NOTE        The ASAM OpenRoad standard is also relevant to “smart cities”, but because this standard is concerned with the simulation of vehicle behaviour it is considered in clause 7. 

The OGC document “Built environment data standards and their integration an analysis of IFC, CityGML and LandInfra” https://portal.ogc.org/files/?artifact_id=92634 was issued in March 2020.  It has a summary as follows: 

Demand for digital representations of built environments is accelerating and can only be satisfied through greater software interoperability and data integration.  The objective of the Integrated Digital Built Environment (IDBE) joint working group is to address this challenge by bringing together experts from the Open Geospatial Consortium and buildingSMART to coordinate the development of the relevant data standards.  This document is an output from IDBE in which we describe the state of three of the most prominent built environment standards – CityGML, IFC and LandInfra – and describe some of the problems that hinder their integration; finally, we propose actions points for overcoming these problems. 

The document makes proposals as follows: 

The following are proposed as action points for achieving better interoperability and integration: 

1. Articulate clearly a set of illustrative use cases in plain, succinct language that ensures they are digestible by a broad audience, basing them on material in existing technical use case documentation.  These use cases should include details of the software applications that are commonly used for integration or working with integrated data, including their input requirements and internal representations. 
2. Derive and make publicly available a shared vocabulary or definition dictionary from terms that are already used in the standards, or a shared resource for identifying synonyms. 
3. Author a best practice document that recommends the use of three-dimensional georeferencing that is expressed at an appropriate level of precision, defines the level of confidence or accuracy and states the data provenance. 
4. Devise a system of common unique identifiers for real-world, physical objects that remain constant and exclusive to the objects either in perpetuity or for as long as the objects exist. 
5. Agree on a collaborative mechanism for opportunistic harmonisation of conceptual representation at thematic overlaps so far as this does not inhibit enrichment and refinement of the schemas as required within their respective domains 

NOTE        The action points are bulleted in the original, but have been numbered here so that they can be referred to. 

Comments on the action points are as follows: 

1. The creation of a national digital twin is a key use case, which brings together other domain specific use cases. 
2. A shared vocabulary is crucial.  The vocabulary will have levels, with a top level which generic to all engineering, a level below specific to civil engineering, and levels below that which are partitioned according to discipline and sector.  At the very top, the “Core vocabulary for industrial data” developed by ISO TC 184/SC 4 may be useful. 
3. Three dimensional georeferencing with predictable levels of accuracy and with provenance is needed because much infrastructure is below ground level. 
4. Unique identifiers are needed for real world objects.  The “or for as long as the object exists” qualification is unhelpful, because it may be necessary to refer to an object after it has gone. 
5. Harmonisation of the schemas may not be the best way to go.  Instead there should be: 

• Reference data defining types or classes which can be used with all schemas.  This is linked to the development of a shared vocabulary - action point 2. 
• Identifiers of individual real world object which can be used with all schemas - action point 4. 
• A common approach to georeferencing - action point 3. 

The development of an ontology for the national digital twin will provide links between the schemas, because an object in the ontology may have a representation in one or more of the schemas.  These representations may be different because of different objectives and scope. 

5.2 City Geography ML 

http://www.citygml.org/

5.2.1 Defining organization 

This standard was developed by the OGC CityGML Standards Working Group. 

5.2.2 Objectives and scope 

The “Motivation” clause of the document says: 

CityGML is a common semantic information model for the representation of 3D urban objects that can be shared over different applications. 

It is implemented as an application schema of the Geography Markup Language 3 (GML3), the extendible international standard for spatial data exchange and encoding issued by the Open Geospatial Consortium (OGC) and the ISO TC 211. 

CityGML has modules as follows: 

• Appearance; 
• Bridge; 
• Building; 
• CityFurniture; 
• CityObjectGroup; 
• Generics; 
• LandUse; 
• Relief; 
• Transportation; 
• Tunnel; 
• Vegetation; 
• WaterBody. 

CityGML defines Level Of Detail (LOD) as follows: 

LOD0:  a two and a half dimensional Digital Terrain Model over which an aerial image or a map may be draped. Buildings may be represented in LOD0 by footprint or roof edge polygons. 

LOD1:  the well-known blocks model comprising prismatic buildings with flat roof structures. 

LOD2:  a building has differentiated roof structures and thematically differentiated boundary surfaces. 

