Harmonising the OGC Standards for the Built Environment: A CityGML Extension for LandInfra

Abstract

The relatively new Open Geospatial Consortium (OGC) standard LandInfra documents in its data model land and civil engineering infrastructure features. It has a Geography Markup Language (GML) implementation, OGC InfraGML, which has essentially no software support and is rarely used in practice. In order to share the benefits of LandInfra (and InfraGML) with a wider public, we have created the Infra Application Domain Extension (ADE), a CityGML ADE that allows us to store LandInfra features in CityGML. In this paper, we semantically map LandInfra to CityGML, describe our ADE, and discuss a few used cases where our ADE can be useful for applications for the built environment. We also provide software to automatically convert datasets from InfraGML to CityGML (and our ADE), and vice versa, as well as to validate them, which will help practitioners generate real-world InfraGML datasets.

1. Introduction

LandInfra [1] is a relatively new Open Geospatial Consortium (OGC) open standard for land and infrastructure features, integrating concepts from Building Information Modelling (BIM) and Geographical Information Systems (GIS). Thus it partially overlaps the main standard of the 3D GIS world, CityGML, such as in its thematic classes Building, Road and Railway (Transportation in CityGML), and LandSurface (ReliefFeature in CityGML) [1]. However, LandInfra is much more powerful in some areas, as it has a more detailed representation for land and infrastructure features, e.g., administrative units, ownership rights, spatial units for land use (land parcels and the legal spaces of buildings), surveying and representation, alignment for roads and railways, subsurface models for terrain, etc.

LandInfra has a Geography Markup Language (GML) implementation: InfraGML, which is also an OGC standard. However, it has no software support yet and is barely used in practice, which means that the advantages of LandInfra (and InfraGML) are not yet being used. The fact that a standard has been tested and implemented in code is a positive feature of the standardization approach, which increases the usability of the standard. After all, we do not want LandInfra, a connecting link between BIM and GIS, to suffer because of low support and no reference implementation. Therefore, in order to encourage the adoption of LandInfra’s features, we have developed the Infra Application Domain Extension (ADE)—an ADE for CityGML that integrates LandInfra’s concepts into CityGML, which we describe in this paper including the steps that we have taken and decisions we have made to develop the ADE. The idea behind the integration is to take the best of both worlds (i.e., CityGML and LandInfra) and have more information than CityGML for specific applications or uses, such as urban environment analysis, subsurface modelling etc.

First, we provide a brief review of the data models of LandInfra and CityGML in Section 2. Second, we provide a complete mapping between LandInfra and CityGML in Section 3, where we identify the matching classes and attributes in the two data models, as well as the LandInfra classes and attributes that do not have a semantic equivalent in CityGML but are useful for the built environment applications, e.g., the material of a building, and the life cycle phase of a building. Third, we describe our CityGML Infra ADE in Section 4, where the missing LandInfra concepts are added to CityGML. Fourth, we provide a few uses in Section 6 for the CityGML Infra ADE to demonstrate the benefits of our ADE in practice.

As a proof of concept of our Infra ADE, we have also implemented two software prototypes to convert datasets from InfraGML to CityGML (and our ADE) and vice versa, as well as a prototype to ensure that the InfraGML files are valid. These are described in Section 5. Finally, we close the article with conclusions and future work.

2. Background

2.1. CityGML

CityGML [2] is an open standard from the OGC for the storage and exchange of 3D city models, including their geometry, semantics, and graphical appearance. It is implemented as an application schema of the GML version 3.1.1 [3].

The data model of CityGML is comprised of a core module and several thematic modules such as Building, Relief, Bridge, Transportation, Vegetation, and WaterBody, which include various types of city objects and their associated semantic properties. Moreover, objects that are not explicitly included in these modules, such as pipes and road noise barriers, can be stored by extending the data model using either of two mechanisms: Generics or ADEs [4,5,6].

Generics allow one to easily extend the city objects in CityGML with a GenericCityObject and attributes (_genericAttribute) without making any changes in the CityGML schema. However, Generics have limitations. CityGML datasets with generic objects and attributes cannot be fully validated against the schema because there is no formal specification of their names and data types. Moreover, name conflicts of the generic objects and attributes may occur. This limits semantic and syntactic interoperability when using Generics.

