Sometimes I feel all of these issues are purposeful.
Instead of simplifying things, producing more and more complexities and issues and benefit from
Coordinates of the IfcLocalPlacement/IfcCartesianPoint
1 Like
Thanx @moult as usual for your detailed explanation. I was so far of another article you wrote about georeferencing (when you were exploring this subject). This article about the coordinates is very appropriate and I think many involved in the industry should not just read it, but study it correctly.
Though I felt a bit offended when you mentioned that I am not using IFCs correctly. To be honest, as an Archicad Power User our principle is to deliver IFCs as best fitted in your description. I started this subject more from outside sources, where different consultant companies try to imply this “wrong” revit workflow. For this reason, I just wanted to know what experts at our Forum think about this matter.
You mention at the end of the article the case of editing the IFC to modify the IfcLocalPlacement. Do you think that should be the workflow? Shouldn’t it be more correct if all involved parties work with same parameters, avoiding any improper manipulation of data?
Hi @agron, I have retracted my statement, and I am happy to see we are trying to achieve better results with IFC. ArchiCAD I believe has implemented georeferencing, and I’m sure they can help guide exactly what settings to use.
The editing of the IFC file is merely a workaround which I have had to apply, but ideally all involved parties should work with the same parameters as you’ve said. The ability for IFC files to reference other files would help greatly to resolve this, as there is no duplication of parameters, but instead the ability to simply link / import in another IFC file.
@Hans_Lammerts please note that I believe the Revit certification is for 2X3, not IFC4. The ability to georeference was an addition in IFC4, therefore I find no fault in the certification process.
If a company has IFC2x3 certificate and start to implement some features from upper version for instance IFC4, I think should control it with bSI and ensure that it works well
As I see all companies, especially Archicad, always implement some new features from upper IFC version
And I haven’t checked certification page yet, but it seems that just Archicad has the new certificate for IFC4
@Moult No offense taken 
One thing though caught my attention at your description. On the IfcProject level the coordinates for northings and eastings are defined by a local system as you describe MGA56 that is defined in meters. Lower in the structure coming to IfcSite, the values for Longitude and Latitude are defined in degree, minutes and seconds as I suppose in GMS. Since the above two systems are different in the way they represent the globe (Elevation) and the position (X,Y), there is a possibility that it could come to discrepancies because of the transformation. Geographical coordinates is not my daily profession, but from experience the second decimal can mean already plus/minus 3 meters offset.
Therefore, to set a clear path of defining correct geographical coordinates for a project that can have one or more sites, the whole IFC Structure in this topic should be represented by the same unit. Same as we have METERS for components, hence either LocalSystem or GMS for defining where the structure is located.
Opinion?
“Since the above two systems are different in the way they represent the globe”
That is totally true and highly strange. Lat /Lon and XY(z) can’t communicate and work together in a "notepad edit’ fashion. In fact, calculating this transformation is highly complex. As the earth is not flat and neither is it (perfecly) curved or round (lat/lon). Our goverements therefore use XYZ defined in local coordinat systems and -names
Any moderate gis user (myself) knowns the basics behind the different translation of local coordinat systems. I find it shocking so many designers of building know so little about the advantages of good georefencing models. And i think that the choice of lat/lon is highly unappropriate measurement for both CAD ánd BIM formats. I for sure don’t rely the input given in this parameter.
My$ bold statements?
@agron Although 2 units can be written in the IFC file, only the CRS defined system is considered authoritative (@Hans_Lammerts, this also answers your question). See this statement in my blog post:
In addition to ordinary coordinates, the
IfcSiteprovidesRefLatitude,RefLongitutde, andRefElevationattributes. As the prefix “Ref” suggests, this is the latitude and longitutde for the reference point. It was introduced as a way for vendors to easily migrate between IFC2X3 and IFC4. This is because the concept of map conversions did not exist in IFC2X3. In the case of IFC4, it is in fact a duplication of data. If there is a discrepancy between theIfcMapConversionand the data provided inIfcSite, theIfcMapConversiontakes priority.
As you can see, the lat/longs were only there for a 2X3 fallback, and should not be used. If they both exist, the lat/longs should be ignored. In addition:
After all of this information is recorded, it’s interesting to note that the IfcGeometricRepresentationContext additionally has a TrueNorth attribute. Assuming the IfcMapConversion is already provided, there is actually no need for a TrueNorth attribute, and so if it is provided, it is merely duplicate data and there for convenience. IFC readers should not parse it and should not apply the same rotation twice. The IfcMapConversion takes priority over the TrueNorth attribute.
Also, you state that “On the IfcProject level the coor…” - this statement is not that accurate. It is defined at the IfcGeometricRepresentationContext level. Therefore, this statement in my article should be emphasized:
I would like to emphasize that the inheritance of coordinate transformation is not done due to spatial containment, but instead due to the selection of
IfcRepresentationContext. This allows differentIfcSiteelements to have a differentIfcRepresentationContext, and therefore have a differentMapConversion. This is useful if you are working on a small town or any geographically large projects, as different sites will likely require different Helmert transformations.
In conclusion, IFC only defines one authoritative unit and one authoritative location for georeferencing, through the map conversion and target CRS (exact unit, e.g. metres, feet, etc, depends on the CRS definition). Here is an example output implementation by Blender BIM:
#27=IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model',3,1.E-05,#9,$);
#32=IFCSIUNIT(*,.LENGTHUNIT.,$,.METRE.);
#33=IFCPROJECTEDCRS('EPSG:28356','Sydney','GDA94','AHD','MGA','56',#32);
#34=IFCMAPCONVERSION(#27,#33,334902.775,6252274.139,4.,0.,1.,0.98);
Hope it helps and clarifies things!
2 Likes
I think we can find the best answer in CityGML schema or maybe in the recent Infra schema
Thanks to @Moult - his answer is fully correct and in line with the intention of the IFC4 schema definitions. The mapping of a local engineering coordinate system to the underlying map coordinate system (an northing/easting/elevation based map coordinate system) is done using IfcMapConversion associated to the geometric context of the project.
Earlier, in IFC2x3 and before, such functionality did not exists. The information about lat / lon / elevation at IfcSite was not meant for exact georeferencing onto a map, but as a location information (at the beginning, before 2x, it was only provided as grad and minutes for sun shading studies or similar). So now, in IFC4, IfcMapConversion shall be used instead.
1 Like
TOWARDS AN INTEGRATION OF GIS AND BIM DATA: WHAT ARE THE GEOMETRIC
AND TOPOLOGICAL ISSUES? - Ken Arroyo Ohori, Filip Biljecki, Abdoulaye Diakit´e, Thomas Krijnen @aothms, Hugo Ledoux, Jantien Stoter
1 Like
I didn’t read the whole acadamic blah, but my eyes caught this sentence
“IFC there are many different ways to model an object, and that supporting all of them is a problem in practice; and thus this hinders standardisation.”
Two things
1 IFC models nothing
2 Yes, converting IFC into GIS will be even more challenging and complicated. Good luck!One of the reasons why DWG is still alive and kicking is that DWG is the best way to feed GIS databases and has a SOLID coordinat system which is relyable. ‘BIM’ Whatever you think bim is for infra or gis. it clearly needs a more clear and solid relation with CAD! Level 1 bim versus L2 bim, all that sort of ##$$ (talk). What is gis? L1
Some companies want some their traditional software survive. Otherwise, CAD era has finished.
Doesn’t it odd? From 2013 (and even before) they know these issues related to coordination
Cad is only dead for those you embrace bimism
1 Like
Let me pour some more oil on the fire. And by that, I mean ‘academic blah’. A lot has been said already, and thank you, @Moult, for your great explanations.
I’ve produced a graphic explaining the relationships between IfcMapConversion etc. for the ICCCBE 2018 conference (PDF), Figure 7 - perhaps this can help further understand the entities and their roles within IFC4.
My other paper, published at ICCCE 2019 conference, goes in depth on the current insufficiencies of the IFC4 schema for complex infrastructure projects (PDF).
On the precedence of what information takes priority, Christian Clemen published a proposal on ‘Level of Georeferencing’ with an open-source checker (PDF). It defines multiple levels, with IfcMapConversion being the highest level.
As both my papers note, the current schema covers the majority - but not all - of the cases, and needs to be expanded appropriately. I am involved with the developments in the IFC for infrastructure and have already put these ideas forward. If you would like to share your own, don’t hesitate to contact me.
EDIT 09.10.2019: Corrected the years of the conferences (were one off).
2 Likes
Thanks @stefan.markic for these invaluable papers,
I have to read them, however, are you working to drop Cartesian Coordinate System (CS) in IFC? Or just have focused on Project, Site, Building?
I’m not fully following your train of thought here. Can you be more specific, where did you get that from?
This is not my expertise, but many times I heard some experts were saying:
“As long as something is using Cartesian coordinates it will never be a reality capture model of the built environment”
And those experts were correct.
As long as you see every Z-plane of your Cartesian coordinate system as being an equipotential surface of Earth, you are (knowingly) making a mistake / introducing a discrepancy. And this discrepancy is encoded by Coordinate Reference Systems (CRS), see ISO 19111.
1 Like
Great papers, and I completely agree with the proposal of a WKT addition. I personally wonder if you can actually simply only use the WKT format, with an EPSG code that is either present (if one exists) or not present (if it is a custom CRS) - after all, I think the WKT format is available for all current EPSG CRSes. Or perhaps I am mistaken. That would lead to cleaner data and less ambiguity about how to fill out the TargetCRS attributes.
@stefan.markic Do you mind if I link to your papers (with due credit) in my article?
@Moult Yes, of course you can cite my papers! Science is (should be) free and accessible to everyone interested!
Regarding WKT: Every EPSG code is basically an identifier for a specific WKT string - see epsg.io export options - the first representation is always the WKT. If using only WKT will get implemented throughout the industry - that is out of my/our hands. You need to consider that other formats (like GML-family) use EPSG codes extensively and are therefore becoming kind-of industry best-practice. But that is a discussion to be had over a couple of beers in my opinion.