ifc naar gis

Preserve GUIDs, Keep City GIS Fast: IFC to GIS Workflows for Planners

Anne Dullemond

— 12 min read
Share
Preserve GUIDs, Keep City GIS Fast: IFC to GIS Workflows for Planners

For most urban-planning jobs, the right route is a controlled ETL or two-pass export: extract IFC semantics with a GUID join, simplify the geometry, then load the result into GIS. Direct import tools are faster but sacrifice attribute control; open-source and browser converters win on repeatability and cost. The trade-off is always the same: semantic fidelity against processing speed and automation.

TL;DR:Using a GUID-based two-pass workflow helps retain semantic details like property sets and is more reliable than single-pass conversions, which often lose information.Georeferencing IFC models requires checking for existing map conversions, manually assigning EPSG codes, and verifying placement against known control points for accuracy.Reprojection mismatches are a common cause of misaligned IFC layers, so ensuring CRS consistency across all GIS layers is essential for proper integration.Simplifying geometry to outer envelopes and filtering by IFC class or storey are effective strategies for maintaining performance at city scale without losing critical spatial information.Automated pipelines with scripting and GUID-based joins are key to efficiently updating IFC-derived GIS layers after design revisions.

3D CityplannerBring IFC Data Into Better PlanningUse 3D Cityplanner to analyse spatial development scenarios with GIS data, 3D city models and project calculations.Explore 3D Cityplanner

Table of Contents

What are the main workflows for converting IFC to GIS?

There is no single correct path from IFC to GIS. The right choice depends on how much semantic detail you need to keep, how large the model is, and whether the output feeds a one-off analysis or a repeatable pipeline.

  • Direct import through ArcGIS or CityEngine gets a model onto the map fastest, but the toolchain often flattens property sets into generic multipatch attributes, so you lose fine-grained control over what survives the trip.
  • ETL platforms such as FME handle attribute mapping, batch processing and coordinate transformation in one pass, which makes them the practical choice when you are converting dozens of buildings rather than one.
  • Open-source converters like ifc2geojson and tum-gis/ifc-to-citygml3 produce GeoJSON or CityGML output through scriptable, version-controlled pipelines, which suits teams that need reproducible builds rather than a manual export each time.
  • Browser or WASM-based tools parse the IFC file locally, which keeps sensitive design data off third-party servers and is handy for a quick massing preview before committing to a full conversion.

A thesis on infrastructure BIM-GIS integration found that many GIS platforms still lack native IFC parsing for IFC4.3 models, which is why standalone converters or custom ETL scripts remain necessary for transport and infrastructure projects rather than a one-click import.

How do ArcGIS, FME and open-source tools handle IFC differently?

Each tool sits at a different point on the automation-versus-control spectrum, and picking the wrong one for the job wastes more time than the conversion itself saves.

  • ArcGIS BIMFileToGeodatabase and CityEngine’s import routines convert BIM workspaces, including IFC, into geodatabase feature classes. You need to set the spatial reference explicitly and decide whether to include floorplan geometry, since the ArcGIS documentation notes that output identifiers and reprojection are left for the user to manage.
  • FME excels at GUID-based joins, attribute transfer between formats, on-the-fly reprojection and scheduled batch runs, which is why the ISPRS Palazzo Trotti pilot built its workflow around FME’s DatabaseJoiner transformer.
  • ifc2geojson parses IFC in the browser or Node.js using web-ifc, supports CRS specification and class filtering, and exports precision-aware 3D GeoJSON suitable for QGIS.
  • tum-gis/ifc-to-citygml3 targets CityGML 3.0 output and supports IFC2x3, IFC4 and IFC4.3, applying IfcMapConversion automatically when the source model carries it.

GUI tools suit one-off site checks; scripted pipelines suit anything you expect to run again next month.

How do you get the georeferencing right?