LOD3:  denotes architectural models with detailed wall and roof structures potentially including doors and windows. 

LOD4:  completes a LOD3 model by adding interior structures for buildings. For example, buildings in LOD4 are composed of rooms, interior doors, stairs, and furniture. 

In all LODs appearance information such as high-resolution textures can be mapped onto the structures. 

5.2.3 Structure of the model 

The top of the CityGML model is shown in Figure 11. 

Figure 11 - Top of the CityGML model 

Comments on Figure 11: 

1. Change is modelled only by a creation and termination of a city object. 
2. A city object group seems to be very similar to a city model, with the exception that one city model cannot be part of another. 
3. The generalizes to relationship is not immediately clear.  This may be to do with level of detail. 

The model for a building in the CityGML model is shown in Figure 12. 

Figure 12 - Building in the CityGML model 

Comments on Figure 12: 

1. It is not clear how the years of construction and demolition for a building relate to the creation and termination dates of a city object. 
2. The distinction between a building part and a building installation seems vague. 
3. The model is clearly intended principally to support visualisation.  Hence a wall is regarded as two surfaces which can be displayed, rather than material between two surfaces which has structural significance. 

5.2.4 Documentation 

The CityGML model is documented according to the guidelines established for OGC standards, as shown in Figure 7. 

5.2.5 Maintenance and usage 

The citygml.org website is [in August 2020] “under reconstruction”.  The OGC website says that version 2 of CityGML was released in 2012, and version 3 is “to be released soon”. 

The level of industrial usage is unknown. 

5.3 Land and Infrastructure Conceptual Model Standard (LandInfra) 

http://docs.opengeospatial.org/is/15-111r1/15-111r1.html

5.3.1 Defining organization 

This standard was developed by the OGC. 

5.3.2 Objectives and scope 

The abstract for the model documentation says: 

“This OGC Land and Infrastructure Conceptual Model Standard presents the implementation-independent concepts supporting land and civil engineering infrastructure facilities.  Conceptual model subject areas include facilities, projects, alignment, road, rail, survey, land features, land division, and wet infrastructure (storm drainage, wastewater, and water distribution systems).  The initial release of this standard includes all of these subject areas except wet infrastructure, which is anticipated to be released as a future extension” 

The Terms and definitions clause contains numerous terms and definitions relevant to land and infrastructure, each with a reference to a source. 

The UML model has packages as follows: 

LandInfra:  LandInfra is the core Requirements Class and is the only mandatory Requirements Class.  This class contains information about the Land and Infrastructure dataset that can contain information about facilities, land features, land division, documents, survey marks, surveys, sets, and feature associations.  LandInfra also contains the definition of types common across other Requirements Classes, such as the Status CodeList. 

Facility:  Facilities include collections of buildings and civil engineering works and their associated siteworks.  The Facilities Requirements Class includes the breakdown of facilities into discipline specific facility parts and introduces the notion of elements which make up these parts.  The Facilities Requirements Class only provides general support for facilities themselves, allowing subsequent Requirements Classes to focus on specific types of the parts that make up facilities, such as road and railway.  This Requirements Class is optional in order to allow for the condition where all of the LandInfra dataset information is not facility related, such as one containing only survey or land division information. 

Project:  A project is an activity related to the improvement of a facility, including design and/or construction.  This class may be for the creation, modification, or elimination of the entire facility or a part of the facility.  The Project Requirements Class includes information about projects and their decomposition into project parts.  In order to allow for the condition where none of the LandInfra dataset information is project related, this Requirements Class is optional. 

Alignment:  An alignment is a positioning element which provides a Linear Referencing System for locating physical elements.  The Alignment Requirements Class specifies how an alignment is defined and used. 

Road:  The Road Requirements Class supports those use cases in which a designer wishes to exchange the output of the design with someone who is likely to use it for purposes other than completing the road design.  Consequently, the Road Requirements Class includes several alternative ways for representing a design such as with 3D RoadElements, 3D StringLines (aka profile views, longitudinal breaklines, long sections), and 3D surfaces and layers, as well as collections of these.  

RoadCrossSection:  The RoadCrossSection Requirements Class extends the Road Requirements Class by adding the 2D CrossSection alternative way of representing a design, as well as collections of these.  

RoadDesign (future work):  The RoadDesign Requirements Class will support designer to designer information interchange, such as would exist when a designer other than the original designer takes over the design process to complete the design.  It is anticipated that the (future proposed) RoadDesign Requirements Class will cover design information in support of those use cases which involve the exchange of design information between designers.  It therefore would include DesignTemplates and SuperelevationEvents. 