The second approach is Application Domain Extensions (ADEs), which is more complex but also more structured than Generics. ADEs are formally specified in a separate XML Schema Definition (XSD) file and have their own namespace. Because of this, datasets that use ADEs can be semantically validated. ADEs can be modelled in two ways: First, directly in the XSD schema file; second, by extending the Unified Modelling Language (UML) model of CityGML with application-specific attributes/objects, and later generating the XML schema from the UML model [4,5,6]. ADEs do not need a formal approval by any standardisation body and can be developed by anyone. They are actively used to create application-specific extensions, such as the Noise ADE for noise mapping [2,7], the Energy ADE for energy modelling [8], the Dutch IMGeo ADE [4], the iTINs ADE for handling massive terrains [5], the Metadata ADE [9], etc. See Biljecki et al. [6] for an overview of existing ADEs.

2.2. LandInfra and InfraGML

LandInfra [1] is also an open standard from the OGC, but one which focuses on land and civil engineering infrastructure facilities, including roads, buildings, railways, projects, alignments, surveys, land features and land divisions. ‘Wet’ infrastructure is slated for a future version, including features such as storm drainage, waste water, and water distribution systems. LandInfra was introduced as the proposed successor to LandXML [10].

LandInfra has 10 main requirements classes (summarised in

Table 1. Main LandInfra requirements classes.

#	Class	Summary	InfraGML Part
1	LandInfra	Mandatory core with dataset information and common types	0
2	Facility	Collection of buildings, civil engineering works and their siteworks	2
3	Project	Activity related to the improvement of a facility	2
4	Alignment	Positioning element for locating physical elements	3
5	Road	Roads with 3D elements	4
6	Railway	3D railway elements and track geometry	5
7	Survey	Information related to surveys, e.g., equipment, results, etc.	6
8	LandFeature	Whether natural or man-made, in the surface or subsurface	1
9	LandDivision	Public (political, judicial, or executive) or private land divisions	7
10	Condominium	Ownership of private and public units in a multi-unit building	7

). The self-named LandInfra is the only mandatory class. InfraGML is the GML based implementation of LandInfra, which is published as an eight part OGC standard: LandInfra Core (Part 0), Land Features (Part 1), Facilities and Projects (Part 2), Alignments (Part 3), Roads (Part 4), Railways (Part 5), Survey (Part 6), and Land Division (Part 7). Each part has a separate schema (XSD file).

Given that LandInfra is quite a young standard, it is currently difficult to identify any solid examples of its usage in practice. The vast majority of academic articles that mention LandInfra only describe the possibility of utilising it for various applications as future work.

Among those papers, the majority of them discuss the relationship between LandInfra and the ISO 19152 LADM (Land Administration Domain Model) [11,12,13,14,15,16]. There are also several papers examining the applicability of LandInfra for extending the transportation modelling of roads [17] in the context of road asset management [18,19,20], and for the interoperability between the LandInfra and RailTopoModel [21] for railway infrastructure [22]. Others discuss the usability of LandInfra (& InfraGML) in specific use cases, such as in the creation of a tax valuation information model [15], underground utility network modelling [23] and possible alignments [24] with the CityGML Utility Networks ADE [25] and PipelineML [26], environmental acoustic studies [27], and modelling legal interests and legal boundaries [28].

Furthermore, attempts are being made to align IFC (Industry Foundation Classes) and LandInfra. For instance, the LandInfra Alignment requirement class is based on the buildingSMART IFC Alignment 1.0 standard [1]. It was developed jointly by the OGC and the buildingSMART Infrastructure IFC Alignment project team to ensure interoperability between the two standards in the future. Moreover, buildingSMART is currently working on an IFC Infrastructure extension to model the spatial and physical components of the roads, bridges, and other structures in IFC [29] so that the forthcoming IFC conceptual model for roads and railways be compatible with the LandInfra and InfraGML.

3. Methodology

Mapping between LandInfra and CityGML

LandInfra and CityGML have significant similarities and differences, which we have discussed in detail in Kumar et al. [30]. After comparing the two standards and analysing the individual correspondences of the classes, attributes and other concepts in the data model of LandInfra to their equivalent ones in CityGML, we found that they fit into five different categories as mentioned below. To avoid any confusion in the names of the classes, the LandInfra and CityGML classes are appended with prefixes LI and CG respectively, in this paper.