A model that looks correct in a BIM viewer can still land in the wrong place on a map, so georeferencing deserves its own checklist rather than an afterthought.

  1. Check whether the IFC file already contains an IfcMapConversion entry (IFC4 or IFC4.3). Tools like tum-gis/ifc-to-citygml3 and ifc2geojson read this automatically and apply it during export.
  2. If no map conversion is present, assign the correct EPSG code manually and apply a translation, rotation and scale transform using a scriptable tool, a common fallback noted in the ifc2geojson project notes.
  3. Verify placement against known control points, ideally survey markers or kerb lines visible in both the model and a trusted base map.
  4. Check elevation separately. A horizontal fix does not guarantee the Z-axis lines up with your terrain model.

Pro Tip: Overlay the converted footprint on aerial imagery before running any spatial analysis. A five-metre offset is invisible in a table of coordinates but obvious the moment you see it against a street.

Why do property sets and GUIDs matter for GIS analysis?

Geometry without attributes is just a shape. The value of IFC in a GIS workflow comes from the property sets: gross floor area, use class, storey, fire rating, ownership. Losing them during conversion turns a rich BIM asset into a decorative polygon.

The fix is to treat the IfcGUID (or GlobalID) as a primary key throughout the pipeline, then run a two-pass export: extract the property tables first, convert the geometry second, and join the two using the GUID rather than rebuilding attributes from scratch.

  • Extract IfcGUID alongside spatial data, never discard it during simplification.
  • Map only the property sets planning actually queries: area, use, storey and any shared parameters tied to zoning or capacity.
  • Perform the geometry-to-attribute join inside the geodatabase, not the source IFC tool.

The ISPRS Palazzo Trotti pilot found that single-pass conversions routinely lost semantic and geometric detail, while a GUID-based two-pass workflow using FME preserved level-of-information far more reliably. That single design choice, joining on GUID rather than re-deriving attributes, is the difference between a GIS layer planners can query meaningfully and one that just looks the part.

How do you keep IFC-derived GIS layers fast at city scale?

A single detailed IFC model can carry hundreds of thousands of vertices. Load twenty of those into a city-wide GIS layer and the map grinds to a halt long before anyone runs a visibility or sunlight analysis.

  • Extract the outer envelope, walls, roof, footprint, rather than every internal wall and duct; research on geometry simplification for city-scale visualisation treats this as standard practice for exactly this reason.
  • Choose 2.5D footprints with height attributes for broad zoning or capacity views, and reserve full multipatch geometry for site-specific detail work.
  • Filter by IFC class or storey before export, so you are not carrying basement plant rooms into a skyline massing study.
  • Keep the full-detail BIM model linked as an external asset, referenced by GUID, rather than embedding every property directly in the GIS layer.

Pro Tip: If a stakeholder only needs to compare building heights and footprints across scenarios, a simplified envelope loads in seconds where the raw IFC geometry would take minutes, and nobody notices the missing rebar detail.

How do you convert one IFC file into GeoPackage for QGIS?

This sequence works for a single building or a small site and forms the basis of most batch pipelines once it is proven.

  1. Open the IFC file and check for an IfcMapConversion entry to confirm whether georeferencing is already present.
  2. Identify the CRS, the relevant IFC classes (walls, slabs, spaces) and which storeys matter for your analysis.
  3. Extract geometry and attributes using ifc2geojson for a browser-based export, or FME for a more controlled attribute mapping, and write the result to GeoPackage or GeoJSON.
  4. Run a GUID-based join between the extracted attribute table and the geometry inside the geodatabase, rather than trusting whatever the export tool attached automatically.
  5. Load the GeoPackage in QGIS, overlay it against a base map or aerial image, and query a handful of attributes to confirm the join worked.
  6. Reproject if the overlay shows any offset, and re-check elevation against known ground levels.

Once this sequence is confirmed for one building, wrap the extraction and join steps in a script so the same recipe runs unattended across a full batch of models.

How do you validate the accuracy of converted GIS data?

