Skip to content

Conversation

@amiroo4
Copy link

@amiroo4 amiroo4 commented Sep 24, 2025

This document proposes a linked georeferencing approach for IFC 5. CRSs are referenced externally toPROJJSON, which encodes CRS definitions, transformations, and coordinate operations in JSON. The schema is designed to be applicable across all georeferencing use cases and to remain independent of any specific file instance.

This document proposes a linked georeferencing approach for IFC 5. CRSs are referenced externally toPROJJSON, which encodes CRS definitions, transformations, and coordinate operations in JSON. The schema is designed to be applicable across all georeferencing use cases and to remain independent of any specific file instance.
@aothms
Copy link
Contributor

aothms commented Sep 24, 2025

Hi @amiroo4 thanks for this. I would want to quickly compare this to the approach in:

{
"path": "82b7699e-9f06-572c-ba4c-983c9907a59a",
"attributes": {
"epsg4326": {
"latitude": 37.810711502676924,
"longitude": -122.47750280356061
}
}
},

  • georeferenced-bridge-deck.ifcx
    • epsg code in attribute namespace, therefore multiple projected/geographic crs'es can be related, in proposed approach only crs'es of different kinds can be related
    • schema is specific to epsg code, which is (a) redundant; there are a lot of different geographic crs'es these are all different schemas, but this can probably be alleviated with inheritance on the schema level (b) adaptive if different crs'es have different measures
  • LinkedGeoreference.ifcx
    • epsg code in attribute value, therefore part in composition behaviour and only one ProjectedCRS will 'survive' after composition
    • more computer interpretable by linking to proj json, but I would wonder whether it's possible to do that on the schema level and not on the instance level

What do you think? Do you see opportunities for this to be harmonized? So have the ability for multiple same-type-crs instances on a prim, this requires some sort of namespace so that they are not folded into a single value during composition, but while retaining the references to the proj json preferably on the schema level (which would likely happen anyway when we somehow differentiate namespaces).

Heights might be a good example. Let's say you want to add a reference point to a model and add multiple geospatial heights to it, one in NAP+EVRF2000+TAW. How would you want to do that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants