Figure L.11a – Local Coordinate System

MODA / Information Framework / Business Entity / Shared Domain / Location ABE / Figure L.11a – Local Coordinate System

Project:

Figure L.11a – Local Coordinate System : Object diagram

Created:	5/3/2022 2:07:39 PM
Modified:	6/3/2022 11:54:30 AM
Project:
Author:	Giu Platania
Version:	1.0.0
Advanced:
ID:	{04DA5FB9-8A08-4877-8300-43F971098AD9}

Contrasting Geographic & Local Places We will now look at the contrasts between Geographic & Local Places. In map representations, many of the features that we display are unique. For example <ul>
<li>country boundaries</li><li>municipal boundaries</li><li>railway lines</li><li>property boundaries</li></ul>
are influenced by natural features (coastlines, hills, rivers etc.). In the Local (artificial) world, many of the features that we wish to represent are made to specification. On a map we are usually interested in where something is (e.g. where is the hospital?) and want to limit the detail so that the result is not too cluttered. For Local places we are usually interested in both the position (placement) and orientation of features (where is the modem cabinet and which way does the front face?) as shown in fig. 11c. On a map we use a two dimensional planar representation as we wish to view large numbers of features at a low level of detail. For Local places, three dimensional modeling is required to accurately represent: <ul>
<li>multistory buildings</li><li>rack layouts</li><li>card positions</li><li>things mounted on walls</li><li>obstructions like low ceilings, windows, air conditioning vents</li></ul>
So we can see that we have different needs between Geographic and Local Places and that our model representation needs to reflect this. Local Places [Oracle Spatial Concepts] defines Local Coordinate Systems (Non Earth) as: “Local coordinates are Cartesian coordinates in a non-Earth (non-georeferenced) coordinate system. … Local coordinate systems are often used in CAD systems, and they can also be used in local surveys where the relationship between the surveyed site and the rest of the world is not important.” Local Places are provided by a type of Physical Resource that we shall call an EquipmentHolder. An EquipmentHolder could be an Enclosure, that encloses the places inside it or a Structure that provides support for things to be attached. EquipmentHolders can be inside other EquipmentHolders, forming a hierarchy. Structures can be attached to other structures, also forming a hierarchy (where the structure providing the support is the parent). Structures can be contained in EquipmentHolders and EquipmentHolders can be attached to Structures, forming a mixed hierarchy (e.g. a single channel radio transceiver subrack is installed in a weatherproof box which is attached to a tower). Local Places are defined relative to their EquipmentHolder. A rack/ card position can have a status of empty or filled and this can change over time. <ul>
<li>e.g. an EquipmentHolder is installed with a card position empty. A card is later installed, and the card position is filled. The card fails and is removed and sent off for repairs and a replacement card is installed in the same position.</li></ul>
The SID Physical Resource model keeps track of the card; the SID Location model keeps track of the position. We will define a Housing as an Enclosure that is not contained in anything (i.e. the outermost level of containment). We will define a primary structure as a free standing structure (i.e. the outermost level of attachment). Housings and Primary Structures may be related to a geographic location (i.e. be located on a map). Some common Housing types are building, equipment cabinet, street cabinet, pit (underground utility box), housing, rack, sub-rack. Some common Structure types are tower, pole, power pole, radio mast. A radio tower may have a number of rails with positions that can be used to attach antennas and dishes. Each of these rails could also be modeled as a structure. Local Places are dependent on the SID Physical Resource model definitions. The Physical Resource model will only model to the “field replaceable unit (FRU)” level (i.e. it will not model individual resistors and ICs). Local Places can be categorized in various ways. Some things to consider are: <ul>
<li>Above ground (mast), on ground (building, street cabinet) or underground (pit)</li><li>Containment (inside) versus attachment (on)</li><li>EquipmentHolders, which are contained in something (rack), versus those that aren’t (street cabinet). A street cabinet could be thought of as a weatherproof rack that also secures the equipment (from theft).</li><li>Logical versus physical Holders (e.g. suite versus rack)</li><li>Ownership. A housing may or may not be owned by the Service Provider (e.g. Leased building, shared site with leased space)</li></ul>
An EquipmentHolder may provide: <ul>
<li>“General space/ free form space” (e.g. floor space in a building – can be used for almost anything)</li><li>“Managed / restricted / pre-defined space” (e.g. card position – restrictions on what can be plugged in)</li></ul>
A managed space EquipmentHolder entity, on instantiation, should create its Local places e.g. CMUX universal card (SPEC 227L - width & height, pin-out) We will use a Cartesian local coordinate system for Local Locations. The Local coordinate system need not be north-south or earth surface aligned. This means that the local coordinate system definition will need to document a position & orientation of up to six degrees of freedom. In most cases the Holder or Structure will be aligned to the earth’s surface (i.e. not tilting like the tower of Pisa) and we will only require a position & orientation 4 degrees of freedom as shown in fig 11a.