buildingSMART / buildingSMART/NextGen-IFC
Use common base16 encoded GlobalIds instead of bespoke base64
- Dominant language
- TeX
- Stars
- 64
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Description
Currently STEP serialized IFC requires storing GlobalIds in a custom base64 format, more information here: https://technical.buildingsmart.org/resources/ifcimplementationguidance/ifc-guid/
As described on the linked page, this is purely for historical storage reasons, the amount of space that it saves in the modern IT environment is insignificant.
IFC uses a bespoke base64 format which means common programming libraries can't read it without extra code. For example: "2Z_lemE5zDQQcXGoemo8lz".
IFC Implementors have to write their own algorithms to handle this.
The nature of base64 means that it is case sensitive. Some databases, Excel, Navisworks, and other tools are not case sensitive by default which causes problems when searching by GlobalId.
I suggest to use the common base16 encoding of GlobalIds for all serializations of IFC. For example: "f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
It is not case sensitive, can be handled natively by many tools and databases, and is backward because you can still safely map between if so desired.
See: [RFC4122 A Universally Unique IDentifier URN Namespace](https://tools.ietf.org/html/rfc4122) for more information.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.