At which level does the validity of a GUID between stakeholders beginn? Since in an IFC File, everything has this unique number (not only objects), i was wondering how can this be implemented throughout a big project, comprised out of multiple IFCs,!?
A Globally Unique Identifier (GUID) … provides a way of uniquely identifying an object
To my understanding an Object is a Wall, Door, CableCarrier, etc.
But what about IfcProject → IfcSite → IfcBuilding → IfcStorey???
I am currently working on a project with different stakeholders exchanging multiple IFC. Between these IFCs, in many cases there are no duplicates, but in some cases they appear. By duplicates I mean ex. GUID of IfcProject or IfcBuilding between Architecture and mechanical is the same; GUID of IfcSite between Architecture and Electrical is also the same.
So what is actually legal here?
Because there is one project on a site that has a building with storeys ( IfcProject → IfcSite → IfcBuilding → IfcStorey), all these GUIDs being generated by all stakeholders (with different BIM authoring tools) should be the same??? The differentiation begins at the level of an object?
Looking at it from a “federated model” view point, it makes sense that the above structure is the same.
Can someone please help me on clarifying this…
thanx
An object for the purposes of GlobalIds are defined as any Rooted element in the IFC schema. As such, IfcProject, IfcSite, and so on are all objects.
The rule we follow is that if the element in question is the same for all semantically for all parties, a particular consultant is nominated as the “owner” of that data, and everybody must change their GlobalIds to match them. If any differences in metadata occur, their copy takes precedence.
For example, usually the client takes ownership over IfcProject, and supplies all of the metadata, except for the georeferencing, which could be a surveyor. Site is usually by civil or portions by landscape architect, and the architect takes ownership of the spatial tree.
We encourage the GlobalIds to match, which allows us to select and merge them easily when we want to provide federated data sets, such as for COBie.
There are sometimes complications with this approach, such as when IfcBuildingStorey discrepancies occur.
In IFC5, it has been agreed that we are moving to the latest version of STEP, which allows IFCs to reference one another. That way, you can have a single IFC file containing just the IfcProject and the spatial tree, and all other IFC files reference that IFC file. No vendor supports this workflow out of the box yet, though.
As a user, you are depending on the software to generate the GUID. In most case, you don’t have any control and you cannot “set” the GUID to a custom value.
So in practice, every IfcProject and IfcBuilding and IfcSite in a project will have a different GUID even if they refer to the same “object” in reality.
One could start from the same source file before modelling, as objects tend to always receive the same GUID once generated, but that requires everybody to use the same software. And I’m not even sure this will work.
Or you could hack the generated IFC-file (patch) by replacing the generated GUIDs after export. Find and replace or so…
By the way, if you’re interested here is how to override a GlobalId in Revit. For the scenarios where we cannot override the GlobalId using the authoring package, I use the IfcPatch tool.
Hi @Moult
Hi @stefkeB
Thanks for clarifying this case. Today this case is rather still not clear to users and especially software producers.
The correct order of defining these were based on a “template” that the investor creates. He decides attributes at the level of IfcProject and the land surveyor the point in IfcSite. But going lower in the IFC Structure, the designing teams must have the ability to impact the GUIDs since they are working on the same IfcBuilding/s and have the same IfcStoreys. One problem that might be here is the definition of storeys in multiple buildings. One building has a roof above the 10th floor , whereas another building a roof above the 8th floor. Semantically, the structure should be able understand that even these storeys are at different heights, they have the same function. Only in such a case, federating models from different disciplines together, the same GUIDs makes sense for their correlation.
Sadly this freedom of “manipulating” GUIDs in the BIM authoring tools is not allowed, at least with the ones I was in contact. Or the manipulation in hand does not bring the requested results. I will have to give it a try to start a project from the same “source” as @stefkeB stating and see where the problems appear.
@Moult do you have experience with changing the GlobalID in BlenderBIM at the level of IfcProject? what is the impact on the whole ifc sctructure?
That’s when patching comes in But it does require a bit of a workflow to be set up.
Sorry, don’t quite understand the question. I have indeed changed the GlobalID at the level of the IfcProject before. Apart from keeping things correct from a data “primary key” point of view, it has no adverse impact (in IFC-SPF, that is … which effectively uses line numbers to reference entities in the current STEP version).
I did not find any pages explaning this methodology, of when a GUID can be the same in IFC files.
For the general users, that would be quite helpful ex. here.
Together with the ability to link and reference IFC objects from external files (or databases, or any repository of any kind), this makes for a very powerful methodology of managing data.
The current situation of single-file-contained IFC-SPF is a limitation of the current selected STEP version and the vendor implementations - the underlying conceptual approach of treating BIM data as a data repository (file based, SQL database, whatever) is still the intention
Maybe the best way to do this for IFC2x3 and IFC4 is to have one stakeholder/designer create a simple file that has the basic structure for the project (possibly including some placeholder objects/geometry) and then exporting the file to IFC for others to import. This is part of what the Model Setup IDM addresses (mainly focused on geo-referencing using this process). More info is in the Standards Library. Look at the “Geo-referencing in IFC” materials under “Technical Reports”.
For the future (IFC5?), one could suppose to use the same file as a “project setup basis” to reference the data into other systems and models. That would be an interesting use case to test.
@jwouellette - the intention is good but the execution fails in some BIM programs. For example, in Revit, geolocation information is not imported and is deleted. Also, levels are added and removed throughout the project, and this is not practical to achieve once the design process has begun, as copied objects from an IFC file in Revit lose their GlobalIds. Revit also loses all the spatial structure information as it only supports one site and building.
These problems have been reported to Autodesk. No response was given.
I have not tested this workflow with other major BIM applications. The workflow works with the BlenderBIM Add-on, but that’s all I can vouch for.
Since many of the stakeholders throughout the world are still working in IFC2x3 (including myself), an explanation about how to implement and at which level this GUID story would be helpful. That is the reason why I have referenced a link. Until IFC5 takes over the majority of the projects, it will take some time…
@jwouellette
I am currently experimenting on this step with my consultants working in different BIM authoring tools. I already see some problems ahead, as also @Moult explanis. On of them is for example is the IfcLabel for PHASE located at the IfcProject. And as you mention an IDM could be a solution to define the tasks of which parameters and at what stage should be generated by which stakeholder.
For more, I will write when I get back the IFCs…
Simple. Off-topic. I can’t see where the IDM Configurator/Toolkit is a part of this discussion. I think the previous response have a done a good job of highlighting the issues. The project you are referring to is a framework for developing and documenting IDMs (use cases, exchange requirements, process maps, etc.). That’s it. It doesn’t solve the problem stated. This is a more fundamental issue of how to reconcile GUIDs of a single concept across multiple sources. While the expectation or need are being clarified, the technical and process resolutions are not, given the issues described. The issues involve the technical underpinnings of software NOT creation of an IDM or resulting MVD. The problem exists completely independent of that.
Personally I don’t have enough knowledge to decide which one is perfect? GUID or Namespace?
Pixar was using GUID before but dropped it, GS1 uses namespace too, …
No GUIDS
USD uses a textual, hierarchical namespace to identify its data, which means it is “namespace paths” by which overrides bind to their defining prims/properties. In consequence, when the internal namespace of a referenced asset changes, higher-level overrides previously recorded in referencing assets will fall off . One solution to this problem is to identify data by a “globally unique identifer” (GUID), and then associate overrides with the same GUID as the defining prim. While solving the namespace-editing problem, GUIDs introduce other problems into a pipeline, and potentially limitations on flexibility of composition. In past iterations of USD, Pixar used a form of GUID at the model/asset granularity, and after carefully weighing the pros and cons, we have decided that for us, the cost of occasional “namespace fix-up” operations run over a collection of assets is worth paying for the ease of asset construction and aggregation, and readable ascii asset representations that we get from namespace-paths as identifiers. (Source)
There is no formal definition wether the GUID refers to the virtual or physical object. In practice as currently implemented and used it can only refer to the virtual object.
You typically have several virtual objects representing a physical object, created by different organizations for different purposes and they all need to live in parallel and have their own GUIDS. The correct way to solve this is to use linked data technology to link these objects together. We have worked on this in Finland for many years in our DRUM projects.
Also IFC should be extended with placeholders for physical objetcs that would have the physical objects GUID:
After doing my small research with different BIM authoring tools I came to the conclusion that there is no common agreement of how these GUIDs should be handled during import/export of IFC files.
The test relied in a creation of a template IFC File where certain parameters have been defined and then this template imported by 4 different software solutions. As you can see in the below table, each software reacts differently.
These values represent the content of the exported IFC file (after importing the IFC template) to identify which of the imported values could be taken over. So, the more green cells we see, the better.
To my very big surprise Autodesk Revit came with the best results, but it does not mean it is ideal for further workflow. The Revit user reported that this method (import IFC and convert into RVT) was not the best since his revit template had to be generated from the beginning, meaning a bit time investment for each project and maybe even faulty libraries.
Archicad on the other hand imported correctly the GUIDs until the level of the IfcBuilingStorey, the same results as in DDS-CAD. In Plancal there are a bit more problems since not only the GUIDs but also parameters such as ProjectName cannot be manually changed.
There are other alphanumeric parameters that showed red in the table but can be adjusted by the user after import for future IFC exports. Sadly in most of the tested software, the GUID is locked and cannot be adjusted. There might be secondary software solutions that allow such manipulation, but is the the scenario we want to favor?
In my opinion the ideal way would be to create this ultimate template for the project which could be used by all stakeholders. Maybe the subject of Linked Data could be the solution, but sadly I don’t have much knowledge about that. This master IFC template could have also different GUID definitions and not necessarily always the same levels as in my test, for ex. IfcBuilding and especially IfcBuildingStorey in the project initiation are not clear, meaning they are defined later on during the development of the project. In this case IfcProject and IfcSite with their attributes are defined for the template.
@agron FYI the buildingSMART documentation clearly states (source):
the IFC-GUID is normally generated automatically and has to be persistent
Therefore, I trust any vendor who scores a red on a GUID field should consider it a bug to be fixed.
I agree with your Revit user’s conclusion that although Revit does maintain the data, it is not practical to be in use in a large project.
Would you mind sharing your template IFC file? That would be a good first step to helping vendors fix things.
I would also like to note for completeness that the following vendors do not seem to be certified yet by buildingSMART:
DDS-CAD (IFC4 import in progress)
Plancal Nova (no import certification)
Plancal extended (no certification)
Revit (if you are testing IFC4, import certification has been in progress since 2017)
ArchiCAD (if you are testing IFC4, import certification has been in progress since 2018)
Perhaps buildingSMART can advise their certification team or update their certification process to ensure that this template-based IDM workflow is both correct and practical?
The testing has been done only in ifc2x3. Since they they are not certified for ifc4 import, I even didn‘t bother in getting that road. I was hoping to find a common ground with this GUID, since today IFC2x3 is the most common version used in the market.
Here is the Nemesis.ifc (86.7 KB) that I had created. Just for Info: it posseses also slabs, since a part of my test was to see if this GUID during import/export has any impact on the IfcBuildingElement. But that is another case…
Perhaps buildingSMART can advise their certification team or update their certification process to ensure that this template-based IDM workflow is both correct and practical?
But it does require a bit of a workflow to be set up.
