The integration of Building Information Modeling (BIM) and Geographic Information System (GIS) remains a significant challenge in the Architecture, Engineering and Construction (AEC) industry. Container-based methods for linked data exchange in the construction domain, such as the Information Container for Linked Document Delivery (ICDD) and the Multi-Model-Container (MMC) standards, might support the BIM and GIS integration process. To address the specific challenges posed by the integration of BIM and GIS, it is necessary to connect geodata in a context-sensitive manner to satisfy distinct requirements. This paper presents four diferent link types in order to create more meaningful connections between datasets: geospatial, geometrical, topological, and mereological links. It furthermore proposes an extension to the MMC schema, a standard defined by the German standard DIN 18290-1, to improve interoperability between the BIM and GIS domains. The MMC facilitates modular and structured data exchange by linking heterogeneous models while preserving their independence. However, its limitations in semantic linking and BIM-GIS domain relationships require further development. To address these challenges, the proposed schema extension includes methods for defining geometric transformation parameters, geospatial relationships, and part-whole associations. The practicality and applicability of the proposed extensions are illustrated through use cases that involve the integration of diverse datasets such as cadastral, surveying, and environmental noise data with building models.
In the construction industry, numerous federated application models from architecture, construction, and facility management are tendered, ordered, created, checked, and jointly analyzed using the Building Information Modeling (BIM) method. With Geographic Information System (GIS), various models such as cadastres, terrain models, city models, land management models, trafic infrastructure, pipelines, environmental data, or demographic data are acquired, managed, analyzed, and presented in geospatial data management. The integration of both domains allows for a more comprehensive understanding of projects within their broader geographical context, enabling better decision-making and improved digital eficiency throughout the project lifecycle and asset management. However, to successfully make use of their joint merits to solve complex tasks and problems in the construction industry, urban planning, or disaster management, their heterogeneous, domain-specific data needs to be contextualised.
There are well-established software systems and expert knowledge for this type of heterogeneous
collaboration [
The use of linked BIM-GIS data, as opposed to repeated conversions between difering data schemas, may help to reduce manual efort and data redundancy, while supporting a more consistent contextualization of the originary data from both worlds. This paper applies the German DIN 18290-1 (Multi-Model-Container (MMC)) as a linking framework to persist and formalize the results of crossmodel computations. These include geospatial, geometrical, topological and mereological relationships. The resulting link model could be exchanged and interpreted by diferent software systems. The authors assume that platforms like Common Data Environment (CDE), BIM coordination tools, BIM model checker, or 3D-Web-GIS could make efective use of a standardized approach to semantically-rich and use case-specific link models.
This section highlights some of the notable works related to BIM-GIS interoperability, and then focuses on related research and standards, addressing the concept of container-based exchange in general.
The Open Geospatial Consortium (OGC), buildingSMART International (bSI) and the International
Organization for Standardization (ISO) address the interoperability as a subject of geometric-semantic
information models, which are jointly used by the Architecture, Engineering and Construction (AEC)
and geospatial domains. These organisations often use the technically misleading, but however common,
term BIM-GIS interoperability. Strictly speaking, the method BIM would be more in line with the term
geospatial information management (GIM), and the GIS tools would be more in line with
ComputerAided Design (CAD)/BIM authoring systems and BIM coordination software [
The OGC and bSI strategic roadmap for enabling information continuity across BIM-GIS domains [
Numerous academic meta-studies cover BIM-GIS interoperability, but each from a very diferent
perspective: Some distinguish BIM and GIS in terms of model intention, user type, use cases, software,
semantic and geometric representation, and spatial scale, highlighting interoperability challenges at
data level, process level, and application level [
The EuroSDR GeoBIM study [
In addition to the many current academic approaches based on ontologies and the semantic-web
technology stack [
Standards for container-based information exchange, such as the German DIN 18290 (MMC), as well as
ISO 21597 (Information Container for Linked Document Delivery (ICDD)), define frameworks to ensure
structured and interoperable data exchange across various phases of a project lifecycle. These containers
serve as digital vessels for organizing, storing, and transmitting information in a way that enhances
collaboration and minimizes miscommunication. There are several core ideas for a container-based
exchange, however, Esser and Borrmann [
The Dutch COINS project has gained prominence as an open standard that provides a flexible data
exchange format for BIM which annotates data utilizing an OWL-based ontology [
The findings from both projects, MEFISTO and COINS, were later incorporated into the development
of the ICDD [
Generic MMC link and store application models and files from various domains that contain semantically
equivalent information in order to serialize and exchange knowledge [
ApplicationModel + id: String + modelType: String
1..*
ModelData + id: String + formatType: String + formatVersion: String
1..*
DataRecource + id: String + location: anyURI 0..1 0..1 0..1
MultiModel + uuid: String + formatVersion: String = "2.1.0" 1..* + mmDomain: anyURI 0..1
1..* MetaData 1..*
Meta + key: String + value: String + type: String + category: String
LinkModel 0..1 + LinkedModel: String[] + location: anyURI
LinkModel
LinkModel + formatVersion: String = "2.1.0" 1..* 0..1 Link 2..*
Relatum + id: String + modelId: String + formatId: String + resourceId: String 0..*
Rate + type: String + value: String + modelId: String 0..1 0..1
MetaData 1..*
Meta
+ key: String
+ value: String
+ type: String
+ category: String
specialist models in Building Information Modeling (multi-model container)" [
Each MMC consists of at least two models and/or documents from diferent domains and two documents that can be described in Extensible Markup Language (XML). The standard provides XML schemas for the multi-model and link-model parts together with optional metadata (Figure 1). The multi-model file contains a XML-based content description of all the domain models and their documents stored in the container using metadata. The link model file contains all the id-based links in the container. Links can be general, if they are between models or documents, or they can be more detailed, if they are between uniquely identifiable elements of models or documents. Additional information about the exchange can be added as metadata using the generic attributes @key and @value. Some required attributes are defined in the standard. For example, IFC models require a "fileFormat" attribute with one of the predefined values.
The containers enable software to exchange internally defined links between elements of diferent models. The MMC is exchanged as a ZIP archive with the extension ".mmc". Parts 2 to 4 of DIN 18290 define specialized MMCs for the exchange for bill of quantities, cost determinations and accounting.
In comparison, both standards, ICDD and MMC, have individual advantages and disadvantages, even though they were designed to serve similar purposes.
ICDD strongly supports linked data principles by making use of ontologies and related technologies (e.g. RDF, Uniform Resource Identifiers (URIs)) and is therefore well-suited for complex and data-rich exchange scenarios. However, the hurdles for an industry adoption are high due to the complexity of the standard and the necessity for an in-depth understanding of the mechanisms and principles used within. Industry adoption and tool support outside the research area is very limited and the profitability of applying the ICDD also to small projects appears questionable, as it adds unnecessary intricacy and overhead.
On the other hand, the MMC standard in its current form has only limited semantic linking capabilities,
making it less efective than ICDD for creating detailed relationships between datasets. However, the
MMCs simpler structure makes it easier to understand and implement as it relies only on XML as a
technology. Most software can read these XML structures. Parts 2 to 4 of DIN 18290 have been adopted
by several German industry tools [
The challenge of linking heterogeneous files, particularly when one or more files lack indexed data or unique identifiers, presents a significant obstacle in data integration and interoperability. This issue is especially prevalent when attempting to connect diverse data sources such as point clouds, gepsptaial raster data, and BIM models.
Furthermore, not only does the absence of identifiers prevent linking, but often the models have a completely disjoint universe of discourse, so there are no equivalent real-world objects to link at all.
The absence of both, linkable equivalent objects and indices, necessitates the use of alternative linking methods based on coincident characteristics of the data. For a BIM- and GIS- interoperability, these coincident characteristics may be categorized as being geospatial, geometrical, topological or mereological.
This paper proposes an extension of the MMC standard that allows to create more diverse, meaningful links between BIM- and GIS-specific input data, while maintaining application simplicity. Four link types as an extension to the current MMC schema are proposed and their utilization in diferent scenarios is presented. 4. An MMC-Schema Extension for BIM-GIS Exchange Initially, this section explains the general concepts and constraints within the MMC schema, which relate to the implementation of all proposed link types. In the subsequent subsections, the link types are explained in detail, as well as their implemention within the MMC schema.
The MMC schema in its current form allows two types of linking: linking between clearly identifiable
(and therefore indexed) elements and linking to an application model as a whole [
• Mereological Link: Mechanisms for capturing part-whole cross-model relationships.
The extended multi-model container should support the transfer of geometrical discipline-specific application models, such as 3D building models, 2D floor plans, 2.5D terrain models, 3D city models, 3D point clouds, and the BIM Collaboration Format (BCF). These models can originate in diverse 2D/3D geodetic coordinate reference systems or local cartesian systems. The software reading the multi-model container should extract the geometric transformation parameters and metadata needed to position these application models correctly in a common coordinate system.
Georeferencing is a quite complex topic, so some constraints are defined, to maintain simplicity in the BIM-GIS-MMC (Figure 2): • Geospatial_MultiModel:wktCrs is the only (singleton) and most outer Coordinate Reference Geospatial Link
Extension
MultiModel
Link
Relatum
Extends Geospatial_MultiModel + wktCrs: String
<<enumeration>> Link_Type_Geospatial useMmcWktCrs useRelatumWktCrs pose geodeticOperation
Extends
Geospatial_Link + type: Link_Type_Geospatial + outerPose:Pose + wktOperation:String
Pose
+ origin: double[
Extends
Geospatial_Relatum + type: Relatum_Type_Geospatial + innerPose:Pose + innerPoseId:String + wktCrs:String
<<enumeration>>
Relatum_Type_Geospatial directPosition innerPose innerPoseId wktCrs System (CRS) for this MMC, which is parameterized as an OGC Well-Known Text (WKT)1, avoiding ambiguous string representations of EPSG-Codes, proj-Strings or software specific schemas. • An ApplicationModel (Figure 1) must not use multiple geospatial CRSs. • ApplicationModels (Figure 1), including geospatial data, are stored as a file, hence, the BIM
GIS-MMC must not contain any URLs to dynamic geospatial web services. • In contrast to normal MMC-links, Geospatial_Link must have exactly two Relatums: A static modelID =”mmc” and an modelID indicating the related ApplicationModel instance. The schema allows for some variants to address possible application model heterogeneity: • The coordinate operation from the ApplicationModel’s to the MultiModel’s CRS is stored in Geospatial_Link, either as: – outerPose, parameterized as a simple rigid body transformation providing origin, cartesian axis, and scales (aka. coordinate base in the MMC-CRS) xor – operationWktCrs, parameterized as geodetic operation, that may include a well geodetic defined datum transformation and map projection xor – uses Link_Type_Geospatial to indicate that the related application model either has the useMmcCrs or useRelatumCrs. • The geometric origin of the related ApplicationModel model can either be – assumed implicitly to be 0,0,0 for the whole document (default) as directPosition xor – be specifed as innerPose such like an project coordinate ofset xor – be specified as deep linked using innerPoseId (such as IfcSite, IfcSpatialElement, IfcGeometricRepresentationContext, IfcProjectedCRS) xor – be specified as a geospatial wktCrs String.
While modeling in BIM involves comparatively simple and structured geometric objects (e.g., components of a building), GIS data may involve much larger datasets if rasters or point clouds are used. 3D point clouds (raster for 2D data) are described by a much larger number of points than abstracted CAD data and are not structured by component IDs. The linking of a subset of such a data set is therefore not possible based on IDs. To avoid structuring within the data, links to subsets of a point cloud are expressed by boundaries that are defined within a link. A processing application has to interpret these boundaries and be able to process the point cloud data in a corresponding way. This prevents data redundancy on the container side because the original data is kept without modification. Additionally, a targeted structure for the required subsets of large point cloud data is created.
The definition of a boundary in a link contains three elements (Figure 4a): • wkt is a valid WKT string for a geometry of type POLYGON or of type MULTIPOLYGON that defines the boundary footprint. • min is a float number that defines the minimum height value of the boundary which would be in z-direction according to the common practice. This value is optional in the boundary definition.
• max is the corresponding maximum height of the boundary and is also an optional attribute.
If no values for min and/or max are defined, the upper or lower limit of the boundary remains open. The 3D geometry is built from the extrusion of the WKT string from and to these limits as shown in Figure 3. Thus, it is possible to reference to 2D map elements as well as 3D model objects. Limitations of this method occur when representing concave 3D objects or objects with openings because of the less accurate approximation of the object surface as known from the convex hull of such objects.
While geometric transformations between diferent data models often prove challenging due to diverse digital representations, topology ofers a more reliable foundation. The concept relies on analyzing three key components of geometric elements: interior (points within), boundary (edge points), and exterior (points outside). This forms the basis for describing geospatial relationships between geometric objects, independent of their specific model representations.
The dimensionality of the linked elements plays a crucial role in determining valid topological relationships: • 0D elements (points): Building nodes, survey points • 1D elements (lines): Utility networks, boundaries • 2D elements (surfaces): Building footprints, land parcels • 3D elements (volumes): Building bodies, underground structures Topological links efectively express neighboring relationships between BIM and GIS models without requiring geometric transformations. Standards like Building Topology Ontology (BOT) and IndoorGML already provide frameworks for graph-like relationships but need connections to external data sources. The presented extended container-based multi-model approach focuses on maintaining relationships between elements through the Topological_Link (Figure 4b), which has two essential properties: • predicate: Defines the type of geospatial relationship (e.g., contains, within, overlaps) • from: A string attribute to identify the source element
To describe a topological link, the Dimensionally Extended 9-Intersection Model (DE-9IM) predicates are implemented in the proposed schema extensions as adjacency relationships (Figure 4b). The predicates consider both the dimensionality of the elements and their interior-boundary-exterior relationships, enabling a precise description of geospatial relationships between elements of diferent dimensions and domains.
Example use cases demonstrating dimensional relationships include: • 3D-2D: Linking a building volume (BIM) to its corresponding land parcel (GIS) • 3D-3D: Connecting building components to underground infrastructure • 2D-1D: Relating building footprints to utility networks • 3D-1D: Establishing relationships between building volumes and transportation networks The dimensionally-aware approach using DE-9IM predicates provides a standardized way to describe geospatial relationships between elements of any dimension, enabling robust cross-domain integration without complex geometric transformations.
GeoEmxetetrnisciaolnLink
Topological Link
Extension
Mereological Link
Extension
Link
Extends
Mereological_Link + relationType: Mereological_Relation + from: String
<<enumeration>> Mereological_Relation partOf hasPart coincidesPartiallyWith coincides Link
Extends
Geometrical_Link + wkt: String + min: float + max: float (a) Geometrical
Link
Extends
Topological_Link + predicate: DE-9IM_Predicates + from: String <<enumeration>>
DE-9IM_Predicates equals disjoint intersects touches contains within overlaps covers crosses (b) Topological (c) Mereological
The mereological link (Figure 4c) describes a part-whole relationship between two instances or models. When linking BIM and GIS data, direct geometric or semantic equivalence is often dificult to establish, particularly due to diferences in data models, varying levels of detail, or incomplete datasets. A mereological link enables the association of subparts of a dataset (e.g., a segment of a point cloud) with corresponding objects in a building model. This approach allows for meaningful connections even in the absence of semantic alignment regarding object types, diferences in data granularity, or inconsistencies in geometric completeness and geospatial alignment between data sources. A mereological link can also serve to link difering representations of the same concept to each other, e.g. a detailed 3D building model to its representation as a cubature in a 3D city model.
The following mereological relation types are proposed: • partOf describes from the perspective of an instance that it’s part of a whole. E.g. a subset of a point cloud represents a part of a building component. As this relationship includes a direction (point cloud segment -> building component), the string attribute from needs to be specified. • hasPart describes the inverse of partOf. E.g. a building component has a part, which is represented within a subset of a point cloud. • coincidesPartiallyWith describes a partial mereological equivalence. E.g. a building model and a point cloud represent the same building, but some components in one model are absent or difer in the other, as the building was partly renewed. • coincides describes a mereological equivalence. E.g. a complete point cloud of a building component is represented as well by a 3D geometric model component, without having added or removed parts of it.
This chapter describes an exemplary scenario with an as-planned building model (.ifc) as the central component. In addition to the 3D building model, cadastral data (.dxf) is available for the property, which contain information about the parcel itself and the neighboring parcels. The neighboring buildings are freely available in a city model (.gml) with a Level of Detail 2 (LOD2). Furthermore, digital terrain data (.xyz, .obj) and noise maps (.geoJSON) of the nearby trafic routes are included for the surrounding area. As the scenario considers the construction process over time, point clouds (.xyz) of the site will be utilized for construction progress monitoring. 5.1. Construction Progress Monitoring using Survey Data and Building Models This case study will demonstrate the use of geometric links to derive a construction progression state from an IFC model and a point cloud of a construction site. Some more examples of applications of geometric links using bounding boxes in the link model were given in subsection 4.2. The process is divided into the following steps; (1) Both, the IFC model and the point cloud of the construction site, are georeferenced and thus co-registered. (2) The WKT files for the extruded 2D-Oriented Bounding Box (OBB) is computed for each building element. The OBB is represented as WKT string along with the attributes min and max for the minimum and maximum z-coordinate (height) of the building element. (3) Each building element is related to a link entry in the link model using the computed OBB. (4) The point cloud is added to all geometric links of the building elements if the bounding box in the link contains at least a point of the point cloud. The usage of a minimum quantity of point contained by the OBB allows for more stable results and considers the efects of outliers in the point cloud. The results of the process steps are shown in Figure 5. The coloured parts of the point cloud are indicating the assignment to a diferent building element. Also, it can be observed that not all building elements are assigned to the point cloud and consequently are not contained in the current construction state of the building.
A building permission is required to build, convert or demolish a building. In order to obtain this permission, the building owner has to submit documents of the building project, cadastral data and data of the surrounding environment to the building authority.
This exchange of building models, cadastral data and city models with a MMC is a use case where diferent geo links could be used. The following Table 1 shows possible link elements and the type of link between them:
This example shows the use of topological and geographic links in the user scenario of Figure 6. Since a topological calculation can only be performed with the lowest coordinate dimension of the elements involved, it is assumed that the higher dimensional elements are broken down to this dimension. For the shown example, it means that the 2D footprint of the 3D IfcBuilding would be the geometry to calculate the topological link to a 2D parcel. Table 1 shows some possible links between the example data.
Another option is to geospatially link the cadastral data and the city model to the IFC building model. In this case, the global coordinate system of the MMC was specified as ETRS89 UTM 32N (EPSG:4647).
The IFC file has a georeferenced IfcSite that contains a project base point with geographic coordinates in latitude and longitude in the WGS84 coordinate reference system (EPSG: 4326). The cadastral coordinates use the ETRS89 coordinate reference system with UTM 32N (EPSG: 25832) coordinates, but the easting coordinates are truncated by the zone. The city model is already in the container CRS. This means that the city model can use the CRS of the MMC (Table 1, last row). The geospatial link elements, except for the city model link, need a pose to transform them into the MMC coordinate system.
In the Federal Immission Control Act (BImschG), German legislation lays down regulations for the
prevention, avoidance and reduction of environmental noise. Noise maps must be drawn up for so-called
main sources of noise (roads, railway lines, airports, etc.) in accordance with the requirements set out
in §4 34.BimSchV [
Various resources are included for the exemplary implementation of the use case described above: The georeferenced noise map in the form of isophones (.geoJSON), a three-dimensional city model (.gml), the georeferenced building model (.ifc), a georeferenced digital terrain model (.obj) and an exemplary noise report (.pdf).
Figure 6 shows a coordination of the mentioned (visualizable) application models.
The spatial localisation of some resources enables both topological and geospatial linking. Furthermore, a mereological link can be derived between the IfcBuilding with its representation in CityGML, as well as between the Isophones and their dedicated noise report, which describes the same matter in textural form. Table 2 shows link example using the aforementioned link types with their respective values.
This paper presented and evaluated four distinct link types—geospatial, geometrical, topological, and mereological links—for the meaningful integration of heterogeneous BIM and GIS data. To support these linking concepts, the existing MMC schema was extended accordingly, and its integration into the MMC standard was successfully demonstrated. The practical application of the extended schema was then illustrated through selected use cases addressing key BIM-GIS interoperability challenges, such as construction progress monitoring, building permission processes, and environmental noise assessment, all leveraging open data formats. The results of these case studies confirmed that the proposed link types efectively meet the specific requirements for heterogeneous data integration across both domains.
The use cases highlighted the versatility of the proposed approach by demonstrating various exchange scenarios that utilized all introduced link types. The MMC schema was chosen for its lightweight structure and ease of implementation, making it a practical choice for industry adoption. However, the demonstration of the link concepts using a MMC does not limit their applicability to the MMC schema. The approaches represent possible extensions to other frameworks, such as the ICDD or similar solutions, if not already contained partially. Moreover, these linking principles could contribute to future standardization eforts in BIM-GIS interoperability, particularly those emphasizing linking-based approaches over conversion-based methods, as recommended in recent literature.
A key advantage of the presented approach is that link interpretation remains within the original authoring software rather than being solely dependent on the interpretation capabilities of the target software. This ensures that link structures can be accurately replicated across diferent platforms, improving data consistency and usability. By embedding explicit linking criteria within the schema, this approach helps eliminate redundant eforts in contextualizing data across various use cases. Instead of merely storing the results of a linking decision, the schema also preserves the motives behind the decision-making process, thus enhancing transparency, reusability, and automation.
The diferent link types proposed in this work ofer specific advantages and constraints depending
on the data context:
• Geospatial links enable the use of geographic location itself as a link between objects and
components, making them essential for GIS data contextualization. However, they require both
application models to be referenced in a common CRS, which is often not the case when dealing
with BIM models or non-geospatial data such as documents or tables.
• Geometrical links uses auxiliary geometries, such as 2D footprints or 3D bounding boxes,
to create relationships between elements which can not be indexed or do not hold suficient
semantics for semantic link discovery (as described e.g. by Willenbacher [
Future research should consider the entire linking workflow and explore the development of an open-source framework to support the process end-to-end. This would include automated link discovery, as described in recent research, as well as the linking process itself, its integration into suitable schemas, and the subsequent analysis of contextualized data by end users. Furthermore, investigating the adoption of AI-driven link prediction and machine learning techniques for automated semantic linking could significantly enhance eficiency and scalability in real-world applications.
During the preparation of this work, the authors used AI tools for grammar and spelling check. After using these tools, the authors reviewed and edited the content as needed and take full responsibility for the publication’s content.
The file used for this publication can be found at this repository: https://doi.org/10.5281/zenodo.14823279
During the preparation of this work, the authors used generative AI (Perplexity, ChatGPT) in order to: Grammar and spelling check, Paraphrase and reword. After using this tool/service, the authors reviewed and edited the content as needed and take full responsibility for the publication’s content.