buildingSMART / buildingSMART/IFC4.x-development
ifc class, ifc type and ifc type enum. mapping to BDNS abbreviations. when to use what...
- Dominant language
- Python
- Stars
- 234
- Forks
- 123
- Avg merge
- 15h 4m
- Merged PRs (30d)
- 5
Description
hi there,
I'm a regular contributor to the BDNS (Building Device Naming Syntax) group and we are currently working to improve the mapping to IFC4.3.
https://github.com/theodi/BDNS/pull/335
currently we have separate columns indicating `ifc_class` and `ifc_type` and I'm evaluating if they are both required / whether one can be derived from the other.
based on the [bsDD-IFC4.3](https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3) it appears that the type enums have been flattened into the class with both being listed as a class. Combining them and tidying a little I was able to generate compliant IFC class names as per the bsDD on my demo branch:
https://jgunstone.github.io/BDNS/BDNS_Abbreviations_Register.html
when placed in an IFC4.3 model is the the case that every IFC class has a matching IFC type?
looking at the [annex-b-types](https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/annex-b2.html) and [annex-b-entitites](https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/annex-b1.html) listings it looks as though it may not be as simple as that...
is the situation different in IFC2x3?
I'm trying to figure out how the ifc type fits in and whether we also need to track / map to that....
not the clearest question... but any guidance you can give would be much appreciated.
Contributor guide
Assessment
This issue has not been assessed yet.