Why IFC georeferencing is often the critical point in photogrammetry handoffs
Photogrammetry can turn supplied images into point clouds, meshes, orthophotos, roof planes, facades, and modelled building envelopes. For BIM coordination, geometry alone is not enough. The model also needs the right spatial relationship, otherwise it imports in the wrong place, with the wrong rotation, or with an unclear height reference.
IFC can describe the relationship between a local engineering coordinate system and a map coordinate system. buildingSMART documents this through IfcMapConversion and IfcProjectedCRS. That matters whenever CAD, Revit, GIS, survey data, and point clouds need to align.
Voxelia’s work is the processing of existing imagery into usable planning data. For BIM handoffs, that means stating whether the output is locally scaled, project-referenced, georeferenced, or documented with CRS and vertical datum.
Practical takeaway
An IFC without traceable coordinates may still work for visualization. For coordination, as-built work, CAD overlay, GIS, digital twins, or planner handoff, that gap is a project risk.
IfcMapConversion and IfcProjectedCRS: the core building blocks
buildingSMART defines IfcMapConversion as the transformation from a project’s local engineering coordinate system into the map CRS. It combines scale, rotation around the Z axis, and translation via Eastings, Northings, and OrthogonalHeight. It does not perform the map projection itself.
IfcProjectedCRS describes the target CRS. In a 3D context, the IFC documentation expects a compound CRS from which geodetic and vertical datums can be identified unambiguously. The Name should be a single clear identifier, commonly an EPSG code.
ISO 16739-1:2024 publishes IFC 4.3 as Edition 2 of the international standard, strengthening IFC as an exchange format across building, infrastructure, and facility workflows.
| IFC Element | Role | What to Check | Practical Note |
|---|---|---|---|
| IfcProjectedCRS.Name | Identifies the target CRS | Single EPSG identifier or WKT | Avoid unclear combined strings. |
| Eastings / Northings | Moves the local origin into map space | Matches project area and CRS | Wrong UTM zone or swapped axes cause large offsets. |
| OrthogonalHeight | Sets height relative to the vertical datum | Vertical datum documented | Do not treat every Z value as construction height. |
| XAxisAbscissa / XAxisOrdinate | Defines local X-axis direction | Project north and model rotation | Small rotation errors make overlays painful. |
| Scale | Converts units between systems | Used for units, not hidden correction | If omitted, IFC assumes 1.0. |
The coordinate logic behind the IFC handoff
IfcMapConversion first scales, then rotates counter-clockwise around Z, then translates by Eastings, Northings, and OrthogonalHeight. buildingSMART gives the rotation angle as theta = arctan(XAxisOrdinate / XAxisAbscissa).
That separation lets a photogrammetry model stay numerically stable near a local origin, while real-world position is documented through metadata and coordinate operation. This is often better than writing very large world coordinates directly into model geometry.
No export magic
IFC export does not repair an unstable model, a wrong scale, or an unclear vertical datum. It only documents the coordinate relationship that was technically established.
Revit, Shared Coordinates, and false origin
In Revit workflows, IFC georeferencing, shared coordinates, and point clouds often meet. A point cloud or mesh from photogrammetry is usually a reference, not a semantic BIM model by itself.
The false-origin approach keeps geometry close to a local origin while real location and rotation are documented separately. For point clouds and meshes, this reduces precision issues and keeps the handoff more usable across CAD, Revit, IFC, and GIS.
Typical errors in photogrammetry-to-IFC handoffs
Most issues appear when multiple tools interpret origin, axes, and heights differently. Therefore the handoff should be checked for import behavior and overlay logic, not only visual appearance.
| Risk | Why It Matters | Symptom | Countermeasure |
|---|---|---|---|
| IFC has geometry but no clear CRS | Hard to align with CAD, cadastral, or GIS data | Manual move and rotate in target tool | Document CRS, origin, rotation, scale, and vertical datum |
| Unclear EPSG naming | Tools may interpret CRS inconsistently | Different viewers show different positions | Use one compound CRS or WKT where needed |
| Ellipsoidal height read as construction height | GNSS height and national height datums differ | Systematic Z offset | State vertical datum separately |
| Large world coordinates in geometry | CAD/BIM software can suffer precision issues | Import, display, or rounding problems | Use local origin plus map conversion/shared coordinates |
How Voxelia validates IFC handoffs from supplied imagery
The review starts with the intended downstream workflow, not the file extension. Viewer models, CAD backgrounds, Revit references, and openBIM deliverables need different statements about origin, scale, axes, heights, and quality.
- 01
Define target output
Clarify whether IFC, point cloud, mesh, orthophoto, DXF/DWG, or a combined BIM handoff is needed.
- 02
Review imagery and references
Assess EXIF/XMP, GNSS, GCPs, reference dimensions, scale, checkpoints, and visible geometry quality.
- 03
Set stable local origin
Keep model processing numerically manageable and carry real-world position as explicit handoff data.
- 04
Validate IFC and CRS data
Check IfcProjectedCRS, IfcMapConversion, EPSG/WKT, project north, height reference, and units.
- 05
Document limits
If imagery only supports local scale or visual reference, state that clearly instead of overstating survey-grade IFC quality.
FAQ: IFC georeferencing from photogrammetry
Validate coordinates before BIM handoff
Turn imagery into BIM-ready data
We assess supplied imagery, scale, CRS, vertical datum, and target workflow, then deliver the right handoff for IFC, CAD, point cloud, orthophoto, or viewer.