Probably not an exporter issue, but I'm just wondering how to get the IfcGUID visible on elements which are copied within the model.
A model with a floor, exported with the option "Store the IFC GUID in an element parameter after export", will get the parameter IfcGUID with a (visible) GUID after the export.
But when I copy the floor and paste it within the same model, and I export the model again, then the IfcGUID stays empty (in the Revit model). The export of the GUID to the GlobalId in the IFC-model is OK (of course it is another GUID, since the copied floor is a different occurrence).
Is there any way to force the visibility of the value within Revit? Or is there some repair possibility? (An audit isn't repairing this).
This isn't a particular issue of 18.3.2. It has been around some time. I also noticed it with copied rooms, but for some reason I always hoped that it would magically solve itself over time, or something like that.
The IfcGUID isn't determined until you export. When you copy/paste, that value is emptied out since you can't have the same GUID twice. That's the current system, anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand that the IfcGUID is generated by export, and then written back to the model. But I'm wondering why after the 2nd export of the copied element, the IfcGUID isn't overwritten with the new IfcGUID, so that the value is again visible in the Revit model.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Aha, right. I think it is because the IfcGUID parameter is read-only, which causes problems like that. I've been thinking about making it read/write, so that (1) it is overwriteable by the IFC code, (2) you can copy/paste it (which I've always found annoying) and (3) you can manually override it. Then downside is that there is the potential for human error. Worth it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually I think it's worth. For 'normal' elements, including rooms, it is in my opinion preferable that the exporter overwrites the value automatically. Especially for Project/Site/Building/BuildingStorey it would be nice to be able to manually override it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Angel,
It would be really helpful if the IfcGUID parameter would be read/write OR if the IFC exporter would check empty IfcGUID, then delete them to create a new populated IfcGUID.
Our clients demand us to deliver IFCs in which 100% of the objects contain an IfcGUID. The reason is that this is the link between the IFC models and de Facility Management Software.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I wrote above << Especially for Project/Site/Building/BuildingStorey it would be nice to be able to manually override it >>
Actually I discovered that for IfcProject, IfcSite and IfcBuilding it is indeed possible to choose your own GlobalID, which you can easily use in all the aspectmodels.
Before you do any IFC-export with the option "Store the IFC GUID in an element parameter after export"),
add the 3 following parameters in the group of IFC Parameters, and give it a valid bogus GlobalId.
IfcProject GUID:
aAbBcCdDeEfFgGhHiIjJ$P
IfcSite GUID:
aAbBcCdDeEfFgGhHiIjJ$S
IfcBuilding GUID:
aAbBcCdDeEfFgGhHiIjJ$B
After export, even with the option "Store the IFC GUID in an element parameter after export" you will be able to change these values.
The shared parameters are:
PARAM e1e476d9-0263-45c7-988e-2fd2c7acb478 IfcProject GUID TEXT 22 1 1
PARAM 09f4373f-3845-4cd1-a0dd-10356af361c7 IfcSite GUID TEXT 22 1 1
PARAM 193baa1c-46cb-4fa2-983c-e3d67d5e1f1d IfcBuilding GUID TEXT 22 1 1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I added a command and form in ggRevitIFC to permit nomination or replacement of the builtin parameter values at any time if anyone wants to test and provide feedback. www.geometrygym.com
Thx Jon for this nice Xmas present!
It is a very handy tool to make the GUIDs of these 3 entities (IfcProject/IfcSite/IfcBuilding) consistent between the federated models (aspectmodels), without the fuss of the workaround as I described.
Regards,
Dirk
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In relation to the original query of this post, I just pushed a commit to the dev branch of the exporter that improves the setting of the GlobalId to elements that are copied from an element with the GlobalId previously set.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Even more thx!
With this commit, combined with the 'Extract IFC Ids' tool in your Xmas present, it is now possible to reveal the hidden IfcGUIDs of copied elements.
Although it would be nice that the reveal action is automatically done by the exporter itself, at least this tool is now already solving the problem!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Probably not an exporter issue, but I'm just wondering how to get the IfcGUID visible on elements which are copied within the model.
A model with a floor, exported with the option "Store the IFC GUID in an element parameter after export", will get the parameter IfcGUID with a (visible) GUID after the export.
But when I copy the floor and paste it within the same model, and I export the model again, then the IfcGUID stays empty (in the Revit model). The export of the GUID to the GlobalId in the IFC-model is OK (of course it is another GUID, since the copied floor is a different occurrence).
Is there any way to force the visibility of the value within Revit? Or is there some repair possibility? (An audit isn't repairing this).
This isn't a particular issue of 18.3.2. It has been around some time. I also noticed it with copied rooms, but for some reason I always hoped that it would magically solve itself over time, or something like that.
Regards,
Dirk
Last edit: Dirk Van Rillaer 2018-04-29
The IfcGUID isn't determined until you export. When you copy/paste, that value is emptied out since you can't have the same GUID twice. That's the current system, anyway.
I understand that the IfcGUID is generated by export, and then written back to the model. But I'm wondering why after the 2nd export of the copied element, the IfcGUID isn't overwritten with the new IfcGUID, so that the value is again visible in the Revit model.
Aha, right. I think it is because the IfcGUID parameter is read-only, which causes problems like that. I've been thinking about making it read/write, so that (1) it is overwriteable by the IFC code, (2) you can copy/paste it (which I've always found annoying) and (3) you can manually override it. Then downside is that there is the potential for human error. Worth it?
Actually I think it's worth. For 'normal' elements, including rooms, it is in my opinion preferable that the exporter overwrites the value automatically. Especially for Project/Site/Building/BuildingStorey it would be nice to be able to manually override it.
Hi Angel,
It would be really helpful if the IfcGUID parameter would be read/write OR if the IFC exporter would check empty IfcGUID, then delete them to create a new populated IfcGUID.
Our clients demand us to deliver IFCs in which 100% of the objects contain an IfcGUID. The reason is that this is the link between the IFC models and de Facility Management Software.
Copying a element and pasting it should empty the IFCGuid or delete it and then the exporter should create a new one.
As I wrote above << Especially for Project/Site/Building/BuildingStorey it would be nice to be able to manually override it >>
Actually I discovered that for IfcProject, IfcSite and IfcBuilding it is indeed possible to choose your own GlobalID, which you can easily use in all the aspectmodels.
Before you do any IFC-export with the option "Store the IFC GUID in an element parameter after export"),
add the 3 following parameters in the group of IFC Parameters, and give it a valid bogus GlobalId.
aAbBcCdDeEfFgGhHiIjJ$P
aAbBcCdDeEfFgGhHiIjJ$S
aAbBcCdDeEfFgGhHiIjJ$B
After export, even with the option "Store the IFC GUID in an element parameter after export" you will be able to change these values.
The shared parameters are:
PARAM e1e476d9-0263-45c7-988e-2fd2c7acb478 IfcProject GUID TEXT 22 1 1
PARAM 09f4373f-3845-4cd1-a0dd-10356af361c7 IfcSite GUID TEXT 22 1 1
PARAM 193baa1c-46cb-4fa2-983c-e3d67d5e1f1d IfcBuilding GUID TEXT 22 1 1
I added a command and form in ggRevitIFC to permit nomination or replacement of the builtin parameter values at any time if anyone wants to test and provide feedback. www.geometrygym.com
https://twitter.com/geometrygym/status/1076953794204712963?s=21
Last edit: JonM 2018-12-26
Thx Jon for this nice Xmas present!
It is a very handy tool to make the GUIDs of these 3 entities (IfcProject/IfcSite/IfcBuilding) consistent between the federated models (aspectmodels), without the fuss of the workaround as I described.
Regards,
Dirk
In relation to the original query of this post, I just pushed a commit to the dev branch of the exporter that improves the setting of the GlobalId to elements that are copied from an element with the GlobalId previously set.
Even more thx!
With this commit, combined with the 'Extract IFC Ids' tool in your Xmas present, it is now possible to reveal the hidden IfcGUIDs of copied elements.
Although it would be nice that the reveal action is automatically done by the exporter itself, at least this tool is now already solving the problem!
crossover reference: https://github.com/Autodesk/revit-ifc/issues/78
- issue of the empty IfcGUID is fixed with the update to R2019.2
- it is now also possible to overwrite each IfcGUID