Railway:  The Railway Requirements Class supports those use cases where a designer wishes to exchange the output of the railway design with someone who is likely to use if for purposes other than further design. Consequently, the Railway Requirements Class covers design output such as 3D railway elements and track geometry including superelevation (cant). 

Survey:  The Survey Requirements Class is the main survey class and provides a framework for information about observations, processes and their results collected during survey work. The content of this package is similar to the OGC Sensor Model Language (SensorML). The main reason not to use the SensorML standard for this topic is to allow the observation and processes structured in a compact way similar to the LandXML format. Due to the high number of classes the Survey Package was split into different parts, Equipment, Observations and SurveyResults. 

Equipment:  In the Equipment Requirements class all information about the processes and the sensors is available that had been used for the determination of an observation. 

Observations:  Observations Requirements class is the package containing all information about the raw observations and the measurements observed during survey work. The raw observations are needed to enable later reprocessing or reporting of resulting properties of the observed feature of interest. 

Survey Results:  The SurveyResults Requirements Class contains the observed property of a feature of interest.  Using sampling features from the Observation & Measurements (O&M) standard, the dependencies between the observation acts and the results are realized. 

LandFeature:  Features of the land, such as naturally occurring water features and vegetation are specified in the LandFeature Requirements Class as land features.  Also included are models of the land surface and subsurface layers.  Improvements to the land such as the construction of an embankment or the planting of landscape material are considered to be part of Site Facilities in the Facility Requirements Class. 

LandDivision:  Land can be divided up into land divisions.  These can either be public (political, judicial, or executive) or private in nature.  The former are administrative divisions and the latter are interests in land.  Both of these are specified in the LandDivision Requirements Class, though condominium interests in land are specified in a separate, Condominium Requirements Class. 

Condominium:  A condominium denotes concurrent ownership of real property that has been divided into private and common portions.  The Condominium Requirements Class includes information about condominium units, buildings and scheme. 

5.3.3 Structure of the model 

The top of the LandInfra model is shown in Figure 13. 

Figure 13 - Top of the LandInfra model 

Comments on Figure 13: 

1. There is a date-time stamp on a LandInfra dataset, but date and time are not recorded elsewhere.  The description of the data model says: “date and time that the dataset was created and therefore the point-in-time for which the data is valid”. 
2. The description of the model says: “Facility parts are roughly equivalent to IfcSpatialElement (e.g., building, road).  These provide containment for IfcElements (e.g., windows, curb and gutter).” 
3. The description of the model for physical element says: “For bSI, IfcElement has subtypes including IfcBuildingElement, IfcElementComponent, and IfcElementAssembly.” 
4. In the CityGML model, the distinction between a building part and a building installation seems vague.  The same distinction is made here between facility part and physical element. 
5. There are business rules in the model which seem arbitrary.  For example, a facility part is related to a project part, but not a project as a whole.  Why is a project not related either to a facility or to a facility part? 

The LandInfra model extension for a railway is shown in Figure 14. 

Figure 14 - LandInfra model for railway 

Comments on Figure 14: 

1. This model extension seems to add little to Figure 13 which is beyond the scope of reference data.  The class railway element set is structuring which is not specific to railway. 
2. The type of a railway element is specified by reference data.  It can be ballast, switch, sleeper, rail, etc.. 

The LandInfra model has an extension for point cloud observations, along with the image that can be used for colourisation of the surface.  This is of interest because point clouds are also within the scope of ISO 10303-42.  The model is shown in Figure 15. 

Figure 15 - LandInfra model for point cloud 

Comments on Figure 15: 

1. The point cloud numeric results are held in an external file with an efficient format for structured data. 
2. The scan definition and its subclasses are not defined in the LandInfra model. 

5.3.4 Documentation 

The LandInfra model is documented according to the guidelines established for OGC standards, as shown in Figure 7. 

5.3.5 Maintenance and usage 

The LandInfra model was published in December 2016. 

The level of industrial usage is unknown. 

5.4 INSPIRE (Infrastructure for Spatial Information in the European Community) 

https://inspire.ec.europa.eu/

5.4.1 Defining organization 

Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 established an Infrastructure for Spatial Information in the European Community (INSPIRE) 

