Figure E.1.1 – A Simple Place

<font color="#e0121d"><b>Further Work Required in Later Releases</b></font><br/><font color="#29313b">This section documents some issues that have not been resolved in this version.</font><br/><ul>
<li><font color="#29313b">Need to ensure that we have a clear interface with the Physical Resource model. As the Location and Physical Resource models are being defined in parallel, this interface will be refined with successive model versions. In particular, if we should allow arbitrary local place definitions by the definition of a reference point, not requiring any PhysicalResource to be present.</font></li><li><font color="#29313b">Need to investigate the use of IAI / IFC 2.x model for Local places [IAI/IFC]</font></li><li><font color="#29313b">Should try to make concrete location entities compliant with Spatial Data Standard SDSFIE/FMSFIE Release 2.10 [SDSFIE/FMSFIE]</font></li><li><font color="#29313b">Need to validate how an equipment suite (row) should be handled, should we make it a new local coordinate system, or an absolute Local place, that fixes one of the x or y coordinates and allows placement relative to it?</font></li><li><font color="#29313b">The current model has some overlap between Geographic sub address and Local address, we need to think more about this (refer fig 5). Local Address should probably only be defined where Geographic address finishes. This means that Local Address will not have a standard starting point.</font></li><li><font color="#29313b">Investigate the removal of the Street and Network Route specializations to Geographic Place.</font></li><li><font color="#29313b">Re-look at Site Role and how this is expected to be used</font></li><li><font color="#29313b">Should add CAD discussions to “Graphical or Textual“ section</font></li><li><font color="#29313b">Need to look at Local Location again to see if it can be made less dependent on EquipmentHolder. This will also fit in with local Place definitions for sites. Also we will need Graphical Representations for Local Places like suite, which aren’t defined by Physical Resource.</font></li><li><font color="#29313b">Determine if a limited Composite pattern should be used for Symbology (ie. add simple and compound symbology entities to fig. 10b) to allow for GeographicLocation types with multiple Geometry attributes.</font></li><li><font color="#29313b">Consider if LogicalAddress should link into GeographicAddress, AbstractGeographicAddress or higher up un the hierarchy</font></li></ul>
<font color="#29313b">What about things like a technician’s van containing card spares?? Should we model these??</font><br/><ul>
<li><font color="#29313b">we could model a van as a holder with a Local location. We may not know where the van is, but just know that the item is "in the van”. Some service providers may keep track of a van location and be able to send the closest van with the required capability to fix a fault or install a service.</font></li></ul>
<font color="#e0121d"><b>Examples</b></font><br/><font color="#29313b"><b>Example 1 – A place increasing in complexity over time</b></font><br/><ol>
<li><ol>
<li></li></ol>
</li><br/></ol>
<font color="#29313b">In this example we will look at a simple Place that changes over time and how the model allows for these changes.</font><br/><font color="#29313b">At the start we have a simple church that has two POTS lines. The Service Provider initially just records the Geographic Location of the property boundary and the address of the property.</font><br/>