• Classes (and their attributes) which can be directly mapped from LandInfra to CityGML, e.g., LI::LandSurface with CG::TINRelief, LI::Road with CG::Road, and so on.
• LandInfra classes that require a specific attribute value to determine their corresponding matching classes in CityGML e.g., LI::LandElement can be mapped to CG::PlantCover, CG::WaterBody or CG::TINRelief based on the value of its attribute elementType. The values for elementType attribute are defined in the LandInfra codelist LandElementType.
• LandInfra classes (and their attributes) that do not have a semantically equivalent class in CityGML e.g., classes such as LI::_LandLayer and LI::Facility.
• Classes (and their attributes) that define relationships among features e.g., how different LandInfra features (LI::Feature(s)) are related to each other via LI::FeatureAssociation, which are not present in CityGML.
• LandInfra constraints such as data types, enumerations, and codelists which do not have a semantic equivalent in CityGML.

Based on these categories, we have developed a complete mapping from LandInfra to CityGML, which is presented in

Table 2. Mapping between the LandInfra conceptual model and CityGML. For simplicity, we only show here the mapping for all the LandInfra main requirement classes (marked with M) and a few other LandInfra classes as examples.

#	LandInfra	CityGML	Description
1	LandInfraDataset (M)	CityModel	Aggregations of features with optional metadata.
2	Feature	_CityObject	The base classes for all the features. Both are derived from GML class _Feature, but LI::Feature is a concrete class whereas CG::_CityObject is abstract; they are only conceptually similar.
3	Document	—	No matching semantic class is available.
4	SurveyMark	—	No matching semantic class is available.
5	Project (M)	—	No matching semantic class is available.
6	Facility (M)	_Site	Both include buildings and other civil engineering structures, such as tunnels and bridges, but LI::Facility also defines runways, pipelines and water systems, which are not present in CityGML. However, LI::Facility is a concrete class whereas CG::_Site is abstract; they are only conceptually similar.
7	FacilityPart	—	No matching semantic class is available.
8	Building	Building	In LandInfra it is a subclass of LI::FacilityPart, whereas in CityGML it is a part of the CG::Building module.
9	LandFeature (M)	—	No matching semantic class is available.
10	LandElement	WaterBody/PlantCover/TINRelief	The correspondence depends on the value of a LI::LandElement’s elementType, which can be waterBody, vegetation or landForm, as defined in the codelist LandElementType.
11	LandSurface	TINRelief	LI::LandSurface models terrain as a TIN, much like CG::TINRelief.
12	_LandLayer	—	No matching semantic class is available.
13	Alignment (M)	—	No matching semantic class is available.
14	Road (M)	Road	In the Transportation module in CityGML and in the Facility requirement class in LandInfra. CityGML focuses on polygon representations with the possibility to include lines as well, while LandInfra focuses on lines and surfaces (i.e., TINs).
15	Railway (M)	Railway	In the Transportation module in CityGML and in the Facility requirement class in LandInfra. LandInfra provides many more components that can be modelled.
16	LandDivision (M)	LandUse	CG::LandUse represents divisions according to specific land uses, whereas LI::LandDivision has richer semantics and is further divided according to political, judicial, or executive views, ownership, rights, and so on.
17	CondominiumBuilding (M)	—	No matching semantic class is available.
18	Survey (M)	—	No matching semantic class is available.

. Notice that many classes in LandInfra do not have clear correspondences in CityGML, which is largely because LandInfra is much more detailed than CityGML with respect to the semantic information and relationships of land and infrastructure features. Loss of information while converting InfraGML datasets to CityGML is thus inevitable without an extension to the CityGML data model.

4. Results

4.1. The CityGML Infra ADE

In order to support LandInfra concepts in CityGML, we have developed the Infra ADE, which is able to store and manage LandInfra/InfraGML datasets in CityGML with full compatibility. We have implemented the ADE and we provide the UML model, the XSD schema, the documentation and a prototype software, which are all publicly available in our GitHub repository: https://github.com/tudelft3d/city2InfraGML.

