buildingSMART / buildingSMART/NextGen-IFC
Provide identity to IFC files
- Dominant language
- TeX
- Stars
- 64
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Description
Description of the proposal:
IFC files don't have persistent identity. When a file is generated from a software, it is nearly impossible, for example, to know that the next IFC file of the same project is related to the previous version. This causes challenges, for example, in dealing with BCF. When a BCF Topic is sent to a CDE, it is impossible to reliably identify the files that the topic is dealing with. BCF tries to send the potential identifiers, like IfcProject GUID, filename, timestamp, etc, but none of these has been proven reliable.
The proposal is to add to the IFC headers the following entries:
* DocumentID: a UUID that persists throughout the versions of the file that are generated from the same model
* DocumentRevision: a version-specific UUID
Is this a proposal to 'add', 'remove' of 'change' entities in the schema (pick one):
What do we win: Reliable identification of IFC files
What do we loose
Schema impact: None
Instance model impact: None
Backwards compatible: Yes
Automatic migration possible: No
Additional implications: Implementing software should have a provision for the user to reset the Document ID, for example, when file is saved as.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.