The LandInfra standard and its role in solving the BIM-GIS quagmire

Abstract

LandInfra is a relatively new open standard for modelling and representing land and infrastructure features. As it overlaps with other open standards in BIM (IFC) and 3D GIS (CityGML), it has been recognised as a potential candidate to bridge the gap between the two domains. However, the knowledge of this standard in both communities is low, and there are still no publications which fully explore LandInfra and its possibilities for integrated BIM-GIS applications. In this paper, we review the LandInfra conceptual model and its GML encoding InfraGML, provide a detailed comparison of it with respect to CityGML and IFC, and investigate a few potential use cases where LandInfra and InfraGML are useful for BIM-GIS applications.

Introduction

Three-dimensional geoinformation practitioners dealing with cities and infrastructure often struggle while shuttling 3D models back and forth between BIM (Building Information Modelling) and GIS (Geographical Information Systems) software, which often only have support for a few proprietary native formats. This forces users to attempt to convert between formats, often losing information, and sometimes even having to manually recreate whole datasets [2, 43, 74]. The integration of BIM and GIS, often dubbed as GeoBIM, is thus widely acknowledged as a crucial step for 3D city modelling and its applications [2].

BIM models are much more detailed and semantically rich than GIS models [2]. BIM is more than a data model, it is an approach to deliver a reliable digital representation of a building during its development. It can be used to demonstrate the entire building life cycle, including the processes of construction, operation, and maintenance [83]. The BIM data is structured and defined using open BIM standards like IFC (Industry Foundation Classes). The integration of BIM and GIS can avoid unnecessary efforts in redundant modelling with focus on reusing the available data. For instance, models of buildings are produced in both domains for different applications, such as design and construction in BIM, and spatial analysis in GIS. With BIM and GIS integration, more detailed 3D city models can be built by reusing the BIM data. These enriched models can be used to perform environmental analysis, e.g. GIS can provide insight about flood-prone areas and give BIM designers detailed information to model the location, orientation, and even construction materials of structures such as buildings [1]. Much work has been done on this integration, particularly of IFC and CityGML, which are two popular open standards in the BIM and 3D GIS domains [2, 19–21, 24, 37, 47]. Despite several attempts, the two domains remain disconnected owing primarily to the differences in the underlying modelling approaches with respect to geometry, semantics, schema, level of detail, etc. [2, 20]; a situation that we refer to as the BIM-GIS quagmire.

Relevant to these efforts is the development of the new open standard LandInfra (Land and Infrastructure) by the OGC (Open Geospatial Consortium), which was designed as a ‘connecting bridge’ between the BIM and GIS domains (Fig. 1). LandInfra is an open conceptual data model for the representation of land and civil engineering infrastructure features. It integrates concepts from CAD (Computer Aided Design), BIM, and GIS, and has overlaps with CityGML and IFC. For instance, many of the LandInfra feature types are similar to the thematic classes in CityGML, such as Building, Road, Railway, LandSurface (ReliefFeature in CityGML), etc. [55]. Furthermore, both LandInfra and CityGML use ISO 19107 geometry types [25] for representing the geometry of the features. Like CityGML, LandInfra also has a UML (Unified Modelling Language) based conceptual model and a GML (Geography Markup Language) encoding, InfraGML. In addition, the LandInfra Alignment requirement class is based on the buildingSMART IFC Alignment 1.0 standard [55]. It was developed jointly by the OGC and the buildingSMART Infrastructure IfcAlignment 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 [13] so that the forthcoming IFC conceptual model for roads and railways be compatible with the LandInfra and InfraGML.

Fig. 1

LandInfra a connecting bridge between IFC and CityGML, but is conceptually, semantically, and geometrically closer to CityGML

Despite the fact that LandInfra has the potential to bring the architectural, BIM, and geospatial views onto a common footing, the standard is not well known in the BIM or GIS communities, and its applicability to integrated BIM-GIS applications has barely been explored. The aim of this paper is thus to investigate LandInfra and its potential role in solving the BIM-GIS quagmire in more detail. In order to meet this goal, this paper: (i) provides an intuitive review of LandInfra, its characteristics and its relation to the main open 3D GIS (CityGML) and BIM (IFC) standards; (ii) summarises what has been written in the academic literature about LandInfra and how it is used (or not) in practice; and (iii) analyses LandInfra’s potential for integrated BIM-GIS applications.

In this paper, we thus start with a brief overview of CityGML, IFC and LandInfra, then proceed to describe how LandInfra is used in theory and in practice. Afterwards, we provide a comparative analysis of the LandInfra conceptual model with CityGML and IFC. We then present three real-world use cases that could benefit from a BIM-GIS integration using LandInfra. We also discuss some minor issues in the data model of LandInfra standard, which we found through our analysis of the standard. We close the article with conclusions and future work.

Background

LandInfra and InfraGML