Depending on the five cases of the classification in our analysis, we have built the Infra ADE for CityGML by:

• Adding the missing LandInfra attributes to the CityGML classes that matched LandInfra classes (Cases 1 and 2);
• Adding new types that represent the LandInfra classes that do not have matching CityGML classes (Case 3 and 4);
• Adding support for the LandInfra geometry types, data types and codelists (Case 5).

These solutions are individually presented in the following subsections. Note that in order to avoid any conflict with the existing CityGML elements, the new Infra ADE elements are defined in a different namespace https://3d.bk.tudelft.nl/schemas/infraADE with an identifier ‘infra’.

4.1.1. Extending the CityGML Classes That Match LandInfra Classes

CG::CityModel is extended to include LI::LandInfraDataset’s classes and their specific attributes (Figure 1). It stores:

• The ID and the scope of the dataset (<infra:datasetID>);
• The metadata about the dataset (e.g., <infra:name>, <infra:dateTime> and <infra:author>);
• The associations between the features in the dataset (<infra:featureAssociation>);
• The information about the survey(s) stored in the dataset (<infra:survey>);
• The collective information about the features belonging to a particular type or authority in the dataset (<infra:set>).

CG::Railway is extended to include LI::Railway’s classes and their specific attributes (Figure 2). It stores:

• The ID and the scope of the railway features present in the dataset (<infra:railwayID>);
• The attribute indicating if the railway feature is existing or proposed (<infra:railwayState>);
• The status to indicate where the railway feature is within its life cycle (<infra:railwayStatus>);
• The railway elements such as switches, rails, etc. present in the dataset (<infra:railwayElement>);
• The specifications of the cant (also called the superelevation) of the railway tracks present in the dataset (<infra:cantSpecification>);
• The alignments (positioning elements) used to define the geometry of the railway tracks (<infra:railwayAlignment>).

CG::Road is extended to include LI::Road’s classes and their specific attributes (Figure 3). It stores:

• The ID and the scope of the road features present in the dataset (<infra:roadID>);
• The estimated width of the road (<infra:approximateWidth>);
• The material of the road (<infra:material>);
• The attribute indicating if the road feature is existing or proposed (<infra:roadState>);
• The status to indicate where the road feature is within its life cycle (<infra:roadStatus>);
• The road elements such as pavements, side walks, etc. present in the dataset (<infra:roadElement>);
• The alignments (positioning elements) used to define the geometry of the roads (<infra:roadAlignment>);
• Alternative ways for representing a road from design perspective such as 3D StringLines (<infra:stringLine> aka profile views, longitudinal breaklines, long sections), and 3D surfaces (<infra:surface>), or as well as collections of these (<infra:stringLineSet> or <infra:surfaceSet>) [1];
• The 2D cross section views cut across the road at a particular location along the length of the road (<infra:roadCrossSection>).

CG::LandUse is extended to include LI::LandDivision’s classes and their specific attributes (Figure 4). It stores:

• The ID and the scope of the land division features present in the dataset;
• The type of land division. It can be public (infra:administrativeDivision) or private (infra:easement or infra:propertyUnit) in nature;
• The statement document which specifies which establishment or acquisition of the land (infra:documentation);
• The ownership rights of properties (infra:ownership);
• The cadastral parcels present in the dataset (infra:landParcel);
• The spatial units to define the geometry (shape and location) of the land parcels, easements, and other administrative divisions (infra:SpatialUnit);
• The bounding elements to specify the boundary of the spatial units (infra:boundingElement).

CG::TINRelief is extended to include LI::LandSurface’s attributes. It stores:

• The ID and the scope of the land surface features present in the dataset (<infra:landSurfaceID>);
• The material of the land surface (<infra:material>);
• The spatial representation of the land surface as TINs (similar to TINRelief);
• The attribute indicating if the feature is existing or proposed (<infra:state>).

A LandInfra LI::LandElement feature can be a terrain, water body or vegetation depending upon the value of its elementType. Therefore, the CityGML classes CG::WaterBody, and CG::_VegetationObject(CG::PlantCover and CG::SolitaryVegetationObject) are extended to include LandElement’s attributes, such as ID (<infra:landElementID>), type of land element (<infra:landElementType>), material (<infra:material>), state (<infra:state>), property (<infra:property>) and sets of associated properties (<infra:propertySet>), and so on.

