One of the fundamental concepts of BIM is getting coordinates correct. I’ve attempted to break down the topic and explain what I interpret from the current IFC 4 specification, as well as how this currently works in Revit.
I would appreciate if others could review this and add comment - I may have misinterpreted something in the specification, and it would be really useful to the community to have a better understanding of CRSes and coordinate concepts in general.
There is currently an official buildingSMART project being led by John Mitchell (@john.mitchell) at the Australasian Chapter called the “Project Setup IDM/MVD”. It’s goal is to standardize the method for exchanging initial project data, such as cadastral, coordinate, and naming conventions and distributing them to all project design stakeholders.
You may want to contact John and look into what has already been discussed and is being proposed.
Thanks for the heads up @jwouellette. I have seen the Australasian chapter’s online resources related to that project, and I link to it in the article and credit them for the explanation of things like the IfcMapConversion attributes.
However, it would be absolutely great to get folks like @john.mitchell and @jonm to review the document to make sure there aren’t misinterpretations / or out of date advice from their project! It’s a bit of a finicky topic and although bsA’s work helps clear up a lot of the ambiguity for me, perhaps I have still made mistakes, which is why I am posting it here
Happy to let the community here know that the article has been updated after a great conversation with @john.mitchell offline.
In addition, there is now experimental support for coordinate reference systems in FreeCAD! I’ve attached some screenshots below - still needs more polish, but the basics are there! I’d encourage everybody who wants to push more native & open-source IFC authoring development to check out FreeCAD and request features
An interesting topic, that I have also been experimenting in couple of running projects.
In Archicad you also have a point called the project origin. This point can have also geographical coordinates (GSM), that are translated into Longitude, Latitude and Elevation of the LocalPlacement in the IfcSite . Even though in my authoring tool I was defining the TrueNorth, for some reason I was not able to find the same value in the IfcGeometricRepresentationContext.TrueNorth.
Nonetheless there is one case that I was not finding correct with the geographical representation of the model in IFC. The ProjectOrigin is a point in space, which in our case represents also the IfcBuilding.ElevationOfRefHeight. The level of where the building sits and where the ProjectOrigin on the actual site is, are two different values, which most of the cases are not necessarily the same. So, our ProjectOrigin was represented by a world coordinate system (Gauß-Krüger System). The elevation had also height datum information, but is the height of ±0,00 of the ground floor. In this case the IfcSite should be referenced to a single Point located on the actual site which differs from the IfcBuilding.ElevationOfRefHeight !
Therefore, working with absolute coordinates is important since we are dealing with point clouds and even infrastructure projects which need the same values.
I think coordination is one of the complex topics which makes a lot of misunderstandings in many cases and hope someday buildingSMART and software vendors find a clear way
I think in some cases Autodesk is ahead of IFC and in some cases behind
But they have started cooperation with Esri (BIM+GIS) and I think soon they will solve coordination issues not only related to project and site, but also related to all objects inside the project
At the moment Revit has Survey Point, Project Base and Internal Origin
However, when it comes to project, site and buildings Revit follows a complex idea which is not efficient
So I think FreeCAD tries to solve this issue and shows a hierarchical tree which will help a lot
@agron good to see you are also experimenting with real GIS coordinates! The fact that you cannot find a true north value is not necessarily a bad thing. As mentioned in the article, the map conversion definition takes priority over the true north value. I have heard that ArchiCAD has does well in implementing CRSes.
As for IfcSite, I believe in a future version of IFC (this is coming from @john.mitchell ) CRS data will be defined at the IfcSite element, not IfcProject. This will help resolve some confusions, and allow infrastructure projects to design for large sites.
Out of curiosity, I wonder if ArchiCAD supports multiple sites and sub sites? This is something I’m looking to build for FreeCAD.
@ReD_CoDE, as outlined in the article, Autodesk currently doesn’t support CRS definitions. I hope their partnership with Esri helps them implement this. I’ll check again in Revit 2021. They also don’t seem to support the concept of a building or a site. Perhaps this will also be resolved in the future.
From what I have seen, coordinates is largely a solved issue in the IFC spec (apart from migrating from project to site definitions - when is this going to happen @jwouellette ?) So a huge thanks to the bS team! So it is now up to vendors to Make It Happen
CRS data will be defined at the IfcSite element, not IfcProject
That is promising news since in our exchange moments, we found it not quite proper that the Project has a coordinate system. The IfcSite is more appropriate.
Out of curiosity, I wonder if ArchiCAD supports multiple sites and sub sites
According to this VIDEO, Archicad can merge multiple IFCs into a single IFC Tree where IfcProject and IfcSite are the same, whereas differentiates at IfcBuilding. This is allowed (I assume) since their GUIDS are identical. To my knowlegde identical GUIDs result in duplicate elements resulting in an error which in the IFC Structure is not allowed ex. IfcWall, IfcDoor, etc. Are you aware of any exceptions for IfcProject and IfcSite in this case?
The video is cool. The only weird thing is the site being treated as a building, which ideally it should simply belong as part of the site, or be called an IfcFacility, or whatever it is being refined to in future specs. This is definitely something I would like to (and will!) build in FreeCAD.
I was recently made aware that sharing IDs is actually encouraged by buildingSmart Australia (as heard from @john.mitchell ) and is not a mistake. You know how IFC has no way in its spec to reference elements from other IFC files? Well, apparently two IFC files sharing the same solution is the poor mans solution to this and it is endorsed by buildingSmart.
Here’s an example I was told: one file may define an IfcProject element prepared by the client (and the OwnerHistory nominates that the client is responsible). A land surveyor then writes his own IFC file that copies the IfcProject element’s GUID from the client, but keeps all other fields blank. Then, the land surveyor defines via IfcRelAggs some IfcSites, Sub-sites, etc with CRS info, along with some topography geometry, let’s say. The OwnerHistory of the sites and sub-sites nominate the Surveyor as the owner. Now, the architect comes into the game, creating his own IFC file. Inside the Architect’s IFC, he copies the surveyor’s site element’s GUIDs, leaving all other fields blank. He then adds an IfcBuilding, along with some IfcBuildingStoreys. Since the architect in this case is responsible for setting buildings and building storeys, he uses the OwnerHistory to make himself responsible. He hands this IFC out to all the other consultants to inherit the GUIDs of the IfcBuilding and the IfcBuildingStoreys so that they can build their own IFC files with their own geometry.
Then, a program is capable of taking all these IFC files from different people, and based on the OwnerHistory decides which IFC file is considered to be the source of truth. It then merges the data together.
Given this example, although the non-explicit reference kinda irks me, I have no issues with creating “partial” IFC files which inherit via having the same GUID. It looks like ArchiCAD is the first vendor I’ve seen that actually supports this workflow. It’ll be awesome if it were extended to any element. Imagine if you could define IfcSpace, or IfcMaterial, and other consultants can start adding useful metadata to the same shared element.
I personally am looking to implement the same workflow in FreeCAD.
Indeed ID is a good idea which supports ISO BIM (ISO 19650) too
But the main issue as you try to explain too (I think) is that: When we marge different IFC files, the authoring software just refers to “ONE” OwnerHistory but in reality, especially after ISO BIM release we should clarify responsibilities and owners clearly for the future porpuses like legal aspects
So, in this case, a project should have a lot of IfcOwnerHistory entities which clarifies who is responsible for which and who is the owner of which?
I have interpreted the site in the video as something arriving from a landscape architect. But you are right that most people define the land as an IfcSite, maybe because of the same naming?! How and where this “model” should be defined, is a subject for the Landscape extension in IFC.
Thanks for the example and exaplanation about the exchange workflow. It seems plausible even though with a lot of role definition of who is responsible for what. In my opinion, it is not a big deal as long the information has been defined properly, in order to be correctly placed in the IFC structure. And I believe this works, from my point of view, as an Archicad user.
The reason why I believe it works is that I have done another test about this flow of information with IfcSpace. In this example, I defined in rchciad some P_Sets in IfcSpace, exported the IFC File and let the building physicist add additional values (the ones that were free in Pset_SpaceCommon). When importing the second IFC file back, I could choose in the programm which values should be imported (new vs. all). In this way I was able to import information and fill in the blanks in my authoring tool.
The tricky part about this workflow is: ALL must work very clean and know which information they are exporting/importing. Otherwise you could create a mess.
Therefore your example with the OwnerHistory seems quite plausible in implementation, and since the IFC Structure tolarates “double GUIDs”. On the other hand I would recommend that this “double GUID” case be limited only for certain parameters, such as IfcProject, IfcSite, or other, since I would not like it in Element level.
Allright - there is a lot of good quality content already posted here. Allow me to add some additional material:
First, notice the nuance here xkcd: Coordinate Precision at what step the term datum comes into play. If you want to be this precise, you need to include such metadata (e.g. in IfcProjectedCRS).
Second, Longitude / Latitude are not Cartesian coordinates, but rather polar coordinates and thus cannot simply be made equal to any Cartesian coordinates of any BIM model (at least I do not know of any BIM model in polar coordinates).
… that are translated into Longitude, Latitude and Elevation of the LocalPlacement in the IfcSite .
Coming from here: IFC4 Documentation : IfcSite has attributesRefLatitude, RefLongitude, and RefElevation; the former two are a IfcCompoundPlaneAngleMeasure on the WGS84 ellipsoid (form of a squished sphere) and thus polar coordinates. They are not part of LocalPlacement in the IfcSite. Same holds for the latter - elevation.
Continuing, the IfcGeometricRepresentationContext::TrueNorth is an IfcDirection (a vector in X-Y plane in this case) and not an angle to the North as in some authoring tools. So you may not find the exact same value. Additionally, one should use the new entity IfcMapConversion.
… CRS data will be defined at the IfcSite element, not IfcProject …
This is an idea that needs to confirmed through the standardization process. Why stop at IfcSite though? Why not have a possibility of different CRS for each geometry and placement (similar to GML)?
ALL must work very clean and know which information they are exporting/importing. Otherwise you could create a mess.
You then drift off to GUIDs and sharing the same GUID among several files. I think this is not really on topic (looking at the title), so in short: that is exactly how I understand IfcGUID-s and IfcOwnerHistory-ies in the first place. And I agree - we have to work clean - but that’s the point of any business, right?
At last, have a look at this great paper proposing different Level of Georeferencing: https://jgcc.geoprevi.ro/docs/2019/10/jgcc_2019_no10_3.pdf Perhaps this will clear out some confusions about different possibilities of georeferencing in IFC.