Validation has two separate jobs: confirming the geometry sits in the right place, and confirming the attributes still mean what they meant in the original model. Skipping either one produces a layer that looks trustworthy and is not.

For spatial accuracy, overlay the converted layer against a known base map or survey control points and measure the offset directly rather than eyeballing it. Check vertical alignment separately from horizontal, since a converted model can be perfectly placed in plan and still sit half a metre above or below the correct terrain height. Where a model includes an IfcMapConversion block, cross-check the reported eastings, northings and rotation against an independent source, a cadastral boundary or a surveyed benchmark, before trusting the automated georeference.

For semantic integrity, sample a set of converted features and compare their attribute values against the original IFC property sets. Confirm that the GUID join produced a one-to-one match with no orphaned geometry and no attribute rows that failed to link. The buildingSMART forum’s practitioner discussions flag missing shared parameters and coordinate mismatches as the two most common failure points, which makes both a reasonable first place to check when a conversion looks wrong.

Build these checks into the pipeline itself rather than treating them as a manual final step. A script that logs join failures and flags features falling outside a reprojection tolerance catches problems before they reach a planning committee, which is a far better place to find them than in a public consultation.

How do you validate the accuracy of converted GIS data? — overview diagram

How do you combine IFC-derived data with existing planning layers?

An IFC-derived building layer only earns its place in a GIS once it sits alongside zoning boundaries, cadastral parcels, infrastructure networks and environmental datasets, and lines up with them cleanly.

Start with a shared coordinate reference system across every layer. Reprojection mismatches are the single most common reason a converted building appears to float free of the parcel it should sit inside. Once alignment is confirmed, treat the converted footprint as a new feature class within your existing schema rather than a standalone file, matching field names and types to your established zoning, land-use or asset-management layers so queries can run across both without extra translation.

Attribute mapping matters as much as spatial mapping. If your planning database already stores land use codes, gross floor area or parking counts for existing buildings, map the equivalent IFC property sets to the same fields rather than inventing a parallel attribute scheme. This is where the GUID-based join described earlier pays off twice: once for internal consistency in the conversion, and again when the resulting layer needs to talk to a decades-old cadastral dataset without a custom crosswalk table.

For redevelopment or infill projects, the practical benefit shows up quickly. A converted building massing dropped into a scenario alongside existing infrastructure, greenery and parking layers lets a planning team run a real visibility or sunlight analysis against the surrounding context rather than the isolated model. Platforms built for scenario comparison, layering a converted IFC asset over GIS base data, existing zoning and public space, make that integration step visible to stakeholders rather than buried in a database.

How do you combine IFC-derived data with existing planning layers? — overview diagram

What does a successful IFC to GIS conversion look like in practice?

The ISPRS Palazzo Trotti pilot remains one of the more instructive published examples because it documents both the failure mode and the fix. A single-pass IFC-to-shapefile conversion of the historic Palazzo Trotti building lost semantic detail and introduced geometric inconsistencies. Switching to a GUID-based two-pass workflow in FME preserved far more of the original level of information, giving the project team a GIS layer that still carried meaningful heritage-conservation attributes rather than bare polygons.

Infrastructure projects show a different pattern. A thesis on transport network management describes a standalone converter built to move IFC4.3 infrastructure models into GeoPackage for ingestion into a transport network engine, built specifically because the target GIS platform had no native IFC support. The project validated the converted output directly in QGIS before it was trusted for network analysis, a step worth repeating on any project rather than assuming a converter’s output is correct by default.

Both examples share a structure worth copying: extract semantics deliberately, verify the geometry independently, and only then treat the converted layer as fit for planning analysis. Neither project trusted a single conversion pass to get everything right on the first attempt, and neither should you.

How do you handle IFC model updates after the initial GIS import?

BIM models change constantly during design development, and a GIS layer built from an early IFC export goes stale the moment the architect issues a revision. Treat synchronisation as part of the workflow from day one rather than a problem to solve later.