Originally from the spatial world, LandInfra [55] was recently proposed as the successor to LandXML [40]. LandXML is an XML based, open data model for the representing civil engineering and survey measurement data [40]. It is not recognised as an official standard by any standards organization like OGC or ISO, which created a confusion in the marketplace concerning the future of the standard. To align LandXML with the OGC standards, a LandGML Interoperability Experiment [50] was initiated by the OGC in 2004 to make LandXML compliant with the OGC GML standard for geospatial data. Following this effort in 2013, LandInfra SWG (Standards Working Group) reviewed LandXML and made efforts to determine how to continue its support to the existing users in the best possible manner. Several problems with the LandXML-1.2 were discovered and likewise documented in [71, 72]. Further, there is no formally published documentation, user guide, requirements definition, or underlying conceptual model of LandXML. Therefore, a fresh OGC standard LandInfra was developed, based on a subset of LandXML functionality, but implemented with GML (as InfraGML) and supported by a UML conceptual model.

LandInfra covers both topography and subsurface information and partners the needs of surveying to locate infrastructure facilities on the terrain in compliance with interests in land [55]. It thus includes land and civil engineering infrastructure facilities, e.g. roads, buildings, railways, projects, alignment, survey, and land features; as well as the division of land based on administration, i.e. jurisdictions and districts; and interests in land, e.g. land parcels, easements and condominiums.

InfraGML is the GML based encoding of the LandInfra data model, which is published as an 8 part OGC standard: LandInfra Core (Part 0) [57], Land Features (Part 1) [58], Facilities and Projects (Part 2) [59], Alignments (Part 3) [60], Roads (Part 4) [61], Railways (Part 5) [62], Survey (Part 6) [63], and Land Division (Part 7) [64]. Each part has a separate schema (XSD file).

LandInfra has 10 requirements classes (Fig. 2), of which LandInfra is the only mandatory one and is implemented in InfraGML standard Part 0. LandInfra allows land features to be collected into a Facility. Facilities include collections of buildings and civil engineering works but only provides general support for the facilities themselves and allows subsequent requirements classes to focus on specific facilities. Projects are activities that are related to the improvement of a facility, this includes design and/or construction. LandInfra requirement classes Facility and Project are implemented in InfraGML standard Part 2. An Alignment is a positioning element providing a linear referencing system necessary for locating elements and is implemented in InfraGML standard Part 3. The LandInfra requirement class Survey supports information in relation to survey work such as equipments used for survey, survey results, etc. and is implemented in InfraGML standard Part 6 (Survey). LandInfra Road, and Railway provide support for modelling roads and railways within the facilities and are implemented in InfraGML standard Part 4 and Part 5, respectively. LandFeature focuses on features of a land and specifically naturally occurring water and vegetation features while LandDivision models the division of land either public or private. LandFeature and LandDivision are implemented in InfraGML standard Part 1 and Part 7, respectively. LandInfra requirement class Condominium deals with the ownership of private and public units in a multi-unit building. It is also implemented in InfraGML standard Part 7.

Fig. 2

LandInfra Requirements Classes (Source: [55])

The development of LandInfra and InfraGML is an important milestone in the direction of open standards for the integration of geospatial information and the information about the built environment. Since it is based on the functionality of LandXML, LandInfra can easily substitute LandXML in the surveying, roads, and highway transportation sector. LandInfra can also be used in the AEC industry for urban facility management and life cycle maintenance of facilities and projects. Further, integration of LandInfra with other OGC standards, such as CityGML, can be useful for different 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.

CityGML

CityGML [52] is an open standard by the Open Geospatial Consortium for the storage and exchange of 3D city models. It models cities’ geometry, semantics, and graphical appearance. It is implemented as an application schema of the Geography Markup Language version 3.1.1 (GML3) [51].

The data model of CityGML comprises of a core module and several thematic modules. The core module defines the abstract base classes from which thematic classes are derived. The thematic module of CityGML provides different thematic classes to store city objects, such as Building, Relief, Bridge, Transportation, Vegetation, and WaterBody, as well as their associated semantic properties. For instance, in case of buildings, it is possible to store building properties such as year of construction (yearOfConstruction), year of demolition (yearOfDemolition), type of roof (roofType), etc. as attributes. Furthermore, CityGML supports the hierarchical decomposition of an object into semantic surfaces depending upon the required LOD (Levels of Detail) e.g. a building in LOD2 can be differentiated into walls (WallSurface), roofs (RoofSurface) and ground surface (GroundSurface). While CityGML offers an LOD (LOD4) for the interior of buildings, this is virtually never used, and the concepts will be modified in a future version [44].

IFC

IFC [32] is an open, international standard used in the BIM domain for the exchange of 3D models of buildings and infrastructure projects, such as bridges and viaducts. The standard is developed by the buildingSMART consortium, which comprises software and construction companies, transportation network operators and government agencies¹.

