buildingSMART Forums

Project UUID not unique

Hi there,

during some tests on around 2000 ifc files I stumpled above the following. Around 250 files uses the same Project ID 344O7vICcwH8qAEnwJDjSU . But they are around 80 different projects from various different architects. Some files are new, some files are around 5 years old. All of them where exported by ArchiCAD.

The famous Schependomlaan has it too. https://github.com/buildingSMART/Sample-Test-Files/blob/master/IFC%202x3/Schependomlaan/Design%20model%20IFC/IFC%20Schependomlaan.ifc

#56= IFCPROJECT('344O7vICcwH8qAEnwJDjSU',#25,
'10 Appartementen Schependomlaan',$,$,$,$,(#53,#197),#42);

Has someone noticed similar problems.

This should not happen IMHO. Would one of you guys out there correct me if I am wrong. I thought a uuid is unique for a project.

cheers bernd

1 Like

GUIDs should be unique.

One potentially related issue is that the UUID version isn’t specified by buildingSMART, resulting in less random GUIDs. I’ve previously reported this problem here and here.

I am surprised at the frequency and the specificity to the IfcProject entity, though. That suggests it may be a different issue.

I took a look at that IFC file and sorted the GUIDs ascending - there are no internal collisions, and I do not see clearly wrong ones (e.g. sequential GUIDs) within that file. My new theory for this scenario is that perhaps ArchiCAD is generating GUIDs correctly, but perhaps if you load a particular template which includes a project GUID, ArchiCAD will preserve it in subsequent exports? I’m not convinced, though, that 250 files are using the same template …

That’s an interesting observation.

ArchiCAD seems to create the project’s globally unique ID (and few other spatial entities’) from a set of userdefined properties (see Graphisoft Help Center). This way they grant users contol over the uniqueness and allow to intentionally generate equal IDs, when two or more of their files do indeed cover the same project, hence if a project is split across multiple files.

This makes a lof of sense IMHO, even though I am not convinced if and how this goes well with guaranteed randomness, imagine for example if multiple users follow the ID scheme that they propose in the Help Center. I guess at least when all those fields are empty, they might better generate a random ID.

1 Like

@tauscher that explains it!

I have added it to the OSArch wiki guides - a new page for ArchiCAD setup things to consider for OpenBIM: https://wiki.osarch.org/index.php?title=ArchiCAD_setup

In my opinion, I think a better solution would be for ArchiCAD to just randomly generate it, but then allow a field to override it in the UI if you want it to match a specific value … the use of such a seed decreases randomness.

@bernd, unfortunately yes, it is typical issue with IfcProject for many applications, it is not only ArchiCAD issue:

  • GlobalId may be the same for semantically different projects
  • GlobalId may be different for 2 IFC files created from one design.

The second issue is also often for buildings and storeys.
In this case I trust the Name but it does not work for IfcProject.

In fact I do not see any practical why to recognize project identity

1 Like

@igor.sokolov which other applications exhibit this problem?

GlobalId may be the same for semantically different projects

From my understanding, this should not happen, and vendors should not design software in a way that makes this occur.

GlobalId may be different for 2 IFC files created from one design.

From my understanding, this is not an issue: this is the desired behaviour to denote that two IFC files actually refer to the same data. When IFC 5 comes with IFC referencing, that’ll clean this up further, but for now, GUID matching is all we’ve got.

Edit: crossed out my statements - I had misread Igor’s message :slight_smile: Thanks @tauscher!

1 Like

Exactly, that is why it is an issue to have different global IDs for semantically equivalent projects, buildings, storeys etc. when they are in different files. Maybe you misread @igor.sokolov 's second case?

I guess we all agree that GlobalIds should be equal if and only if the identified products are semantically equivalent. Neither of the two violations should happen, but they do happen even if implemented properly because determining semantic equivalence is rarely possible without an educated user.

@tauscher whoops! You’re absolutely right. I’ve edited the post. Yes, I believe we are all in agreement here.

One addition detail, though, I’d like to propose that such strongly seeded approaches like that seen in ArchiCAD may reduce randomness. Therefore, I’d refer to my original proposal for the buildingSMART spec to specify UUID4, and then allow users to override it if they know what they’re doing.

1 Like

Does it mean we all agree, two totally different projects should never ever have the same UUID. Thus I consider this a bug in ArchiCAD.
I just remember all the file are from different Architects, from different Projects. They just have one commonalties: they all where exported with ArchiCAD.