The Directive came into force on 15 May 2007 and has been implemented in stages, with full implementation required within the EU by 2021. 

The INSPIRE website describes the “INSPIRE Coordination Team” as follows: 

The INSPIRE coordination team consists of staff of the European Commission from DG Environment and the Joint Research Centre (JRC) and staff of the European Environmental Agency (EEA). Its role is to coordinate the implementation and further evolution of INSPIRE and to coordinate with other EU policies. 

DG Environment acts as an overall legislative and policy co-ordinator for INSPIRE. Given the primary focus of INSPIRE on environmental policy, and based on liaison with the EEA, DG Environment specifies environmental thematic policy requirements for INSPIRE as a framework for the implementation programme. DG Environment is chairing the INSPIRE maintenance and implementation group. 

The Joint Research Centre acts as the overall technical co-ordinator of INSPIRE. The JRC ensures the viability and evolution of the technical infrastructure for INSPIRE and guarantees the liaison with the European and international research community. JRC also initiates and monitors the work with international standardisation bodies for the purposes of INSPIRE and is responsible for the technical coordination with other relevant international initiatives. The JRC is chairing the technical sub-group of the INSPIRE maintenance and implementation group (MIG-T). 

In 2013, the European Environmental Agency (EEA) increased its involvement in the EU level coordination, by taking on tasks related to monitoring and reporting, and data and service sharing under INSPIRE as part of the SEIS and INSPIRE activities. The EEA also uses its networking experiences through the well-established European Environment Information and Observation Network (Eionet) to strengthen the integration of INSPIRE with other EU level initiatives, including reporting and information dissemination under the environmental acquis. 

5.4.2 Objectives and scope 

The “About INSPIRE” page on the website says: 

The INSPIRE Directive aims to create a European Union spatial data infrastructure for the purposes of EU environmental policies and policies or activities which may have an impact on the environment.  This European Spatial Data Infrastructure will enable the sharing of environmental spatial information among public sector organisations, facilitate public access to spatial information across Europe and assist in policy-making across boundaries. 

Article 4 of the directive says: 

This Directive shall cover spatial data sets which fulfil the following conditions: 

• they relate to an area where a Member State has and/or exercises jurisdictional rights; 
• they are in electronic format; 
• they are held by or on behalf of any of the following: 
  • a public authority, having been produced or received by a public authority, or being managed or updated by that authority and falling within the scope of its public tasks; 
  • a third party to whom the network has been made available in accordance with Article 12; 
• they relate to one or more of the themes listed in Annex I, II or III. 

[Annex I includes mapping, land registries, hydrology and transport systems; Annex II includes topography, land cover and geology; Annex III includes buildings, soil, land use, agricultural and industrial facilities, minerals, and environmental monitoring and risks.] 

The INSPIRE website says the following: 

Technical Guidance documents define how Member States might implement the Implementing Rules described in a Commission Regulation.  Technical Guidance documents may include non-binding technical requirements that must be satisfied if a Member State chooses to conform to the Technical Guidance.  Implementing this technical guidance will maximise the interoperability of INSPIRE services. 

and contains Figure 16. 

Figure 16 - Relationship between INSPIRE implementing rules and technical guidance 

“Data specification - Technical guidelines” are defined for the different “themes” listed in the Annexes to the INSPIRE directive.  The data specifications conform to ISO 19131 “Data product specifications”.  The development approach is governed by the following: 

Definition of Annex Themes and Scope which describes in greater detail the spatial data themes defined in the Directive  

Generic Conceptual Model which defines base technologies for identification, use of reference data libraries, and spatial information 

Methodology for the Development of Data Specifications which describes how to arrive from user requirements to a data specification. 

Guidelines for the Encoding of Spatial Data defines how geographic information can be encoded. 

For each data specification, the Interoperability of Spatial Data Sets and Services - General Executive Summary says: 

Even though it does not specify a mandatory encoding rule it [Guidelines for the encoding of spatial data] sets GML (ISO 19136) as the default encoding for INSPIRE. 

Guidelines for the use of Observations & Measurements which describes how ISO 19156 “Observations and Measurements” is used within INSPIRE. 

The data schemas can be accessed at https://inspire.ec.europa.eu/data-specifications/2892.

The GML schemas that provide and implementation can be accessed at https://inspire.ec.europa.eu/documents/gml-application-schemas-april-2010. 

5.4.3 Structure of the model 

