A building model and a geospatial model can be used together in more than one way. The right design depends on what the recipient must do with both datasets, which meanings must correspond, and which source remains authoritative. Starting with a file conversion can hide those decisions.
Three patterns, with different obligations
The OGC and buildingSMART comparison describes three patterns used for integration. A project may combine them, but each pattern creates different obligations.
| Pattern | What happens | Questions to resolve |
|---|---|---|
| Schema mapping | Selected objects and information are translated into a target schema. A recipient may then use one target representation. | Which source concepts map to which target concepts? What geometry, properties, relationships, and detail are kept, simplified, or omitted? |
| Federation | A software environment presents information from multiple models together, potentially as a spatial, semantic, temporal, tabular, or graph view. | Which model versions and access dependencies are needed? How are coordinate contexts reconciled? What is computed at use time, and what must remain linked to its source? |
| Linked objects | Cross-references connect corresponding elements in different models so information can be found in more than one source. | How is correspondence identified and updated? What identifier is stable in each system? Which source controls changes to each property or geometry? |
These are design choices, not guaranteed capabilities of a particular product or format. A linked object does not by itself create a shared identity service. A federated display does not prove that the underlying concepts are equivalent. A mapping can produce a valid target file while losing information the receiving task needs.
Decide what counts as equivalent
Names and visible shapes are weak evidence of semantic equivalence. An IFC space, a city-model room, and an indoor-navigation cell may refer to related volumes while serving different functions and carrying different relationships. A project may assert that two particular objects refer to the same real-world space, but that assertion needs a rule and evidence. Similar labels, overlapping geometry, or an aligned view do not establish identity.
Write down the concept relationship before mapping:
- Is the target object the same real-world object, a view of it, an aggregate, or a derived representation?
- Which geometry and level of detail must the receiving task use?
- Which properties, classifications, containment, and relationships matter?
- Can one source object become several target objects, or several source objects be aggregated?
- Which stable identifiers, source versions, and correspondence records are available?
- What information may be simplified or omitted, and who accepts that loss?
The BIM semantics article explains why geometry does not establish project relationships or object meaning. The reference-model article distinguishes a useful linked reference from an editable source.
Read standards by their stated scope
The 2020 OGC/buildingSMART analysis compares IFC, CityGML, and LandInfra and discusses schema mapping, federation, and cross-references. It is a comparative report, not an implementation result or current product route.
ISO/TS 19166:2025 describes conceptual BIM-to-GIS mechanisms for a user-specific perspective, element mapping, and level-of-detail mapping. The public scope says it focuses primarily on BIM-to-GIS mapping for visualization. It expressly excludes physical schema integration, coordinate-system mapping, relationship mapping, and bidirectional mapping. Those exclusions matter: a conceptual mapping framework does not resolve all the identity, placement, relationship, or implementation decisions in an actual exchange.
A 2025 paper proposes extending the Multi-Model Container schema with geospatial and relationship information. Treat that work as a proposal, not as an adopted profile, general support claim, or persistent-identity mechanism.
Write an integration brief
Before choosing a route, capture the decision in a short brief:
| Brief field | State explicitly |
|---|---|
| Receiving use | The question, task, users, and time at which the combined information is needed. |
| Inputs and authority | Source model identifiers, versions, owners, update state, and the authoritative source for each kind of information. |
| Concept correspondence | Which source and target objects are considered equivalent, related, aggregated, or derived, and why. |
| Required view | Geometry, semantic detail, classifications, properties, relationships, and level of detail the task needs. |
| Identity and updates | Keys used to reconnect objects, how changes are reconciled, and how deleted or split objects are handled. |
| Spatial context | Local and project frames, CRS, operation, vertical meaning, relevant epoch, and permitted placement loss. |
| Dependencies and access | Referenced files, services, permissions, and the behavior if a source is unavailable or changes. |
| Known loss | Information that will not transfer or will only be available through a link. |
| Evidence | How the receiver will demonstrate that the selected representation serves the stated task. Keep acceptance criteria and execution with the responsible project process. |
This brief may conclude that one target schema is sufficient, that sources should be federated, or that selected objects should be linked. It may also use different patterns for different data layers. The decision should follow the receiver’s required work, not the number of formats involved.
Keep the claims bounded
A schema can describe a mapping mechanism. A system can display two models together. A link can resolve to a second object. Each observation is narrower than proof that the integrated result preserves required identity, semantics, coordinate context, or update behavior.
For a named sender and receiver, verify the exact product versions, direction, schema/profile, dependencies, and delivered data. Route that work to the portal’s Ecosystem Routes and Workflows coverage. Define the intended tests and acceptance with Validation, Exchange Control, and Long-Term Reuse. This article supplies the integration decision and brief that those later steps can use.