buildingSMART / buildingSMART/NextGen-IFC

Use common base16 encoded GlobalIds instead of bespoke base64

Open
#8 7 comments 2 reactions 0 assignees View on GitHub
Decision made valid proposal
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.