The GUID-based join described earlier is what makes updates manageable. Because the original IfcGUID persists across most model revisions (unless an element is deleted and rebuilt from scratch), a re-export can be matched against the existing GIS attribute table using the same join logic, updating only the features whose GUIDs changed rather than rebuilding the entire layer. Features with GUIDs no longer present in the new export flag as deleted; new GUIDs flag as additions.

Version-controlled, scripted pipelines built around open-source tools like ifc2geojson or tum-gis handle this far better than a manual GUI export, since the script can be rerun against a new IFC file and produce a diff automatically. Keep a log of conversion runs, including the source file’s timestamp and any manual georeferencing corrections applied, so a planning team can trace which GIS features reflect the latest design and which are still pending an update. For projects with monthly or weekly design cycles, that log is often the only thing standing between an accurate site model and a scenario comparison built on outdated massing.

Balancing fidelity and usability in IFC to GIS work

Most planning teams over-invest in geometric detail and under-invest in semantic mapping, then wonder why their GIS layer cannot answer a simple capacity question. A two-stage approach works better: secure the GUID-based semantics first, simplify geometry second. Browser-based platform tools earn their place once that foundation is solid, particularly for stakeholder sessions where repeatable, QA-checked pipelines matter more than one impressive render.

— Anne Dullemond

Where 3D Cityplanner fits after the conversion

Once your IFC-derived building footprints, storeys and property sets are sitting cleanly in GIS, the next question is usually how fast you can turn that data into something a planning committee or investor can actually evaluate. That is where a converted dataset stops being a database exercise and starts being a decision-making tool.

3D Cityplanner is a browser-based platform that takes GIS layers, including converted IFC building massing, and lets you build, compare and present development scenarios in 3D without installing anything. It combines your GIS base data with automated area generation, visibility and sunlight analysis, and parking or capacity calculations, so a converted building footprint can sit inside a full site context: infrastructure, greenery, public space and zoning boundaries, within the same working session. That makes it a practical next step for early-stage feasibility studies and redevelopment scenarios, where the question is not just “does this model convert correctly” but “how does this massing perform against three alternative layouts, and can I show that to stakeholders next week”. For teams working through a gebiedsscan or an early feasibility check, pairing converted BIM data with a scenario-comparison workspace saves the step of rebuilding context manually in every review cycle. Pricing runs from the Starter plan at €79 per month up to Team and Organisation tiers for larger departments, with a demo available for teams that want to test a converted dataset against a real site before committing.

Sources

FAQ

How do you open an IFC file?

Open an IFC file with a dedicated BIM viewer or authoring tool that supports the IFC schema, such as those built on the buildingSMART standard. Many are free to use for viewing, though editing typically requires a licensed BIM application.

Is there a free IFC viewer available?

Yes, several free IFC viewers exist, and browser-based tools built on web-ifc, the same library behind ifc2geojson, let you inspect a model’s geometry and properties directly in a browser tab with no installation. These are useful for a quick check before committing to a full GIS conversion.

How do you make a GIS map from an IFC file?

Convert the IFC file to a GIS-friendly format first, typically GeoJSON, GeoPackage or CityGML, using a tool like FME, ArcGIS’s BIMFileToGeodatabase, or an open-source converter such as ifc2geojson. Once converted, load the file into QGIS or ArcGIS, verify the coordinate reference system, and overlay it against existing planning layers.

What is the IFC file format?

IFC (Industry Foundation Classes) is an open, vendor-neutral data schema for exchanging building information model data between software applications, maintained under the buildingSMART standard. It stores geometry alongside semantic information, such as property sets, storeys and GUIDs, which is exactly the detail worth preserving when converting into GIS.

Can 3D Cityplanner work with IFC-derived GIS data?

Yes. Once IFC data has been converted into a GIS-compatible format such as GeoPackage or GeoJSON, 3D Cityplanner can bring that building massing into a browser-based scenario alongside existing GIS layers, infrastructure and public space, for site analysis and stakeholder presentations.

Read more