Today is the first day of the Munich DevLab. This one is for five whole days. I am looking forward to the week here and will be very pleased if it is as exciting and productive as the two days at the Waltham DevLab.
Meanwhile and unrelated to the DevLabs, Håkon Clausen of Nosyko AS commented on the UniqueId, DWF and IFC GUID discussion and submitted a port of the IFC GUID algorithm discussed there to C#. He also has an issue with the IFC GUID associated with certain types in the model:
Comment: Since I'm not a great fan of dependencies to unmanaged code I did some work on converting the C part to C#. I could post it if someone is interested.
I'm having some trouble though with mismatch between the GUID I calculate and the one exported to IFC.
If I try to calculate the IFC GUID for some family symbols it works only for some of them.
For instance, the GUID on furniture types seems to match with the GUID on the corresponding IFC object IfcFurnitureType. However the GUID on a door symbol does not correspond with the GUID on the exported IfcDoorStyle. I guess it has to do with the IfcDoorStyle often being exported multiple times for some strange reasons, but even if it's one to one, the GUID does not match. Is there any way to calculate the right GUID for these elements too?
Response: I cannot say much about why it might fail for some family symbols.
In Revit 2011, there is a new API method which may provide the correct exported element GUIDs that you are looking for:
Export id: The static method ExportUtils.GetExportId retrieves the GUID representing an element in DWF and IFC export. This id is used in the contents of DWF export and IFC export and it should be used only when cross-referencing to the contents of these export formats. When storing Ids that will need to be mapped back to elements in future sessions, UniqueId must be used instead.
Answer: Thanks for the tip. I was not aware of that GetExportId function. After testing it, I guess this does the same that you showed in your post on how to get from the Revit UniqueID string to a .NET GUID. Here is a solution IfcGuidHakon.zip including the translation of the IFC GUID algorithm to C#. I placed some documentation in the code. My reason for translating it was simply to avoid native code and possibly deployment issues on 32 bit and 64 bit platforms.
My use case is to export ID's that will later be used in an external application and compared against an IFC export. I have found that this technique works very well for a lot of elements (e.g. rooms) but family symbols are a little tricky it seems (and I do not mean instances - my application is only concerned with the number of instances for a given symbol, not the instances in itself). The ExportUtils.GetExportId did not help either. I think that the reason is perhaps in the IFC export and also that there is not always a 1-1 match between Revit and the exported IFC model. Taking the Basic example from Revit 2011, a door symbol (e.g. Single-Flush 813x2134) that is exported as an IfcDoorStyle does not have the same GUID as the one encoded from the door symbol, but as I mentioned, all furniture types match. That specific door symbol is also exported as two IfcDoorStyle instances for some reason, perhaps because of the some difference in geometry. It seems like there is no way to identify the Revit family symbol based on the information on the corresponding IFC object. There is a TAG attribute on the IFC objects (6 digit integer) but I have not found out where that information is coming from in Revit.
Here is IfcGuidHakon.zip containing the complete source code and Visual Studio solution of this algorithm and a command line program for testing it.
Update
2014-07-02: Thanks to the issue reported by Paul Marsland in the comment below, Håkon took another look at the code and replied:
I tracked down a bug in the algorithm. It was a silly typo, a call to BitConverter.ToInt16 should be BitConverter.ToUInt16 like all the rest...
I updated the code a bit, added some tests and created the IfcGuid GitHub repository to host it.
A couple of years ago I ran into something like Håkon's problem. I don't know that I can solve it - but I might be able to explain it.
Door Geometry can be fundamentally different depending on the thickness of wall that the door is hosted in. At one point a few years back, I found that in some export cases there were "special" family symbols which were representing the different symbol/thickness variations.
For what it's worth - as they say :).
-Matt
Posted by: Matt Mason | June 30, 2010 at 12:49
Dear Matt,
Thank you very much for your note. Yes, this is in fact analogous to the issue discussed for columns in
http://thebuildingcoder.typepad.com/blog/2010/02/retrieving-column-and-stair-geometry.html
Cheers, Jeremy.
Posted by: Jeremy Tammik | June 30, 2010 at 13:18
If anyone is looking for the VB.Net conversion of Håkon's code, I've posted a working version of the IfcGuid module here: http://arupforge.arup.com/wiki/index.php?title=IFC_Guids_in_VB.Net
Note, this is one of those cases where C# != VB.net, so a straight forward syntax conversion wasn't enough.
Posted by: Stevedowning | July 16, 2010 at 03:39
Dear Jeremy, Can you please help me to find coordinates of door or any other elements in IFC files? I am not finding any class which can give the coordinates. Also the structure of a IFC file. How it gives the elements information and its properties?
Please help me.
Posted by: Nilesh | July 11, 2012 at 06:05
Dear Nilesh,
An IFC file is not a trivial animal. I would suggest using a full-fledged toolkit to tackle it.
Cheers, Jeremy.
Posted by: Jeremy Tammik | August 22, 2012 at 07:42
Hi all,
I wonder if its possible that Håkon's algorithm can have some kind of open source license like the MIT attached so that it can be actually picked up by the industry! Its a pity that we cannot actually use this translation of the C code in our C# projects because of IP issues!
By the way, where is the original C code and how it is licensed? It could be that the "translation" is not valid at all (i am not a lawyer!). Nobody seems to care about legal issues much, but we have to, as we are in the process of open-sourcing our code, and dont wont to depend on viral licenses like GPL, and also dont want to breach a copyright!
Posted by: Joerg | April 05, 2013 at 21:57
Dear Joerg,
Oh dear, I am awfully sorry that you are faced with these issues.
I am not, thank God, and I have no idea. I am still hoping I will survive without being forced to deal with that kind of stuff.
As far as I know, I am the original author of the original C code that this is based on. That probably does not help, though.
As far as I can tell, this same code is used in many IFC implementations all over the place.
Probably you can find some copy somewhere which has a license attached to it.
Its actually pretty trivial, anyway.
Good luck!
Cheers, Jeremy.
Posted by: Jeremy Tammik | April 08, 2013 at 08:39
Jeremy
I have been working on a number of utilities that require conversion between GUID's and base64GUID's. I have read many of your blogs on this subject and find them very useful and informative.
I am not sure however if I have found an error in the Hakon Clausen code referenced above or whether its an error on my behalf (I tried downloading your version/implementation of the C# code from the buildingSMART technical website to see if I get the same error but there seems to be a problem with the zip file)
The problem I have found is that certain GUID's when converted to base64 and then back again don't yield the same GUID. I am working on some tools to assist in producing COBie UK datasets from Cadduct (Autodesk Fabrication) models. An example of the type of error I am having is:
the following GUID:
01cf62c8-e9bc-bf88-0000-000000000005
when converted to base64 with the above algorithm yields:
01psB8wRl0Y00000000005
When this is converted back to its standard form I get:
01cf62c8-e9bb-c088-0000-000000000005
I have a few otheer examples that do not work both ways, most of those I have tested however work fine.
Any help/insight greatly appreciated.
regards
Paul
Posted by: Paul Marsland | April 28, 2014 at 07:43
Paul, I tracked down the bug. Specifically there was a BitConverter.ToInt16 call in there which should have been BitConverter.ToUInt16 like the rest. I have updated it a bit and added you test case. The whole thing can be found here https://github.com/hakonhc/IfcGuid
Posted by: Håkon Clausen | July 02, 2014 at 05:18
Dear Paul and Håkon,
Thank you both very much for reporting and fixing this!
I added a note about the fix and the GitHub repository to the main blog post, to ensure it does not get missed.
Cheers, Jeremy.
Posted by: Jeremy Tammik | July 02, 2014 at 05:40