The new update "Append "(Type)" to all internal Revit type property sets, to avoid having multiple property sets with the same name assigned to the same IFC entity." has completely broken our COBie validation process. It has also broken the links for the cost managers who pull data from specific places within the IFC.
We have invested significant time in creating rulesets within Solibri to check the validity of COBie data. All COBie data would sit under the data parameter group, now with this change it splits the data into two locations. Can you please add functionality to have this as an optional requirement? It doesn't export the data representative of what has been authored in Revit which is a big problem for us.
Any support would much appreciated.
Thanks,
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The previous method of having two property sets associated with the same element was considered illegal by other vendors/IFC implementors. I'll share this feedback with the MSG group given that we want COBie to work properly - I'll see if I can get Thomas Liebich to respond.
Regards,
Angel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
+1 And wouldn't it be possible to simply merge property sets with the same name during export. I think that would solve Alex problems but also keep the vendors happy. The instance/type diffentation isn't really needed in Ifc at the moment although it could be intresting for a model exchange mvd.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I talked to Thomas Liebich, and with the suggestion above, I recommend the following:
If a type property set is associated with a type element, leave the original name alone. This is allowed, anyway.
If a type property set is associated with an instance element, and it has a duplicate name, merge it.
does have a problem, though. If the instance and type property sets both contain a property of the same name, then what happens? Do we prefer one (say, the instance one), or do we rename one of the properties?
It looks like we are getting to a solution here, but for that one last bit :)
Angel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would suggest an instance suffix for the instance parameter. Although, a check your model suffix would be appropriate because this a situation you would always want to avoid. SImilar parameter names have always been a problem in the similar named property sets anyway, you never know which one is used. Maybe an error message in revit flaging similar naming in the same object would also be helpfull.
Ewoud
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Shouldn't an instance parameter override a type parameter of the same name? Keep in mind that from Revit's point of view, the instance and type are different elements; it is only sometimes when exporting to IFC that we don't have a type.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
+1 for the post of Alex.
@Angel. The instance IfcExportAs for example overwrites the type settings of the object when exported. So if the one overwrites the other I don't see a problem in merging and end up with just one parameter of the 2. Because you manualy wanted the overwrite in Revit in the first place (for some reason)? (I must say that I don't use this workmethod using overwrites by instance myself but I think your right that de instance overwrites (replaces) the type parameter at this point).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why not create types in ifc associated to the instances akin to how it is structured in Revit?
Even if the only feature of the ifc type is a parameter/property association. I've always wondered why Revit hasn't exported ifc with this relationship.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We do for most of them, There are a couple of IFC2x3 objects that don't have types, and a few that we just haven't implemented yet. I agree that the easiest solution for some of these issues is just to export more types, and your suggestion of at least having it for the parameter/property association makes a ton of sense.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Angel,
Could you explain this? So what you're saying is that in the current IFC exports the type instance structure of Revit is stored in the IFC including their properrty sets. This would mean IFC readers such as Navisworks, Solibri etc. would be able to show this structure? Which isn;t the case. I know IFC4 has more advanced type/instance support is IFC4 export supporting this better? Just curious where we are at the moment with regards to development and what's limiting things at the moment. The file readers or the exporter?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A treatise on Revit and IFC follows. Don't read close to bedtime :)
Revit has (generically speaking) elements and element types. In addition, some element types belong to families, while others belong to "system families" (which aren't really families, but just placeholders). Elements and element types in Revit can have properties independent of each other. It is undefined in Revit what it means for an element and its type to have the same property with different parameters; that's up to the user to decide. In IFC, for parameters that actually do something on export (e.g. "IfcExportAs") we generally take it to mean that the element parameter value overrides the element type parameter value.
Now, IFC has IfcElements and IfcTypeObjects. IfcElements correspond roughly to Revit elements; IfcTypeObjects correspond roughly to Revit element types. Nothing in IFC corresponds to Revit families, so that's always a source of data loss when exporting to IFC. In general, we can export the Revit element to an IfcElement, and associate it with its properties, and we can export a Revot element type to an IfcTypeOject and associate it with its properties.
In addition, Revit element types can contain shared geometry or parametric information that all elements of that type share. For walls, for instance, the wall type contains the information about the layer structure. For families, the type contains all of the geometry; the instance contains just the placement and orientation. Now IFC contains both the IfcMaterialLayerSet (for walls) and IfcMappedItems/IfcRepresentationMaps (for families), but it has a slightly looser definition. An IfcRepresentationMap, which contains shared geometry, doesn't have to be associated with a type, which is very different from Revit; this can cause issues when trying to figure out how to read the geometry.
Bringing it all back to the original subject, then, on export:
1. We sometimes export elements as IfcElement and element types as IfcTypeProducts. This works well.
2. We sometimes don't export the element type as IfcTypeProduct because that is missing for a particular element type. This means that we have to put both the instance and type parameters on the IfcElement, and make sure that they don't repeat names.
3. We sometimes don't export the element type as IfcTypeProduct for system families that don't share geometry.
After this thread, my intention is to stop doing #3 - if there is a type, we'll export it. I don't think there are a lot of cases of #2, so we might not need to do anything at all in IFC2x3 for this for practical cases. With #1 and #3 done, we can then only use "(Type)" for the few cases of #2, which we can check.
Once this work is done, I'll check back with the thread to make sure the solution is acceptable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Followup question - we can make incremental work that would remove the "(Type)" from all elements that exported an instance and type entity, and work over time to make sure everything that can have a type entity does. That would reduce, but not eliminate, the number of property sets with "(Type)" after them. Is that better than now or does it have to be all or nothing?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry to be difficult, for me it should be all or nothing. We need to have consistency. I think the solution you have at the moment works, merging Type and Instances properties with the same name is dangerous. I have a major end of stage COBie validation process coming up and so it means major re-work for me (and Solibri as a software providor) to align with this change.
Ideally, having the option in the UI to append (type) to type property sets would be great, is this possible?
Cheers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(But I pick only the things I need through p-sets anyway, and do not bother with the "export everything" approach that the Revit parameter sets lead to)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
is it not possible to get both the type and instance parameters on the same Pset? When the data tap has the same name? I think that is where it is going wrong. Solibri collects all parameters to choose from. And Navisworks just the parameters from the first tab it can find and then stops. If it were all the same data tab, there would not be a problem
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's possible (although not trivial) but it isn't what's actually in Revit. In Revit, you may have an instance property and a type property of the same name with different values. Joining them with some rule is guaranteeing data loss. Of course, that's not to say that it's not acceptable data loss, but between the effort to do it and the data loss, we have to proceed with caution.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Angel,
Thanks for the replies. It clarifys things a bit. But back to pratical day to day use on live projects.
First of all, I do prefer my own parameter mapping, but having a quick and easy data dump option like export all revit parameters is very usefull.
Arjan is discribing the exact day to day practical use case problem we had in the old situation. The new Type suffix for property set naming kills your preset takeoffs and is even worse like Alex explained. Type and instance can differ by family so talk about data loss and missing stuff. So I do think a merging option in the exporter would really help for now although it might not be the prefered future method. I would be happy to check a model on the double name suffix or preffix in parameter names to filter out the double parameter naming situations. For day to day use merging the property sets would be very helpfull.
I really hope you're able to add this to the exporter.
Thanks,
Ewoud
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Angel, I completely understand that the schema needs differentiate between identical instance and type properties, right now, I need a quick and dirty way to have all type and instance properties to fall under the one property set 'data' as they used to. It will take me a solid 2 days to rewrite our validation process to deal with this change, will it take you guys longer that that to add the option in the UI to export duplicate property sets as before albeit non-compliant? Or, if I ask the designers to revert back to the older exporter, have there been any major bug fixes that I should watch out for?
Thanks for your help.
Alex.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, we'll take a dual approach - we'll add Types that are missing, and we'll add Advanced UI to create an "invalid" IFC file to allow you to get your (and others) validation to continue to work.
Regards,
Angel
Last edit: Angel Velez 2016-09-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am struggling with this “append type” thing. The IFC show double property sets like Identity Data and Identity Data(Type). Does someone have a solution for this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In your particular case, it looks like IFCDOORSTYLE isn't treated properly as a type entity, and the (Type) is being appended. As a hacky workaround, you can just replace
(Type)'
with
'
in the IFC file. Note that you don't want to do that in general, because then you could have property sets with duplicate names for the same entity. In this case, though, it doesn't seem like that's the case.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I opened the IFC file and found the IFCDOORSTYLE. It says in these lines that something is 'not defined'. What could that be? For the IFCDOORPANELPROPERTIES there is also something 'not defined'.
The workaround you mentioned is not a solution, but i want to fix the problem.
Hi Guys,
The new update "Append "(Type)" to all internal Revit type property sets, to avoid having multiple property sets with the same name assigned to the same IFC entity." has completely broken our COBie validation process. It has also broken the links for the cost managers who pull data from specific places within the IFC.
We have invested significant time in creating rulesets within Solibri to check the validity of COBie data. All COBie data would sit under the data parameter group, now with this change it splits the data into two locations. Can you please add functionality to have this as an optional requirement? It doesn't export the data representative of what has been authored in Revit which is a big problem for us.
Any support would much appreciated.
Thanks,
Alex
+1
Hi Alex (and Troels),
The previous method of having two property sets associated with the same element was considered illegal by other vendors/IFC implementors. I'll share this feedback with the MSG group given that we want COBie to work properly - I'll see if I can get Thomas Liebich to respond.
Regards,
Angel
+1 And wouldn't it be possible to simply merge property sets with the same name during export. I think that would solve Alex problems but also keep the vendors happy. The instance/type diffentation isn't really needed in Ifc at the moment although it could be intresting for a model exchange mvd.
I talked to Thomas Liebich, and with the suggestion above, I recommend the following:
If a type property set is associated with an instance element, and it has a duplicate name, merge it.
does have a problem, though. If the instance and type property sets both contain a property of the same name, then what happens? Do we prefer one (say, the instance one), or do we rename one of the properties?
It looks like we are getting to a solution here, but for that one last bit :)
Angel
I would suggest an instance suffix for the instance parameter. Although, a check your model suffix would be appropriate because this a situation you would always want to avoid. SImilar parameter names have always been a problem in the similar named property sets anyway, you never know which one is used. Maybe an error message in revit flaging similar naming in the same object would also be helpfull.
Ewoud
Shouldn't an instance parameter override a type parameter of the same name? Keep in mind that from Revit's point of view, the instance and type are different elements; it is only sometimes when exporting to IFC that we don't have a type.
+1 for the post of Alex.
@Angel. The instance IfcExportAs for example overwrites the type settings of the object when exported. So if the one overwrites the other I don't see a problem in merging and end up with just one parameter of the 2. Because you manualy wanted the overwrite in Revit in the first place (for some reason)? (I must say that I don't use this workmethod using overwrites by instance myself but I think your right that de instance overwrites (replaces) the type parameter at this point).
Why not create types in ifc associated to the instances akin to how it is structured in Revit?
Even if the only feature of the ifc type is a parameter/property association. I've always wondered why Revit hasn't exported ifc with this relationship.
We do for most of them, There are a couple of IFC2x3 objects that don't have types, and a few that we just haven't implemented yet. I agree that the easiest solution for some of these issues is just to export more types, and your suggestion of at least having it for the parameter/property association makes a ton of sense.
Hi Angel,
Could you explain this? So what you're saying is that in the current IFC exports the type instance structure of Revit is stored in the IFC including their properrty sets. This would mean IFC readers such as Navisworks, Solibri etc. would be able to show this structure? Which isn;t the case. I know IFC4 has more advanced type/instance support is IFC4 export supporting this better? Just curious where we are at the moment with regards to development and what's limiting things at the moment. The file readers or the exporter?
A treatise on Revit and IFC follows. Don't read close to bedtime :)
Revit has (generically speaking) elements and element types. In addition, some element types belong to families, while others belong to "system families" (which aren't really families, but just placeholders). Elements and element types in Revit can have properties independent of each other. It is undefined in Revit what it means for an element and its type to have the same property with different parameters; that's up to the user to decide. In IFC, for parameters that actually do something on export (e.g. "IfcExportAs") we generally take it to mean that the element parameter value overrides the element type parameter value.
Now, IFC has IfcElements and IfcTypeObjects. IfcElements correspond roughly to Revit elements; IfcTypeObjects correspond roughly to Revit element types. Nothing in IFC corresponds to Revit families, so that's always a source of data loss when exporting to IFC. In general, we can export the Revit element to an IfcElement, and associate it with its properties, and we can export a Revot element type to an IfcTypeOject and associate it with its properties.
In addition, Revit element types can contain shared geometry or parametric information that all elements of that type share. For walls, for instance, the wall type contains the information about the layer structure. For families, the type contains all of the geometry; the instance contains just the placement and orientation. Now IFC contains both the IfcMaterialLayerSet (for walls) and IfcMappedItems/IfcRepresentationMaps (for families), but it has a slightly looser definition. An IfcRepresentationMap, which contains shared geometry, doesn't have to be associated with a type, which is very different from Revit; this can cause issues when trying to figure out how to read the geometry.
Bringing it all back to the original subject, then, on export:
1. We sometimes export elements as IfcElement and element types as IfcTypeProducts. This works well.
2. We sometimes don't export the element type as IfcTypeProduct because that is missing for a particular element type. This means that we have to put both the instance and type parameters on the IfcElement, and make sure that they don't repeat names.
3. We sometimes don't export the element type as IfcTypeProduct for system families that don't share geometry.
After this thread, my intention is to stop doing #3 - if there is a type, we'll export it. I don't think there are a lot of cases of #2, so we might not need to do anything at all in IFC2x3 for this for practical cases. With #1 and #3 done, we can then only use "(Type)" for the few cases of #2, which we can check.
Once this work is done, I'll check back with the thread to make sure the solution is acceptable.
Followup question - we can make incremental work that would remove the "(Type)" from all elements that exported an instance and type entity, and work over time to make sure everything that can have a type entity does. That would reduce, but not eliminate, the number of property sets with "(Type)" after them. Is that better than now or does it have to be all or nothing?
Hi Angel,
Sorry to be difficult, for me it should be all or nothing. We need to have consistency. I think the solution you have at the moment works, merging Type and Instances properties with the same name is dangerous. I have a major end of stage COBie validation process coming up and so it means major re-work for me (and Solibri as a software providor) to align with this change.
Ideally, having the option in the UI to append (type) to type property sets would be great, is this possible?
Cheers.
Reduce asap, and eliminate down the road I'd say.
(But I pick only the things I need through p-sets anyway, and do not bother with the "export everything" approach that the Revit parameter sets lead to)
is it not possible to get both the type and instance parameters on the same Pset? When the data tap has the same name? I think that is where it is going wrong. Solibri collects all parameters to choose from. And Navisworks just the parameters from the first tab it can find and then stops. If it were all the same data tab, there would not be a problem
It's possible (although not trivial) but it isn't what's actually in Revit. In Revit, you may have an instance property and a type property of the same name with different values. Joining them with some rule is guaranteeing data loss. Of course, that's not to say that it's not acceptable data loss, but between the effort to do it and the data loss, we have to proceed with caution.
Hi Angel,
Thanks for the replies. It clarifys things a bit. But back to pratical day to day use on live projects.
First of all, I do prefer my own parameter mapping, but having a quick and easy data dump option like export all revit parameters is very usefull.
Arjan is discribing the exact day to day practical use case problem we had in the old situation. The new Type suffix for property set naming kills your preset takeoffs and is even worse like Alex explained. Type and instance can differ by family so talk about data loss and missing stuff. So I do think a merging option in the exporter would really help for now although it might not be the prefered future method. I would be happy to check a model on the double name suffix or preffix in parameter names to filter out the double parameter naming situations. For day to day use merging the property sets would be very helpfull.
I really hope you're able to add this to the exporter.
Thanks,
Ewoud
Hi Guys - apologies I have been on annual leave.
Angel, I completely understand that the schema needs differentiate between identical instance and type properties, right now, I need a quick and dirty way to have all type and instance properties to fall under the one property set 'data' as they used to. It will take me a solid 2 days to rewrite our validation process to deal with this change, will it take you guys longer that that to add the option in the UI to export duplicate property sets as before albeit non-compliant? Or, if I ask the designers to revert back to the older exporter, have there been any major bug fixes that I should watch out for?
Thanks for your help.
Alex.
OK, we'll take a dual approach - we'll add Types that are missing, and we'll add Advanced UI to create an "invalid" IFC file to allow you to get your (and others) validation to continue to work.
Regards,
Angel
Last edit: Angel Velez 2016-09-07
Great. Thanks Angel.
Do you know if it will be released by 21 September? If not, I will need to re-write the validation procedures anyway.
Thanks again,
Alex
Unlikely. I would revert to an older version for now unless you desperately need a code fix from the last version.
I am struggling with this “append type” thing. The IFC show double property sets like Identity Data and Identity Data(Type). Does someone have a solution for this?
In your particular case, it looks like IFCDOORSTYLE isn't treated properly as a type entity, and the (Type) is being appended. As a hacky workaround, you can just replace
(Type)'
with
'
in the IFC file. Note that you don't want to do that in general, because then you could have property sets with duplicate names for the same entity. In this case, though, it doesn't seem like that's the case.
I opened the IFC file and found the IFCDOORSTYLE. It says in these lines that something is 'not defined'. What could that be? For the IFCDOORPANELPROPERTIES there is also something 'not defined'.
The workaround you mentioned is not a solution, but i want to fix the problem.