(The following is occuring with Revit 2016 using v16.5 of the IFC Exporter)
I have a situation where an Engineer for reasons i wont go into here has built their Revit model literally 100m above its true location relative to Revits internal origin. So if I were to link this model in to another one which had been modelled at the startup location, using Origin-to-Origin, this link would be 100m above where it should be.
The model is also out of alignment with the others in XY (i know this is not an issue, just FYI for futher along my post)
Now this is all fixable within Revit to Revit exhange using Shared Coords, however we also need to exhange IFCs ..
Named Locations have been created for both Project Coordinates (local) and MGA Coordinates (geolocated), and in each of these the Project Base Point (in all files) has been set to the same position (a Grid intersection) and given either local (0,0,0) or geolocated (big number, big number, 0) coordinates. Exporting to IFC at either real world or project local coordinates is simply a matter of activating the relevant Named Location.
This works for all models in XY, however the Engineers model is floating at Z+100m up in the air, despite the fact that the Project Base Point is situated in the same location in their model as in all the other models.
I had previously understood that the Survey Point was actually used for the origin when exporting IFC, and some older discussions seem to support this, but in my experimenting recently it seems to have no effect - the PBP is used for the IFC XY origin.
I have tried adjusting the Elevation of the PBP up and down by 100m to compensate, but this had no effect on the vertical position of the exports. I linked all 3 versions into both Solibri and Revit (IFC links) and in both applications all 3 models were in the same location.
So it appears that although the PBP is used to determine the XY origin of the IFC file, the Z origin is fixed at the internal origin?
Is this correct? bug or intentional?
does anyone have any other workarounds for this issue?
So far I have tried linking this into another file, repositioning and exporting to IFC with links exported, but this has the same issue (why not use the hosts coordinates??), and I have also tried Binding the link which does work .. except it is a huge model which takes ages so the chances of the engineer doing this (Binding link then exporting) every 1-2 weeks is about ZERO
Last edit: Owen Sharp 2017-01-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Owen,
That's strange, I seem to be able to do it, without moving any base point: This is what I did (ini 2016):
Created a project with walls at 100m, exported to IFC. verified that yes the walls are at 100m in the file.
New project in 2016. Link in the IFC file from the last step. Verified that the walls were at 100m still.
Move the link down 100m.
Export to IFC using the option to export links as separate IFC files.
Check the IFC file in FZK or Solibri - the walls are right at the base level as they were in Revit.
Does that workflow work for you? or are you seeing something different?
Andy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We're having the same behaviour: in 2017 exporter workflow exported ifcsite parameter has coordinates of internal startup location, but based on moved survey point, and it doesn't matter if we name the site or not. Also the elevation is taken from startup location, which is wrong, and it is possible to ruin ir by moving unclipped project basepoint.
This usually happens whem model is initiated without proper understanding, just somwhere, but later author tries to setup all correctly and unclips PBP to move it to, say, grid intersection.
One thing off topic - could you, please, change the window name back to (Alternate UI), just to know if the plugin installed correctly?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, after 8 hours of testing it appears that if ICF addin is installed (not sure if the logics behind is the same in original Revit bundle), the behavior is the following:
1. If you're using only revit files, there will be no problems - you're just using shared coordinates and thats all (or origin-origin (startup location), or center-center (by model bounding box).
But in most cases it is impossible to use same Revit versions, and IFC is the only way out:
1. During export to ifc what matters is ORIGIN (startup location, Revit internal zero). Usually it moves with PBP, but if you unclip it - you will have issues with placement, because now you will not be able to see where is your Origin point.
2. When you import IFC back in revit, you can't acquire coordinates. When IFC is inserted, Revit merges Origin in IFC with Revit internal origin, despite that IFC Origin is also having coordinates inside. In other words - only relative point position is taken into account.
3. Mentioned coordinates in IFC Origin are used to position different models in IFC viewers, and these coordinates are defined not by PBP in revit, but by the relative placement of SURVEY POINT (which represents zero) and revit model origin (startup location). Same is for elevation, but only if you manually choose to record elevation in options.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In accordance with http://thebuildingcoder.typepad.com/blog/2012/11/survey-and-project-base-point.html it is possible that used doc.ActiveProjectLocation api call always responds with coordinates of internal origin, where the defined coordinates and angle are stored when you change survey point settings or specify coordinates at point.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
(The following is occuring with Revit 2016 using v16.5 of the IFC Exporter)
I have a situation where an Engineer for reasons i wont go into here has built their Revit model literally 100m above its true location relative to Revits internal origin. So if I were to link this model in to another one which had been modelled at the startup location, using Origin-to-Origin, this link would be 100m above where it should be.
The model is also out of alignment with the others in XY (i know this is not an issue, just FYI for futher along my post)
Now this is all fixable within Revit to Revit exhange using Shared Coords, however we also need to exhange IFCs ..
Named Locations have been created for both Project Coordinates (local) and MGA Coordinates (geolocated), and in each of these the Project Base Point (in all files) has been set to the same position (a Grid intersection) and given either local (0,0,0) or geolocated (big number, big number, 0) coordinates. Exporting to IFC at either real world or project local coordinates is simply a matter of activating the relevant Named Location.
This works for all models in XY, however the Engineers model is floating at Z+100m up in the air, despite the fact that the Project Base Point is situated in the same location in their model as in all the other models.
I had previously understood that the Survey Point was actually used for the origin when exporting IFC, and some older discussions seem to support this, but in my experimenting recently it seems to have no effect - the PBP is used for the IFC XY origin.
I have tried adjusting the Elevation of the PBP up and down by 100m to compensate, but this had no effect on the vertical position of the exports. I linked all 3 versions into both Solibri and Revit (IFC links) and in both applications all 3 models were in the same location.
So it appears that although the PBP is used to determine the XY origin of the IFC file, the Z origin is fixed at the internal origin?
Is this correct? bug or intentional?
does anyone have any other workarounds for this issue?
So far I have tried linking this into another file, repositioning and exporting to IFC with links exported, but this has the same issue (why not use the hosts coordinates??), and I have also tried Binding the link which does work .. except it is a huge model which takes ages so the chances of the engineer doing this (Binding link then exporting) every 1-2 weeks is about ZERO
Last edit: Owen Sharp 2017-01-18
Hi Owen,
That's strange, I seem to be able to do it, without moving any base point: This is what I did (ini 2016):
Created a project with walls at 100m, exported to IFC. verified that yes the walls are at 100m in the file.
New project in 2016. Link in the IFC file from the last step. Verified that the walls were at 100m still.
Move the link down 100m.
Export to IFC using the option to export links as separate IFC files.
Check the IFC file in FZK or Solibri - the walls are right at the base level as they were in Revit.
Does that workflow work for you? or are you seeing something different?
Andy
We're having the same behaviour: in 2017 exporter workflow exported ifcsite parameter has coordinates of internal startup location, but based on moved survey point, and it doesn't matter if we name the site or not. Also the elevation is taken from startup location, which is wrong, and it is possible to ruin ir by moving unclipped project basepoint.
This usually happens whem model is initiated without proper understanding, just somwhere, but later author tries to setup all correctly and unclips PBP to move it to, say, grid intersection.
One thing off topic - could you, please, change the window name back to (Alternate UI), just to know if the plugin installed correctly?
Ok, after 8 hours of testing it appears that if ICF addin is installed (not sure if the logics behind is the same in original Revit bundle), the behavior is the following:
1. If you're using only revit files, there will be no problems - you're just using shared coordinates and thats all (or origin-origin (startup location), or center-center (by model bounding box).
But in most cases it is impossible to use same Revit versions, and IFC is the only way out:
1. During export to ifc what matters is ORIGIN (startup location, Revit internal zero). Usually it moves with PBP, but if you unclip it - you will have issues with placement, because now you will not be able to see where is your Origin point.
2. When you import IFC back in revit, you can't acquire coordinates. When IFC is inserted, Revit merges Origin in IFC with Revit internal origin, despite that IFC Origin is also having coordinates inside. In other words - only relative point position is taken into account.
3. Mentioned coordinates in IFC Origin are used to position different models in IFC viewers, and these coordinates are defined not by PBP in revit, but by the relative placement of SURVEY POINT (which represents zero) and revit model origin (startup location). Same is for elevation, but only if you manually choose to record elevation in options.
In accordance with http://thebuildingcoder.typepad.com/blog/2012/11/survey-and-project-base-point.html it is possible that used doc.ActiveProjectLocation api call always responds with coordinates of internal origin, where the defined coordinates and angle are stored when you change survey point settings or specify coordinates at point.