5.4.3.1 Transport networks 

https://inspire.ec.europa.eu/id/document/tg/tn

Transport Networks is a theme in Annex I of the INSPIRE directive.  (It is considered here as an example.) 

A railway transport network (say) is implemented by a hierarchy of XML schemas as follows: 

railway transport network 

common transport elements 

network 

GML (defined by OGC/ISO 19136) 

All the schemas “above” GML are GML application schemas following the rules given in Annex E of ISO 19136. 

The principal classes in the hierarchy from GML abstract feature to the railway schema are shown in Figure 17. 

Figure 17 - Railway transport network 

5.4.3.2 INSPIRE Feature Concept Dictionary (IFCD) 

https://inspire.ec.europa.eu/featureconcept

The INSPIRE Feature Concept Dictionary web page says: 

The INSPIRE Feature Concept Dictionary (IFCD) acts as a common feature concept dictionary for all INSPIRE data specifications.  The common feature concept dictionary contains terms and definitions required for specifying thematic spatial object types and it is main role is in particular to support the harmonisation effort and to identify conflicts between the specifications of the spatial object types in the different themes. 

372 “concepts” are defined.  Mostly these are subclasses of abstract feature, but some are properties and some are document types. 

5.4.4 Documentation 

The INSPIRE models are documented according to the guidelines established for OGC standards, as shown in Figure 7.  However there are additional implementation guidelines because compliance is required by EU directive. 

5.4.5 Maintenance and usage 

The model is actively maintained by the INSPIRE Coordination Team. 

Compliance will be mandatory within the EU from 2021. 

5.5 iCity Transportation Planning Suite of Ontologies 

https://enterpriseintegrationlab.github.io/icity/iCityOntologyReport_1.2.pdf

5.5.1 Defining organization 

University of Toronto, Transportation Research Institute 

5.5.2 Objectives and scope 

The Ontario report is a combination of ontologies taken, or adapted, from different sources to cover a broad scope.  The Ontario report does not have a single Foundation Data Model to which the ontologies are fitted.  Instead, there is a set of "foundation ontologies", as follows: 

• Location 
• Activity 
• Recurring Event 
• Resource 
• Parthood 
• Units of Measure 
• Observations 
• Time 
• Change 

5.5.3 Structure of the model 

The location ontology taken from OGC has the entity Feature.  The change ontology taken from Katsumi and Fox [http://ceur-ws.org/Vol-2043/paper-05.pdf] has the entities TimeVaryingConcept and Manifestation.  The activity ontology taken from PSL has the entities Activity and State. 

There is no diagram that relates these entities, although there are examples showing them used together. 

NOTE        The 4D approach to change can be related to ISO 15926-2.  Hence a TimeVaryingConcept is a whole life individual, and a Manifestation is more or less a temporal part of an individual. 

The ontology for recurring events is interesting.  This is something important, which is not often addressed.  It is partially addressed in ISO 15926-13 for recurring work periods.  The ontology in the Ontario report is simplified because it only considers completely regular recurrences.  In practice an event may occur every day, except Sundays and bank holidays. 

Based on the foundation ontologies are application ontologies, as follows: 

• Contact 
• Person 
• Household 
• Organization 
• Building 
• Vehicle 
• Transportation System 
• Travel 
• Parking 
• Public Transit 
• Land Use 
• Trip 
• Trip Costs 
• Urban System 

In these ontologies, the allocation of relationships to whole life individuals seems arbitrary.  A Household can have different people at different times that are part of it, but cannot occupy a different DwellingUnit at different times.  Also a DwellingUnit has the same postal address throughout its life. 

The Transportation System and related application ontologies are perhaps less complete and detailed than ASAM Open-Drive. 

The report states: 

Future work should clarify the distinction between the adoption of the 4-dimensionalist approach to capture change and the ontological commitment to the 4-dimensionalist philosophy.  There are many implications in defining a class as a Perdurant (Occurant) or an Endurant (Continuant).  Future work should consider alignment of the iCity Ontology to an Upper Ontology such as DOLCE or BFO in order to make these commitments explicit. 

5.5.4 Documentation 

The report is well written, with UML-like diagrams and good examples.  Recasting the examples with respect to the adopted Top Level Ontology will be useful documentation and a measure of progress on the National Digital Twin. 

5.5.5 Maintenance and usage 

The report is a one-off academic study, and no direct industrial usage is expected.