I noticed that if there is any $ character in the IFC GUID, they are removed from the id in the exported DAE file. This is not very consistent to map the id from the DAE objects with original IFC objects. Is there a way to fix it? Thank you very much!
Best wishes,
Pine
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I realize this can be unfortunate. However, as far as I know, the identifiers in Collada files need to conform xsd:ID [1]. This means that it must start with a letter or underscore, and can only contain letters, digits, underscores, hyphens, and periods. That's the reason. If you have a suggestion to work around this, let me know, but I must admit that the IfcConvert output is not designed to be easily parsed and correlated back to the data in the IFC file.
Thank you very much for your responses to both of my questions. I totally understand that the design intent has it's reasons. Just a quick suggestion on the GUID issue, is it OK to just use the IFC line number as the ID in the DAE file? The line number is unique in an IFC file so that it can behave similar as the GUID. This will make it inconsistent if anyone wants to modify the IFC model and relink with the previous model. But for the IfcConvert tool I think this won't be an issue, right? Thank you very much!
Best wishes,
Pine
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, I agree this should be made more consistent and predictable. How would you feel about using the more standard RFC 4122 notation for the GlobalId?
This would imply writing:
node-a92fca97-d753-4391-9571-6ddc6febd423
instead of:
2fBygNrrD3aPLnRTnlwzGZ
These are merely different notations for the same data, the first being hexadecimal, the IFC GlobalId being base64 encoded.
Kind regards,
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I fully agree. As long as there is a way to link back to the IFC objects, I think it would be very helpful so that others can also benefit from IfcConvert. I will be looking forward to a change like this to make it more consistent. Thank you!
Best wishes,
Pine
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I noticed that if there is any $ character in the IFC GUID, they are removed from the id in the exported DAE file. This is not very consistent to map the id from the DAE objects with original IFC objects. Is there a way to fix it? Thank you very much!
Best wishes,
Pine
Hi Pine,
I realize this can be unfortunate. However, as far as I know, the identifiers in Collada files need to conform xsd:ID [1]. This means that it must start with a letter or underscore, and can only contain letters, digits, underscores, hyphens, and periods. That's the reason. If you have a suggestion to work around this, let me know, but I must admit that the IfcConvert output is not designed to be easily parsed and correlated back to the data in the IFC file.
[1] http://www.datypic.com/sc/xsd/t-xsd_ID.html
Kind regards,
Thomas
Hi Thomas,
Thank you very much for your responses to both of my questions. I totally understand that the design intent has it's reasons. Just a quick suggestion on the GUID issue, is it OK to just use the IFC line number as the ID in the DAE file? The line number is unique in an IFC file so that it can behave similar as the GUID. This will make it inconsistent if anyone wants to modify the IFC model and relink with the previous model. But for the IfcConvert tool I think this won't be an issue, right? Thank you very much!
Best wishes,
Pine
Hi Pine,
Actually, I agree this should be made more consistent and predictable. How would you feel about using the more standard RFC 4122 notation for the GlobalId?
This would imply writing:
instead of:
These are merely different notations for the same data, the first being hexadecimal, the IFC GlobalId being base64 encoded.
Kind regards,
Thomas
Hi Thomas,
I fully agree. As long as there is a way to link back to the IFC objects, I think it would be very helpful so that others can also benefit from IfcConvert. I will be looking forward to a change like this to make it more consistent. Thank you!
Best wishes,
Pine
Hi,
Implemented in r350. Hope it will make IfcConvert output more useful to you.
Kind regards,
Thomas