Similarly, CityGML CG::Building and CG::BuildingPart are extended to include LandInfra LI::Building’s (from LI::FacilityPart) attributes such has ID, state and status. See Appendix A for the rest of the UML models.

4.1.2. Adding New Feature Types for Non-Matching LandInfra Classes

A new feature type LandInfraFeature is introduced as a subclass of CG::_CityObject to represent LandInfra’s LI::Feature class. Since LI::Feature is a concrete class and CG::_CityObject is an abstract class, we introduced LandInfraFeature as a concrete class in our ADE (Figure 1).

LandInfra LI::Document is introduced to store documents with information about the datasets, e.g., statements, condominium schemes, etc. (Figure 1). Similarly, LandInfra’s LI::SurveyMark is defined to store points on the surface of the Earth which are stable during surveying operations.

LandInfra LI::Facility and LI::FacilityPart are introduced as the subclasses of LandInfraFeature to represent the infrastructure facilities in the Infra ADE. Further, to store the activities related to the improvement of facilities, such as design and/or construction, we introduced the LandInfra LI::Project and LI::ProjectyPart feature types in the ADE (Figure 1).

LandInfra’s LI::Alignment and its associated classes are introduced in the ADE to provide a linear referencing system for locating the features, e.g., an alignment for the centreline of a road, alignment for rails, etc. (Figure 5). An alignment can be represented as:

• A simple 2D line string (<infra:lineString2DRepresentation>);
• A horizontal alignment (<infra:Alignment2DHorizontal>);
• A horizontal alignment with an accompanying 2D vertical long section taken along the horizontal alignment (<infra:Alignment2DVertical>);
• A 3D line string (<infra:lineString3DRepresentation>).

LandInfra LI::CondominiumBuilding, LI::CondominiumBuildingPart and other associated classes are introduced in the Infra ADE. The LandInfra abstract class LI::_LandLayer is introduced as it is to represent the layers underneath the land surface (Figure 6). They can be defined in three ways: As a 3D polyface mesh solid (<infra:SolidLayer>), as a collection of surface layers (<infra:SurfaceLayer>), or as a series of 2D vertical cross sections (<infra:LinearLayer>). Lastly, LandInfra LI::Survey is introduced in the ADE to model information related to the acquisition of geometry and semantic properties of features.

4.1.3. New Geometry Types, Data Types and Codelists

Three new LandInfra-specific geometry types are introduced in the CityGML Infra ADE, namely IndexedPoint, SimpleIndexedPolygon, and PolyfaceMesh. These geometry types do not exist in the ISO 19107 and in GML. Given that existing software (FME [31], FZK viewer [32], etc.) would require additional implementation to support and visualize these new geometry types, we made their implementation optional in the ADE (in case there is support in the future). We fully understand how difficult it can be to extend software support for each and every ADE that defines new geometry types. Therefore, while converting from InfraGML to CityGML Infra ADE using our software prototype, these geometry types are now converted to the existing OGC Simple Feature structure supported in GML.

Further, one new LandInfra data type, ID is introduced. The ID data type is defined to uniquely identify the features within the scope of the dataset. It has an attribute identifier which is a user defined ID unique within the dataset or globally unique with the inclusion of scope attribute (see snippet below).

We also defined 18 new codelists that were taken from LandInfra, which are summarised in

Table 3. Description of codelists included in the Infra ADE.

#	Codelist	Description
1	State	Whether an object is existing or proposed.
2	Status	Life cycle stage of an object, e.g., planned, under construction, etc.
3	ProfessionalType	Position of the person in charge of the land development and infrastructure project e.g., draftsman, engineer, surveyor, etc.
4	FacilityPartType	e.g., building, road, etc.
5	LandElementType	e.g., vegetation, terrain, etc.
6	RoadElementType	e.g., pavement, gutter, etc.
7	RailwayElementType	e.g., switch, rail, etc.
8	LandParcelState	e.g., main parcel or carrier parcel, etc.
9	SurveyMonumentType	e.g., boundary marker, observation point of geodetic significance, etc.
10	StatementType	Statement that is signed to establish the interest in the land.
11	SigningRole	Role a signing party plays, e.g., owner, buyer, seller, etc.
12	CondominiumUseType	e.g., residential, office, etc.
13	BuildingPartType	e.g., the main part to which the postal address refers to, or a secondary part like the basement of a shop, etc.
14	StringType	Geometric string representation of bounding element BEString.
15	DimensionType	Dimension of a spatial unit. Depending on the value, a spatial unit can include attributes such as area, volume and height.
16	ImplicitSurfaceType	Top or bottom surface of a spatial unit for the bounding element BEImplicitFace.
17	SurveyType	e.g., compiled, computed or actually surveyed, etc.
18	SurveyResultType	e.g., point, point cloud, image, etc.

. They are implemented as simple dictionaries according to the CityGML specifications and can be further extended. It is interesting to note that the codelist used to identify the type of easement (EasementType) in the LandInfra requirement class LandDivision is missing in the LandInfra specifications. It is therefore not included in the codelists defined for the ADE. We also defined two enumerations taken from LandInfra: Side and StringDirectionType.

5. Implementation and Testing

5.1. Software Prototypes

In order to test our ADE and show its usability, we have developed an open source prototype that automatically converts datasets from InfraGML to CityGML (with our Infra ADE), and vice versa. For the conversion from CityGML to InfraGML, since InfraGML does not offer the possibility to extend its core model, only the classes and attributes that can be mapped are converted.

It should be noticed that we do not attempt to convert to a harmonised data model (see El-Mekawy et al. [33] as an example) since the resulting files would not be useful in practice: Software packages do not have support for such data models.

The software we have developed, together with sample datasets, is freely available in our GitHub repository: https://github.com/tudelft3d/city2InfraGML. It is composed of two Python scripts:

• citygml2infragml.py for converting original CityGML models to InfraGML.
• infragml2citygml.py for converting InfraGML models to CityGML (with Infra ADE).

In addition, since there is currently no official way to validate InfraGML datasets, we developed a validator that checks a dataset against the schema (https://github.com/tudelft3d/city2InfraGML). It can be combined with val3dity (https://github.com/tudelft3d/val3dity) to validate the geometry of the 3D primitives according to the international standard ISO 19107 [34,35]. For the validator, we introduced an additional wrapper schema for specifically validating different LandInfra features (e.g., terrain, facilities, roads, etc.) within a single dataset.

5.2. Experiments and Validation

We tested our software with various real world datasets in the Netherlands (Figure 7) and validated our results by checking them against the schema using the validator. The examples of XML in the following sections are taken from the real-world datasets that we have created.

The tested datasets were the following.

• From CityGML to InfraGML:

  (a)

  CityGML 2.0.0 LOD2 (Levels of Detail) city model of an area in Rotterdam, the Netherlands (Source: http://rotterdamopendata.nl/dataset/rotterdam-3d-bestanden).

  (b)

  CityGML 1.0.0 LOD2 models of building and terrain of an area in the Hague, the Netherlands (Source: https://data.overheid.nl/data/dataset/48265-3d-lod2-stadsmodel-2010-den-haag-citygml).

  (c)

  CityGML 2.0.0 LOD1 city model of an area of Delft, the Netherlands generated using 3dfier (https://github.com/tudelft3d/3dfier) (Source: https://3d.bk.tudelft.nl/opendata/3dfier/).

• From InfraGML to CityGML:

  (a)

  Sample InfraGML 1.0.0 datasets of land surfaces, facilities and roads.

  (b)

  3D city models of an area in Delft, Rotterdam, and the Hague, the Netherlands generated by converting original CityGML LOD1 and LOD2 models to InfraGML using citygml2infragml.py.

6. Use Cases for the CityGML Infra ADE

Some use cases for LandInfra are included in the official documentation [1], which would be equally applicable to the Infra ADE. These are: Road alignments, surveying, conversions between LandXML and InfraGML, storage of terrain data, land division, and representation of railway features. In addition, Blanchet et al. [27] investigated whether CityGML or InfraGML is best suited for initial environment acoustic studies, but the research was limited to a conceptual study of the LandInfra standard, and real world InfraGML datasets were not available.

We provide here a list of additional use cases where our CityGML Infra ADE can be useful in practice:

• Subsurface modelling
  CityGML originally does not model real-world subsurface data originating from the geological models [36], which is useful for many applications, such as infrastructural works that require excavations and soil studies. Since LandInfra has support for modelling topography (terrain) and subsurface information in its requirement class LandFeature, our Infra ADE enables the modelling of surface features (such as buildings, roads, etc.) with subsurface information in an integrated framework (see Snippet 1 below for implementation in an Infra ADE dataset). The subsurface layers can be represented in three ways in the Infra ADE: As TINs, 3D polyface mesh solids, or vertical 2D cross sections. Each subsurface layer can have an additional attribute material to specify the material of the layer. This integrated framework will not only benefit the planning and design process for surface and subsurface structure construction, but also make transparent the risk management.
• 3D cadastre
  CityGML lacks the capability to represent the legal extents and rights of entities within a complex, which is the core of land administration information. Extensions have been proposed to integrate this information in the data model of CityGML for the management of property rights, e.g., the CityGML Land Administration Domain Model (LADM) ADE to represent the legal ownership of buildings and their parts in CityGML in accordance with the ISO 19152-LADM [37] standard [38,39]. However, most of the available land administration research with CityGML is centred around buildings.
  LandInfra is more than LADM. LandInfra addresses land development in the context of activities concerning civil engineering infrastructure facilities [1]. This is achieved by modelling what is needed to account for such activities, including defining the legal entities, their boundaries, as well as identification of the signing parties [1]. LandDivision is one of the requirement classes of LandInfra. As mentioned in the LandInfra specifications, the scope of LandInfra does not include land recording and database storage. The LandInfra Standard addresses only a subset of LADM [1]. The integration of LandInfra with CityGML in our Infra ADE further enables modelling administrative divisions, cadastral information and ownership rights of condominiums, and subsurface infrastructure such as underground tunnels (Snippet 2).
• Urban facility management
  Currently, most of the research related to facility management is confined to buildings. For instance, Kim et al. [40] implemented the CityGML Indoor ADE to implement indoor space and indoor facility management applications for buildings. Similarly, the CityGML Computer Aided Facility Management (CAFM) ADE was developed by Moshrefzadeh et al. [41] to integrate detailed geometric and semantic information on the outer shell of the buildings for applications like cleaning management, and cost planning and management.
  In LandInfra, a facility includes buildings and other infrastructure, such as roads, railways, runways, waste water system, bridge, utilities (pipelines) etc. [1]. The integration of LandInfra with CityGML in our Infra ADE enables effective management of all the aforementioned facilities in CityGML. Each facility, whether a building or a road, has a life cycle, including planning, design, construction, maintenance, operation, and termination phases. Furthermore, a facility may be broken down into parts (FacilityPart), e.g., a shopping mall may include buildings, roads, site, drainage, water distribution and waste water [1]. Any activity such as the design or construction related to a facility (or its parts) is managed through projects (Project/ProjectPart). The CityGML Infra ADE dataset can include any number of projects to store the status of the facility project (projectStatus) and the date on which the status value is valid (statusDate) to make the dataset more manageable (Snippet 3).
• Surveying
  Survey data can be used as a reliable data source at all the stages of the life cycle of a building or other features. Designers of architectural and design projects, armed with accurate site data, can work with reduced overall commercial risk, and with greater certainty. CityGML does not provide a way to store survey data in a structured way, but LandInfra has a requirement class Survey outlining the specifications to store such data. Because of this, the integration of LandInfra with CityGML in our Infra ADE enables effective management of survey metadata in CityGML, e.g., survey type and its purpose, surveyor information, and so on. Further, it is possible to store information about the survey observation points, accuracy information, equipments or sensors used, and the results.
• Asset management
  Asset management can be summarised as a systematic approach to the process of maintaining, upgrading and operating physical assets in a cost-effective way for both short- and long-term planning [42]. For municipalities and regional governments asset management is a crucial element of day-to-day operations. Within asset management, the maintenance of roads and transportation networks is key to keeping traffic moving smoothly and safely on a daily basis. Road maintenance includes activities such as smoothness control/de-icing, repairs, closures, milestone maintenance and traffic city furniture replacement [17].
  While CityGML has support for Levels of Detail (LODs), it only supports line representation at LOD0 and polygon representation at LOD1–LOD4. InfraGML supports four representations for roads: Solid, faceted (triangular) surfaces, lines running longitudinally and 2D views cut perpendicular to a road’s centreline. It is also possible to model the cross-section of a road, which is valuable for repair projects. Furthermore, CityGML has support for railways in its Transportation module, but it has little support and almost no documentation. It is also unclear how to exactly model a railway in CityGML, as it is also mentioned as being a part of the Tunnel and Bridge modules. With InfraGML, there is a dedicated class for railways and this has support for 3D railway elements and track geometry including superelevation (cant). Snippet 5 summarises the potential additional elements from LandInfra that can enhance CityGML data for road asset management.
• Urban environmental analysis
  The added value of integrating CityGML and LandInfra in our Infra ADE can also be seen in urban applications such as estimating the level of noise exposure on buildings, or how much solar irradiation a building will receive. Unlike CityGML, LandInfra explicitly models the materials of road surfaces and terrain, geometry and semantics of railways, type of road elements (pavements, hard shoulders, soft shoulders etc.), construction materials of buildings, and information about the observation/measurement points to name a few. Such information is useful for environmental applications such as urban noise and flood mapping. We have added all these elements in the Infra ADE to supplement environmental analysis using CityGML. The previous snippet of XML Snippet 5 contains elements that can be useful in urban environmental analysis.

7. Conclusions and Future Work

LandInfra is a more powerful standard than CityGML in some areas, as it has a much more detailed representation for land and infrastructure features. However, it currently has essentially no support in software, and even the academic papers that touch upon its theoretical potential do not use it in practice. Our Infra ADE for CityGML provides a way to change this situation by embedding LandInfra’s features in CityGML. This way, we can use the best of both standards, and we can also ensure that the resulting datasets can be used in practice by the software packages already supporting CityGML. There is a lot of support available for the CityGML extension mechanism such as parsers, validators, DBMS, and so on, which can indirectly contribute to the adoption of LandInfra through our ADE. One example is the latest version of 3DCityDB (3D City Database 4.0.0), which offers support to store CityGML files having ADEs in a database. A CityGML ADE is handled like a ‘plugin’ and the 3DCityDB core database schema is extended dynamically with new tables based on the schemas of the ADE [43,44]. Similarly, citygml4j [45], a Java API for CityGML, supports reading and writing CityGML ADE datasets. Further, it is also possible to visualize the ADE datasets with new city objects (with GML geometries) and semantic attributes using FME and FZK viewer. As discussed before, these software would require additional implementation to support and visualize any new geometry types (other than GML) introduced in an ADE dataset.

In order to develop the Infra ADE, we have performed a detailed analysis of the individual classes, attributes and relations in CityGML and LandInfra, and created a mapping from LandInfra to CityGML. We have mapped LandInfra to CityGML (and not vice versa) because CityGML provides mechanisms to extend its data model with new feature types and attributes using Generic city objects or ADEs, whereas similar extensions are not supported in the LandInfra standard. Moreover, CityGML has the concept of LODs, which is widely used in practice and missing in LandInfra.

To provide a proof-of-concept of our mapping, we have developed two open source software prototypes for converting CityGML (and Infra ADE) datasets to InfraGML and vice versa. Since LandInfra is a relatively new standard and there are no concrete datasets available for it, the developed prototypes can help practitioners to generate valid real-world sample InfraGML datasets, which can then lead to the real-world applications that are currently missing from the standard.

Furthermore, we are working on the development of InfraJSON, a JSON (JavaScript Object Notation) based encoding for InfraGML, which can be explored at our public GitHub repository: https://github.com/tudelft3d/InfraJSON. Despite the precedence set by the high usage of GML (XML) in various OGC standards, it is a verbose and complex encoding for use in real world applications, whereas JSON provides an easy-to-use and easy-to-read alternative [46,47]. For instance, CityJSON (http://www.cityjson.org) is a JSON-based encoding for a subset of the OGC CityGML data model. Virtually all features are supported except a few (https://www.cityjson.org/citygml-compatibility/). It also has support for software tools available for generation, manipulation and visualisation. InfraJSON is a work in progress and its development would encourage the usage of the LandInfra standard.