Support compound CRS by default! (hor+ ver datum) in the CRS Library

Hans_Lammerts
Hans_Lammerts
edited August 25 in 3D Modeling
The Problem

The Coordinate System Library used by BricsCAD only supports horizontal coordinate reference systems (CRSs). Vertical CRSs and compound CRSs (horizontal and vertical coordinate systems combined, as defined in the EPSG registry) are not supported by default.

For a platform positioned as a 3D BIM and GIS solution, this is a significant limitation.

As a result, a drawing can be accurately georeferenced in X and Y, yet its vertical component remains undefined. The software provides no mechanism to assign or store a vertical reference system. Consequently, IFC exports cannot reliably indicate whether elevations represent ellipsoidal heights, national leveling heights, orthometric heights, or another vertical datum altogether.

In other words, BricsCAD can answer where a model is in two dimensions, but not where it is in three dimensions.

Why This Matters

1. IFC and openBIM Standards Require It

IFC 4.3 introduces IfcProjectedCRS, which expects a compound CRS for georeferenced 3D models. Both the horizontal and vertical datums must be identifiable to ensure reliable data exchange.

BricsCAD is marketed as an infrastructure BIM platform, yet it cannot currently store or export the very metadata that the buildingSMART standard expects. Across Europe, clients and public authorities increasingly require correctly georeferenced IFC deliverables, including a defined vertical datum.

2. Compound CRS Definitions Already Exist

The EPSG registry already provides compound CRS definitions for many national coordinate systems:

  • Belgium
    • EPSG:6190 (Lambert 72 + Ostend Height / TAW)
    • EPSG:8370 (Lambert 2008 + Ostend Height)
  • Netherlands
    • EPSG:7415 (Amersfoort / RD New + NAP Height)
  • Germany
    • EPSG:5555 (UTM Zone 32N + DHHN92 Height)
  • United Kingdom
    • EPSG:9306 (HS2 Grid + HS2 Vertical Reference Frame)

Surveyors, GIS platforms, and geospatial databases already work with these compound CRS definitions every day. BricsCAD is one of the few professional geospatial platforms that cannot.

3. GNSS and Drone Workflows Are Now Standard Practice

Modern survey workflows routinely rely on GNSS observations and drone-derived data. These datasets often contain ellipsoidal heights that must be transformed to local vertical datums through geoid models.

BricsCAD's Vertical Datum Transformation functionality can perform these conversions, but the resulting vertical reference information is not stored as part of the drawing's coordinate system definition. Once the data leaves the software, the provenance of the elevations is lost.

A coordinate transformation without recorded metadata is only half a solution.

4. It Causes Confusion Today

Users often search for nationally recognised compound CRSs such as EPSG:7415 and find nothing.

As a result, Dutch users frequently select EPSG:28992 (RD New) because it is available, even though it only defines the horizontal reference system. The vertical component (NAP) is left undefined.

This creates the false impression that the model is fully georeferenced when, in reality, only the horizontal position is defined.

5. The Rest of the Industry Already Supports This

Leading geospatial and surveying platforms support vertical and compound coordinate reference systems, including geoid-based transformations:

  • Esri ArcGIS
  • QGIS / PROJ
  • Trimble Business Center
  • Leica office software

Models may enter a BIM workflow with complete 3D georeferencing, but once exported from BricsCAD they retain only part of that information.

Proposed Improvements

We propose the following enhancements:

1. Add Vertical and Compound CRS Support to the Coordinate System Library

Vertical CRSs and compound CRSs should be available and searchable by default.

Examples include:

  • EPSG:6190 – Lambert 72 + Ostend Height
  • EPSG:8370 – Lambert 2008 + Ostend Height
  • EPSG:7415 – RD New + NAP Height
  • EPSG:5555 – UTM Zone 32N + DHHN92 Height
  • And all other relevant EPSG compound CRS definitions

2. Store Vertical CRS Assignments Within DWG Files

Allow a DWG model to store a vertical CRS assignment alongside the horizontal CRS, creating a complete 3D spatial reference definition.

3. Integrate Vertical Datum Transformations Into Standard Workflows

The existing geoid-based vertical transformation functionality should be integrated into:

  • Coordinate transformations
  • Map queries
  • IMX exchange
  • Data Connect workflows
  • Other geospatial data processing tools

Vertical transformations should be part of the standard coordinate system workflow rather than a separate, optional extension.

4. Preserve Vertical Datum Information During Export

Carry vertical datum information through to IFC and other exchange formats by:

  • Exporting compound CRS identifiers where supported
  • Populating IFC attributes such as IfcProjectedCRS.Name
  • Supporting the IFC VerticalDatum attribute when applicable

This ensures that georeferencing metadata remains intact throughout the project lifecycle.

Who Benefits?

This enhancement would benefit everyone involved in 3D data exchange:

  • Surveyors delivering GNSS and drone-derived datasets
  • Designers and engineers exporting IFC models
  • Contractors and infrastructure operators
  • Public agencies requiring georeferenced BIM deliverables
  • GIS teams consuming 3D DWG data
  • BricsCAD and Autodesk users alike

Ultimately, it would allow the industry to answer a fundamental question with confidence:

"Where is this model in 3D space?"

Today, BricsCAD can only provide part of that answer.

Note: A similar enhancement request has also been submitted to the Autodesk Civil 3D development team through the Civil 3D Ideas forum, as Civil 3D currently suffers from the same limitation regarding vertical and compound coordinate reference system support.