buildingSMART / buildingSMART/IFC4.x-development
IFC4.3 georeferencing scale breaks IFC4 georeferencing user guide recommendations
- Dominant language
- Python
- Stars
- 234
- Forks
- 123
- Avg merge
- 15h 4m
- Merged PRs (30d)
- 5
Description
buildingSMART has long published this georeferencing guide:
https://www.buildingsmart.org/wp-content/uploads/2020/02/User-Guide-for-Geo-referencing-in-IFC-v2.0.pdf
This has long described the use of the scale parameter to store the average combined scale factor:

We have delivered many projects which use this Scale parameter accordingly and this is what buildingSMART Australia has been recommending to government organisations. I was always under the impression that this was endorsed by buildingSMART despite the contradiction in the official ISO IFC4 specs which describes it as a **Unit Scale** (as opposed to an average combined scale factor). The contradiction made sense because it allows you to store information that would otherwise be lost.
Now that IFC4.3 is being certified, vendors are implementing the Scale as a **Unit Scale** (e.g. latest version of Autodesk Navisworks). This now puts versions <=IFC4.3 into a position where they cannot store the average combined scale factor. This is in practice a breaking change. Is this intended? For example clients will see hundreds of meters of discrepancy in the origin points of models.
Contributor guide
Assessment
This issue has not been assessed yet.