IFC files can contain many types of classes (130 defined types, 207 enumeration types, 60 select types and 776 entities in IFC 4 Addendum 2 [14]. Among others, there are classes to model the semantics of products (which include building elements such as IfcDoor or IfcColumn), organisations, rules, processes, and resources. For the purposes of this paper, the most interesting ones are products, which include the definition of locations, such as building sites (IfcSite) and spaces (IfcSpace), and also the physical elements in buildings (e.g. IfcBeam, IfcColumn, IfcDoor, IfcWindow).

LandInfra (and InfraGML) in theory and practice

LandInfra is a relatively young standard and at present it is difficult to identify any concrete examples of its usage in practice; the majority of scientific articles that mention LandInfra only describe the need to consider it in future work.

There are many papers discussing the relationship between LandInfra and the ISO 19152 Land Administration Domain Model (LADM), see for instance [15, 33, 34, 42, 66, 67, 78]. In these papers, InfraGML is cited, alongside other models such as CityGML and LandXML, in relation to harvesting the existing 3D data that is collected to open up the possibility of creating a 3D cadastral database.

There are several papers discussing the integration of LandInfra in specific use cases. Kara et al. [34] assessed the use of several different models to provide a valuation information model for property taxes. Pouliot et al. [68] compared schema matching between user needs and three geospatial standards (the CityGML UtilityNetwork ADE, InfraGML and IFC) in relation to underground utility network modelling. They were not able to come to a definitive conclusion due to contradictory results based on differences in schema matching techniques and the variation between the various levels and the number of elements when comparing one schema to another. [69] assessed LandInfra, along with other 3D spatial information models, in terms of their capability for modelling legal interests and legal boundaries as defined in the Victorian jurisdiction in Australia. They found that the LandInfra approach for referencing IFC-based physical elements can be utilised for incorporating physical objects into the Victorian model but they would need to incorporate elements of multiple 3D spatial information models for their final model. LandInfra is also mentioned as one of the potential standards for representing data about underground infrastructure (utilities and other subsurface features) by the OGC Underground Infrastructure Concept Development Study (CDS) to improve the underground infrastructure data interoperability [65]. LandInfra considers wet infrastructure and utilities within its scope [73], its possible alignments with the CityGML Utility Networks ADE [5] and PipelineML [56] were highlighted in the study [65].

There are several papers discussing the integration of LandInfra and InfraGML with other geospatial standards. Important work is being done in this direction by the team at Institut Géographique National (IGN) France for aligning CityGML and InfraGML [12, 17]. Their research investigated the acoustic process and inputs to determine which available data between CityGML and InfraGML is best suited for initial environment acoustic studies [12]. The research also raised several important points such as the lack of flexibility for extensions in the LandInfra conceptual model and the unavailability of real world InfraGML datasets in practice. Devys [17] discussed interoperability, between the RailTopoModel [81] and LandInfra, for railway infrastructure and proposed a mapping between the two models. Labetski et al. [39] analysed the usage of LandInfra as a framework for extending the definition of the LODs for roads in the transportation module of CityGML, but found that the lack of the concept of levels of detail in LandInfra made it irrelevant. [49] also propose to analyse LandInfra in the context of roads but for the purpose of determining limitations in current data standards for road assets and create recommendations towards an improved standard in order to apply SW (Semantic Web) technologies to build a prototype solution for road asset data conflation. As they continued their analysis, [48] found that the use of IFC, IFC Alignment and InfraGML should be considered, as these standards are supported by several industrial software applications. They conclude with the belief that instead of trying to develop yet another road asset information standard there should be an investigation into translation approaches to assists communication between standards [48]. Malmkvist et al. [45] utilised InfraGML and IFC Alignment for the information exchange of road asset data between the design and operation phases of a road project within different software systems.

Comparative analysis between IFC, CityGML, and LandInfra

In this section we analyse the differences and similarities between CityGML, IFC, and LandInfra. These are briefly summarised in Table 1. The comparison of standards is done on the basis of 16 criteria derived from the criteria described in [6, 76, 86]. The first five criteria enlisted in Table 1, namely, Body, Version, Users, Encoding, and Focus describe the general information about the standards e.g. the standardising body, the current version of the standard, its main users, the type of encoding, and the main focus of the standard, respectively. The criteria Geometry discusses the support for different geometries types and semantics in the standards. Semantics indicates the possibility to assign thematic meaning to an object or a group of objects. Topology describes how the topological relationships between the geometries of features are stored in the data model of the standards. Semantics describes the differences in the modelling of feature semantics between IFC, LandInfra, and CityGML. The criteria Metadata, Land use representation, LODs, Appearance, and Extensions evaluates the support for metadata, land use, Levels of Detail (LODs), textures/materials and the possibility for extensions to the data model of the standards, respectively. ‘Software support’ discusses the available software support for the standards which can be useful for the practitioners. The most relevant differences are analysed in more detail in this section.

• 1. Geometry. IFC uses the many geometry types defined in ISO 10303 [28], which include a variety of representation paradigms within IfcShapeRepresentation, such as primitive instancing, CSG, sweeps and B-rep. These paradigms can be used independently or combined with each other in a hierarchy of operations. The elements are usually modelled in local coordinate systems, which are defined by a hierarchical set of transformations based on entities that define local systems (IfcLocalPlacement), axes (IfcAxis2Placement) and 2D/3D vectors (IfcDirection). These systems can correspond to the levels in a decomposition structure (typically a site, project, building and individual floors), or to a series of object locations that are defined based on those below them, among other options. For example, the local placement system of a door may refer to the placement system of the corresponding wall, while that of the wall refers to the building. Global coordinates can be however obtained using the georeferencing information that is sometimes included in IFC files, such as with the latitude, longitude and elevation information in IfcSite.

  Table 1 A comparison of CityGML, IFC and LandInfra

  Meanwhile, CityGML represents elements directly in a single global coordinate system and uses only the B-rep types defined in GML 3.1.1, which represent solids, surfaces, TINs, etc. and are based on the ISO 19107 geometry model with the restriction that only planar and linear geometry types are used. LandInfra is very similar in that it also uses the ISO 19107 geometry model, but it defines new geometry types such as IndexedPoint, PolyfaceMesh, and SimpleIndexedPolygon in its conceptual model. InfraGML uses GML 3.2 for solids and surfaces, and GML 3.3 for triangles and TINs.

  Despite the fact that the latter two standards use GML, there are still differences between them. For example, CityGML represents TINs as a triangulated surface (gml:TriangulatedSurface) with triangles specified with a Simple Features geometry (gml:Triangle). In the Simple Feature structure, the first vertex of every linear ring (triangle/polygon) is repeated as the last vertex of the linear ring. On the other hand, InfraGML uses GML 3.3 where a TIN is represented as a collection of gmltin:SimpleTrianglePatch. It is based upon the GML 3.3 SimpleTriangle, rather than the GML 3.1.1 or GML 3.2 Triangle [53] and avoids the repetition of first vertex as the last vertex in each triangle.

  As another example, LandInfra defines a ‘Polyface Mesh’ geometry to compactly represent the boundary of a solid. A Polyface Mesh in LandInfra stores every surface (triangle/polygon) of a solid as references to the IDs of the vertices forming that surface (see InfraGML snippet below for implementation). The vertices are stored in a separate list with their IDs and are not repeated for every triangle like in Simple Features. CityGML supports no such geometry in the actual model. However, CityGML iTINs ADE² implemented new geometry types in the GML schema which are extended to existing CityGML features for compact representation of massive TINs, up to a factor of around 20 [36].

  

  Furthermore, LandInfra supports the concept of an Alignment for linear construction works, such as roads and rails, which is similar to IfcAlignment [55]. The simplest geometry representation for an alignment is a 2D straight line, but an alignment can consist of multiple segments which are connected, i.e. from the end of one to the start of the next. Since there is no requirement that a segment should be tangentially continuous with the next one, the transition from one segment to the other can be jerky when using straight lines for representing these segments. However, it is often recommended to smooth out the transitions using a circular curve, clothoid, or another spiral for design and construction, which are supported by the LandInfra Alignment class, similar to IfcAlignment [55]. These geometry types, which are taken from the OGC Abstract Specification Topic 1 (Feature Geometry in LandInfra), and are not supported in CityGML.

• 2. Topology. Topology in BIM usually refers to hierarchical geometric representations like CSG or Half-space intersection models. However, IFC also contains several topological relationships in a GIS sense. Elements are expected to be connected to their openings (IfcOpeningElement) and coverings (IfcCovering), and there are also various connections between related elements defined using the connectivity relationship IfcRelConnects, such as with ports (IfcPort) and the structural members of an element (IfcStructuralMember).

  CityGML uses the concept of XLinks provided by GML to store only once a surface shared by two objects. For example, if a wall (bldg:WallSurface) is shared by two different buildings, then its ID can be referenced by the other building using XLinks. This mechanism is however not mandatory [52] and a CityGML dataset can contain repetition of multiple identical geometries [8]. No other topological relationship e.g. adjacency or incidence can be explicitly stored in the model.

  LandInfra conceptual model uses the same concept of XLinks for sharing of surfaces among features. It is also possible to link all the facility parts (lif:FacilityPart) to the facility (lif:Facility) they belong to using Xlinks (see InfraGML snippet below for implementation). Further, relationship between different facility parts can be specified using XLinks.

  

• 3. Semantics. There are clear differences in the modelling of feature semantics between IFC, LandInfra and CityGML. For example, a building in CityGML can be subdivided into semantic surfaces such as roofs, walls, doors, and windows. In IFC, it would instead be subdivided into the elements used in its construction, such as slabs, columns and beams, as well as fittings like windows, stairs and doors. Neither of these are possible in LandInfra.

  All three standards exhibit coherence between the semantics and the geometry of the objects they model. For instance, in CityGML, if the hierarchical decompositions of semantics and geometry depict the same structure, then they are considered coherent [52, 75]. For example, a building represented as a gml:CompositeSolid can be decomposed into two building parts, each of which is a gml:Solid. This is similar to IFC, since many building elements (i.e. IfcElement and its subtypes) have a concrete semantic meaning in theory, such as the subtypes of IfcBuildingElement: IfcCovering, IfcBeam, IfcColumn, IfcCurtainWall, IfcDoor, IfcMember, IfcRailing, IfcRamp, IfcRampFlight, IfcWall, IfcSlab, IfcStairFlight, IfcWindow, IfcStair, IfcRoof, IfcPile, IfcFooting, and IfcPlate. However, these are inconsistently used in practice, and software often just exports generic types like IfcBuildingElementProxy instead.

  LandInfra also exhibits coherence between semantics and geometry of features in its data model. In Fig. 3, a Facility (represented as a gml:MultiSolid in InfraGML) is decomposed into two FacilityPart(s). A facility part can either be a building, a road or a railway feature. If the two FacilityPart(s) are the same, e.g. buildings with gml:Solid geometry, then the hierarchical decomposition of geometry is structured similarly to CityGML. However, there is no (or partial) coherence if the facility parts are different with different geometry, e.g. a building with gml:Solid geometry and a road with gml:MultiSurface geometry.

  Fig. 3

  

  Geometric-semantic coherence in the LandInfra Facility class

  Additionally, even as there are many similarities between the LandInfra feature types and the CityGML thematic classes, they are not always grouped in the same way and also have different names for the same concepts. For example, LandInfra separates Roads and Railways while CityGML groups the two in the Transportation thematic module.

• 4. Metadata. Metadata is extensively used in IFC, but it is not used in a consistent manner by different software. For basic information, the IFC standard provides specific entries for the header of an IFC file (FILE_DESCRIPTION, FILE_NAME, FILE_SCHEMA), as well as specific entities in the body of the file, such as IfcOrganization, IfcPerson and IfcPostalAddress. Additional information is usually added through a reference (e.g. IfcDocumentInformation) to an external document. The reference captures metadata of the external file (e.g. document IDs, author, description, purpose and timestamps), and the metadata of the IFC file is contained in the external document. For instance, the latter process is often done to add scheduling and construction information in IFC files.

  In CityGML, there is very basic support for metadata using gml:metaDataProperty inherited from GML3 and is not ISO 19115 compliant [29]. GML does not provide an information model for metadata, instead a mechanism to include or reference metadata is provided [51]. A 3D Metadata ADE³ was recently developed focusing on adding metadata related to 3D city models in CityGML [38]. It incorporates ISO 19115 metadata elements and several other elements related to 3D city models such as LODs, feature count, and metadata related to CityGML thematic models. LandInfra has ISO 19115 compliant metadata to describe the geospatial dataset and sensor observations (see the InfraGML snippet below for implementation).

  

• 5. LODs (Levels of Detail). CityGML supports 5 different LODs, from LOD0 to LOD4 for multi-representation of 3D city objects. In CityGML, the concept of LODs is very well established for buildings and bridges. For instance, LOD0 for a building is a 2D footprint, LOD1 is a block model generated by extruding the footprint, LOD2 is an upgraded LOD1 model with roof structure and semantically differentiated boundary surfaces, LOD3 are architecturally detailed models, and LOD4 models contain information about the interior of an object (see Fig. 4). Biljecki [9] proposed an improved LOD specification for buildings, however, it is not a part of the current CityGML specifications.

  Fig. 4

  

  A building represented in LOD0 to LOD4 in CityGML (Source: [7])

  IFC files usually contain building models only in very high detail. Since BIM focuses on information about the design and construction of building sites, it thus usually has very geometrically complex and semantically rich information about the buildings [2]. However, they can also contain 2D architectural floor plans as well as the usual 3D building models in one file [2]. However, regarding BIM models in general, there is the concept of the level of development (also abbreviated as LOD), which represents a model in the typical stages that it goes through. These include everything from its conception, detailed design, construction and the as-built model for facilities management. As the model gets progressively more detailed in these stages, the concept is indirectly related to the level of detail in it.

  LODs are not supported in LandInfra.

• 6. Extensions. It is possible to extend the CityGML model using Generic city objects or ADEs [11]. Extensions and Generics are not supported in LandInfra. IFC models can be extended using property sets, proxy elements, and by defining new entities or types [82]. Several researchers have defined their own IFC extensions using these "de facto" methods, e.g. IFC extension to estimate the construction cost of buildings by [85], IFC extension to incorporate information of RFID tags attached to building elements in IFC by [46] and so on.

• 7. Appearance (Textures & Materials). IFC has wide support for appearance in two ways: for design and construction purposes through IfcMaterial (e.g. to know its mechanical or fire resistance capabilities stored as IfcMaterialProperties), and for visualisation purposes through IfcMaterialDefinitionRepresentation. CityGML draws concepts from both X3D [27, 31] and COLLADA [4] for material and texture information of city objects [52], LandInfra does not support textures nor materials.

• 8. Software Usage & Support. LandInfra conceptual model was accepted as an OGC standard in 2016. Its GML encoding (InfraGML 1.0) became a standard later in 2017. In spite of a stable release, there is no software support available, that we know of, to parse, visualize, and use InfraGML.

  On the other hand, a number of software packages and libraries are available which can be useful for practitioners and researchers dealing with CityGML. Most of the software are recent and well-maintained. For instance, citygml4j⁴ is an open source Java library for reading/writing CityGML datasets; 3D City Database [84] is a database solution to store, and manage CityGML models on top of a standard spatial relational database (PostGIS and Oracle); azul⁵ and FZK⁶ are popular CityGML viewers for macOS and Windows, respectively and so on. [16] provides a list of available software for CityGML.

  IFC has the widest usage and software support among these standards, but the standard is implemented inconsistently by different software, which limits compatibility in practice. In particular, most BIM and building design software can export from its native (internal) formats to IFC, but there is a degree of information loss while doing so. Importing from IFC is known to be even more problematic, as arguably less effort has been put into this process. Recently, a GeoBIM software compatibility benchmark⁷ was funded to assess all of these issues in more detail. Some of the well known open-source projects for IFC include IfcOpenShell⁸, BiMserver⁹, etc. [23] provides a list of available software for IFC.

• 9. Codelists. While both CityGML and LandInfra define their code lists in accordance with ISO 19103 — Geographic information — Conceptual schema language [30], neither follows a standard in naming conventions which makes mapping between similar code lists impossible. This means that there may be significant overlap between two code lists and thus unnecessary duplication. There is a further risk of a specific terminology being utilised twice but with differing definition or meaning. The issue of standardising code lists and enumerations is described further in the work of [78].

  Meanwhile, IFC only has support for enumerations, but the standard does contain a lot of them (207 in IFC4 Addendum 2), and they have similar extensibility to codelists because they contain specific definitions for user-defined and undefined types.

• 10. Land use representation. CityGML only represents the division of the Earth’s surface according to specific land use e.g. residential, industrial, and so on. LandInfra uses ISO 19152:2012 Land Administration Domain Model (LADM) [26] which offers a rich conceptual scheme for recording of interests in land including above and below the ground surface, ownership, rights, restrictions, and so on [55]. Since IFC focuses on specific building sites, land use is typically not a concern.

Use cases benefiting from BIM-GIS integration through LandInfra

Some use cases for LandInfra are included in the official documentation [55] of the standard: road alignments, surveying, conversions between LandXML and InfraGML, storage of terrain data, land division, and representation of railway features. However, these are described only at a superficial level, vaguely explaining broad cases where the standard could be used for (rather than how) and omitting any technical details. Moreover, it is a relatively new standard, and at present, we do not know of any concrete examples of its usage in real world applications.

That being said, we believe that there is potential for LandInfra in many areas. For instance, buildings are currently the main focus of the integration of BIM and GIS [2], while other features, e.g. terrain, vegetation, roads, water bodies, bridges, etc. are often ignored. This is something that can change with LandInfra, since it covers all the aforementioned city features and provides extensive semantic information for land and infrastructure features.

As a way to contribute to this discussion, we present here three potential use cases where LandInfra can act as a “connecting bridge” between BIM & GIS.

• 1. 3D Cadastre: 3D Digital management of property interests in the building complexes

  The land administration organizations in different countries, such as the Netherlands, Norway, Germany, Australia, have investigated a 3D approach to digitally manage information about the ownership rights of properties/units within building complexes, see e.g. [77]. Digital management of property interests in 3D mainly requires legal information (ownership, boundaries, is it public/private?) and physical information (location, semantics, and 3D geometry) about the property [3]. BIM can provide highly detailed 3D physical information about the buildings. However, IFC currently lacks a standardised way to internally represent the legal information of a building site encompassing many properties, such as condominium boundaries, which is the core of land administration information [3]. CityGML can provide physical information about the buildings and other surrounding features such as terrain, roads, tunnels, but the representation of legal extents and rights is not explicitly covered in the standard.

  There has been significant amount of research over the past decade on the integration of legal information with 3D physical models for the management of property rights. For instance, [70] proposed the CityGML LADM ADE (Land Administration Domain Model) to represent the legal ownership of buildings and their parts in CityGML in accordance with ISO 19152-LADM standard [26]. Similarly, [3] proposed an extension to IFC to manage legal information about the buildings in 3D. However, most of the available land administration research with IFC and CityGML is centred around buildings.

  LandInfra provides a step further in this direction by not confining the ownership of the land to buildings or building parts. Traditional 2D cadastre is supported, as well as the newer 3D land ownership exemplified by condominiums with 3D parcels. Cadastral information and ownership rights in LandInfra can also be associated with subsurface infrastructure such as underground tunnels and pipelines (utility networks) [55].

  LandInfra core requirement class LandDivison deals with cadastral information and is based on ISO 19152-LADM standard. LandInfra class SuperficieObject models buildings and other constructions including tunnels, pipelines, or cables, established/owned by a party (other than the owners of the land parcels on which they are constructed) according to a valid document i.e. a Statement. The XML snippet given below depicts the cadastral information about a tunnel (gml:id = ~so1~) across two land parcels (gml:id = ~lp1~ and ~lp2~) depicted in Fig. 5.

  Fig. 5

  

  A tunnel (SuperficieObject) across two land parcels [55]

  

• 2. Subsurface geological modelling

  Data about the geological subsurface such as type of soil, its porosity and depth, bedrock layers, etc. provides important information about the conditions of the ground. This data is of crucial interest for projects which involve shallow or deep digging of the ground, such as building construction, excavation, etc. [87]. By including such information in the design stage, risks of accidents can be better handled and costs can be reduced significantly. The abundance of aboveground 3D city models often overlooks the fact that the cities and their infrastructures are not lying on a “flying carpet”. We need holistic modelling of cities in 3D with integrated subsurface information.

  GIS standards (such as the OGC standard CityGML) or BIM standards (such as IFC) are not designed to work with real world subsurface data originating from the 3D geological models [87], even if some work has been done to model such information in integrated models [22, 80], as well as in IFC [18].

  The standard LandInfra includes support for topography (terrain) as well as subsurface information in its requirement class LandFeature [55]. The class LandFeature has 3 main subclasses: LandElement, LandSurface, and LandLayer. The LandElement class focuses mostly on the representation of topographic features of the land such as water body and vegetation [55].

  The classes of interest for modelling subsurfaces in LandInfra are LandSurface and LandLayer. The class LandSurface can be used to specify the surface of the terrain of an area and the boundary between two subsurface layers as TIN (Triangulated Irregular Network) (see snippet below) [55]. It also has an additional attribute material to specify the material of the surface.

  

  Below the land surface, the land comprises of layers formed of different materials. These material layers are specified in LandInfra by the abstract class LandLayer [55]. They can be represented in 3 ways:

  • (a) as a 3D polyface mesh solid (SolidLayer),

    

  • (b) by specifying a top and bottom horizontal surface (i.e. a LandSurface) with TIN spatial representation (SurfacesLayer). A resultant solid shape is implied between these two layers representing the material layer.

    

  • (c) by a set of vertical 2D cross sections of the layer (LinearLayer). A LinearLayer is represented by at least two 2D cross sections (LandCrossSection) at a specific location along a linear element of reference (LinearElement) [55]. Each cross section is divided into cross section areas (CrossSectionAreas) of a particular kind of material by means of cross section points (crossSectionPoint).

    

• 3. Surveying

  [10] highlighted that the choices made by the practitioners when acquiring and processing data for generating 3D city models are rarely documented in a dataset, mostly because there is no standardised way of storing it. GIS standards (such as the OGC standard CityGML) or BIM standards (such as IFC) do not offer a mechanism to store such data in a structured way. The LandInfra Survey requirements class provides a framework to model information about observations, equipments used, processing, and the results collected by a survey such as laser scanning or photogrammetric survey. It is based on the OGC standard SensorML (Sensor Model Language) [54]. It has 3 main classes, namely, SurveyObservation, Equipment, and SurveyResults and provides:

  • (a) storage of metadata about the survey e.g. type and purpose of survey, information about the surveyor, and so on (class Survey).

  • (b) storage of information about the location of observation points, set-up method, accuracy information, and so on (class SurveyObservation).

  • (c) explicit modelling of the information about the sensor(s) used for each observation in a survey (Equipment).

  • (d) storage of the results of the survey (class SurveyResults)

Evaluation of use cases

From the use cases (e.g. 3D cadastre, subsurface modelling, and surveying) we can make several observations regarding the advantages of LandInfra over CityGML or IFC. IFC and CityGML focus on different domains: IFC on design and construction (BIM) and CityGML on city modelling for spatial analysis (GIS), which does not provide an easy solution for integration. Further, CityGML can provide physical information about the buildings and other surrounding features, such as terrain, roads, tunnels, etc., but it does not cover the representation of legal extents and the rights of features. IFC similarly lacks a standardised way to represent the legal information of a building. Moreover, both CityGML and IFC do not model real world subsurface data originating from geological models. It is also not possible to store the data collected by a survey, such as laser scanning or photogrammetric surveys, in CityGML or IFC. LandInfra meets these shortcomings by incorporating all of these concepts in one model.

Another advantage of LandInfra for these use cases is that the integration is solved within one official standard and no additional software support is needed for these use cases. Modelling these use cases in IFC and CityGML would require creating an extension to the original data models of these standards, i.e. using ADEs or Generics in CityGML, and Property Sets in IFC. This would require the development of additional software support to handle such CityGML and IFC datasets. Furthermore, these extensions are essentially ‘trial balloons’ and are not official standards. They could be developed by anyone using different naming conventions and different geometric and semantic notations [11]. Problems related to data interoperability between IFC and CityGML would still exist.

LandInfra provides a step closer in the integration of BIM and GIS by integrating these concepts in its data model to provide extensive semantic data for land and infrastructure features. Further, LandInfra is an official standard of the OGC, unlike CityGML or IFC extensions. As such, LandInfra can act as a connecting bridge between BIM and GIS for applications that need both types of data as shown in the use cases. It is an important open standard for the integration of geoinformation and the information about the built environment. LandInfra can offer richer and more insightful information and deliverables to civil engineers, designers, architects, surveyors, 3D city modellers, and other stakeholders to create accurate, reusable, and interoperable 3D city models.

Minor practical issues with LandInfra and InfraGML

During the course of our evaluation of LandInfra for BIM-GIS integration, we encountered some issues which we believe are of concern when using the standard in real world applications.

• 1. In Section 7.9.4 of the LandInfra specifications document, it is mentioned that “LandLayer is an abstract class”. However, it is implemented as a concrete class in InfraGML and can be instantiated.

• 2. InfraGML is developed as a multi-part standard and each part has a separate XML schema file (XSD). When trying to validate an InfraGML dataset containing more than one type of requirement class (such as Facilities with LandSurface) against one XSD, validation errors are reported. A ‘wrapper schema’ (like in CityGML) which links the XSDs of all the parts of InfraGML is missing.

• 3. LandInfra Document class contains ‘information in permanent form approved by one or more signature’ [55]. It is derived from LandInfra Feature class and therefore has an optional spatial representation (spatialRepresentation). It is not clear what the spatial representation of a document could be: that described in the document, the spatial location where the document is located, or other possible interpretations.

• 4. Given that the facilities, such as Roads, inherit the spatialRepresentation property from the LandInfra Feature this means that the representation type of facilities is not restricted by type, but instead can utilise any geometry type that is supported by spatialRepresentation. This can lead to unrealistic representation types that validate under the current schema, such as a road modelled as a point.

• 5. LandInfra includes future proposed classes directly in the current UML schema which can be confusing to interpret and can potentially give the impression of a false claim of completeness. For example Facility requirement class has 8 proposed future classes, namely, Bridge, Drainage, Environmental, Site, Tunnel, Wastewater, WaterDistribution and OtherFacility. Additionally it seems unrealistic to propose future classes mixed directly with current classes without having tested and received feedback for the current classes. This may discourage contribution from potential collaborators by providing a false sense of finality of future versions of LandInfra.

Conclusions and future work

The article presents a detailed comparison of the LandInfra conceptual model with CityGML and IFC, and three potential use cases for LandInfra in practice. As an open standard at the junction of BIM and GIS, LandInfra is uniquely situated to act as a “connecting bridge” for BIM-GIS integration. Its good support for metadata, land division, and the ISO 19107 geometry types are all positive aspects of the standard, as is the involvement of buildingSMART and practitioners in the development of the standard. The three use cases we presented, where LandInfra could act as a link between BIM & GIS in practice, show that, in theory, 3D cadastres, subsurface geological modelling, and surveying are all interesting applications for LandInfra, and there are many more potential ones.

However, it is hard to claim that LandInfra is the answer to many BIM-GIS integration problems at present. First, as it stands, LandInfra is clearly a standard that is much closer to the standards of 3D GIS than to how objects are modelled in BIM world, which in practice will greatly limit its interoperability with BIM formats like IFC. Second, the data model of LandInfra cannot be extended or modified, which limits its use in practice especially since it aims as bridging different communities. Third, the current lack of example usage and available InfraGML datasets makes extensive testing and validation difficult. The fact that there is no software packages to read/write, edit, or manipulate LandInfra makes it rather difficult to convince practitioners to convert their datasets to it. We fear that without a push for open implementations and greater concern for the implementability of the standard, there is a danger that the standard will languish and be unused, as has been the case with a few OGC open standards.

In order to avoid this last issue, we are working on two solutions: (i) a LandInfra ADE for CityGML, which will encourage the adoption of LandInfra’s features, and (ii) InfraJSON, a JSON 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, GML is a bulky and cumbersome encoding that is hard to use, and thus it is often disliked by both users and developers [41, 79]. By contrast, JSON provides an easy-to-use and easy-to-read alternative, such as with CityJSON¹⁰, which is a JSON based encoding of CityGML.