buildingSMART / buildingSMART/IFC4.x-development

IFC4.3 georeferencing scale breaks IFC4 georeferencing user guide recommendations

Open
#741 0 comments 0 reactions 0 assignees View on GitHub
allocated allocated-gis ifc-update-out
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:

![2023-12-07-153820_783x321_scrot](https://github.com/buildingSMART/IFC4.3.x-development/assets/88302/be57c165-550d-44b3-becb-4722d7bb3668)

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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.