Coordinates of the IfcLocalPlacement/IfcCartesianPoint

do you know what is best practice on defining the coordinates of components in the IFC Structure, respectively the IfcLocalPlacement/IfcCartesianPoint?

Depending whether the component sits near the Project Zero Point the values appearing in the IfcCartesianPoint will be in a range of some tens of meters. When the model georeferenced acording to a local datum, the component sits in the BIM Authoring tool far away from the Project Zero Point resulting in coordinates rangin in thousends/millions.

Some software are able to handle such high number and some less.

What is your opinion about these HIGH numbers appearing in the IFC structure of a project?
I have embedded two screenshots representing two cases: the first with coordinates relative to project zero and the second one is georeferenced.

regards

I remember @Moult had some posts about this before

Hi @agron, the issue you are experiencing about using very high numbers as a way of georeferencing is because the geoferencing entity in IFC is missing. Indeed, any 3d format with large numbers will have parsing issues.

The solution, and proper way to georeference in IFC is to use a map conversion, along with a target CRS (coordinate reference system) entity. Therefore all of the local coordinates will be nice and small and manageable.

I have written about how georeferencing works (and gotten it checked by John Mitchell at buildingSMART, who invented the entity and is a domain expert) here:

https://thinkmoult.com/ifc-coordinate-reference-systems-and-revit.html

It is an unfortunate scenario that programs like Revit don’t understand how to properly do georeferencing and that leads to misunderstandings, such as people offsetting their entire model to absurd distances. (Note that offsetting is actually incorrect, as proper local to global CRS conversions have other transformations too, such as scale, also. Different sites on a large project will each have different transformations)

If you’d like to play with software that supports IFC georeferencing properly, you can use ArchiCAD, FreeCAD, or BlenderBIM. If you are stuck with Revit, I highly advise you reset your coordinates to the origin (I show how Revit calculates coordinates in my post) and enter in georeferencing data manually into the IFC file (it’s not hard), or if using IFC2x3, put it into a separate metadata file.

4 Likes

"It is an unfortunate scenario that programs like Revit don’t understand how to properly do georeferencing "

What?! But it is certified anyway.
Georeferencing is not part of any bim workflow, neither was it part of certification?!

O.M.G!

Sometimes I feel all of these issues are purposeful.

Instead of simplifying things, producing more and more complexities and issues and benefit from

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 :wink:

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?

1 Like

“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 IfcSite provides RefLatitude , RefLongitutde , and RefElevation attributes. 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 the IfcMapConversion and the data provided in IfcSite , the IfcMapConversion takes 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 different IfcSite elements to have a different IfcRepresentationContext , and therefore have a different MapConversion . 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?