[IFC-Tunnel] Georeferencing re-work

[SergejMuhic]

The document summarizing the proposal: [DOCUMENTATION] geo_ref.pdf

Due to some requirements a re-work of georeferencing is required.

1. Non projected coordinate transformations
2. Support for geographic coordinate systems
3. Local placement reference to a geometric representation context (not in scope of IFC Tunnel for now)

[Moult]

There are currently 4 logged unresolved issues here: https://github.com/buildingSMART/IFC4.3.x-development/issues?q=is%3Aissue+is%3Aopen+label%3Aallocated-gis

There are a few more unresolved issues from the forums, but I haven't gotten around to documenting them. In particular, the EPSG database connection is an important one for implementers. I will keep you posted as I add more.

[pjanck]

I've read through the proposal and the issues referenced above and the following sums my opinion on the topic:

1. Further explaining the requirements: https://www.researchgate.net/publication/350740139_Georeferencing
   • Option 2 is currently supported for projected coordinate reference systems (CRSs) as described in the proposal
   • Option 1 would be the case of I only want to specify a single point on Earth as the origin of my model
   • Option 3 would be the case of I only want to specify a single point in a CRS, but not use it's axes; as put by the proposal

the case where no coordinate operation is supposed to be performed on coordinates

2. I agree with the requirement to reference other types of CRS, like geographic CRS, especially useful in Option 3 above
3. Option 1 is not that semantically rich in my view, however useful in combination of contexts
4. I feel that the enum listed in the proposals for solution section of the proposal is a valid solution, however not that pretty. I'm more inclined towards defining more entities and have strong typing.
5. I greet the possibility to have multiple IfcGeometricRepresentaionContext in one IfcProject! Can we consider even having multiple Body representations, each in its own context? And, as put in the proposal, multiple placements, each in its own context? I'd count this as being in scope of IfcTunnel project.
6. I agree with the IfcTranslationOperation to cover Option 3 above (it takes the coordinates of the CRS, however not its axes). The Scale attributes makes little-to-no sense to me, since the operation explicitly ignores the axes. So what are we scaling?
7. I agree with the IfcWellKnownTextCRS as a separate entity as already proposed in one of my previous publications. I'd change the parent entity to IfcCoordinateReferenceSystem.
8. I agree with the IfcGeographicCRS to support Option 3 above. Please do include the Identifier where an EPSG code should be.
9. The combination of IfcGeographicCRS with IfcMapConversion must be explicitly forbidden (with a WHERE rule in the schema?).
10. I join the call for a dedicated expert panel.
11. I'd propose to also drop the Scale.. attributes of IfcMapConversion, since they do not serve their purposes and rather confuse the community. The scale is conveyed by the properties of the CRS as encoded by the EPSG code.

[LeeGregory12d]

Stefan, Your 11. Sorry but I don't think the scale is the one encoded by the EPSG code or WKT. It is not the scale factor of the projection but the combined scale factor which varies with height.

It is used to covert map distances (distance between two map coordinates) to ground distances (standard metres).

[pjanck]

It is not the scale factor of the projection but the combined scale factor which varies with height.

I totally agree with you. In my view, the EPSG code (e.g. https://epsg.io/5555) conveys all the information needed to calculate the combined scale factor, depending on the object's location within the area of applicability.

And we both know that this combined scale factor can only be approximated to a constant within a small area. Which makes the Scale attribute of IfcMapConversion useless for infrastructure objects.

[LeeGregory12d]

Stefan,

1. Small Area Yes the fact that a combined scale factor is only applicable in a small area is why having only one IfcMapConversion for the whole project is a huge problem for an infrastructure project. This was pointed out in the IFC Model Setup IDM paper with the railway example, and you and I have mentioned the same problem a number of times, but so far there has been no resolution. Sergej and Ifc Tunnel have been working on something like that but I haven’t seen an actual example to see how it is all going to work.

One possible solution that you and Andre proposed in a paper is that everything has to be in Map Coordinates. This does remove the problem but still leaves open the question of what people with “local engineering coordinates” have to do with their data to produce the Map Coordinates.

2. Leaving Out the Scales I don’t agree with leaving out the scale factors and the receiving software having to use EPSG codes etc to work it all out. The beauty of having the combined scale factor etc in there is that the receiving software doesn’t have to know anything about the projection itself to do the conversion from local engineering coordinates to Map Coordinates - everything that is needed is contained in IfcMapConversion.

Regards Lee

Dr Lee Gregory Managing Director 12D Solutions Pty Ltd

Creators of the 12d Model Civil and Surveying Software and 12d Synergy for Data Management and Project Collaboration. Ph: +61 (0)2 9970 7117 Email: @.**@.> Web: www.12d.comhttp://www.12d.com/aus/?utm_source=emailsig&utm_medium=email&utm_campaign=emaillink

From: Stefan Jaud @.> Sent: Thursday, 25 November 2021 6:20 PM To: bSI-InfraRoom/IFC-Specification @.> Cc: Lee John Gregory @.>; Comment @.> Subject: Re: [bSI-InfraRoom/IFC-Specification] [IFC-Tunnel] Georeferencing re-work (#83)

It is not the scale factor of the projection but the combined scale factor which varies with height.

I totally agree with you. In my view, the EPSG code (e.g. https://epsg.io/5555) conveys all the information needed to calculate the combined scale factor, depending on the object's location within the area of applicability.

And we both know that this combined scale factor can only be approximated to a constant within a small area. Which makes the Scale attribute of IfcMapConversion useless for infrastructure objects.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/bSI-InfraRoom/IFC-Specification/issues/83#issuecomment-978901318, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOZ2E5UISGC5D2JFOSHNKUDUNXPT3ANCNFSM47BNXAQA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Report this message as spamhttps://console.mailguard.com.au/ras/21QI57pIak/7vF2PaIgrOCVia0deVqOrm/2

[https://www.12dmodel.com/images/mail/TF21_Email_sig.png]https://12dtechforum.com/?utm_medium=email&utm_source=12dsolutions&utm_campaign=tf2021&utm_content=signature

[http://forums.12dmodel.com/downloads/images/12d_Logo.jpg]http://www.12d.com [http://forums.12dmodel.com/downloads/images/Youtube_12d.jpg] http://www.youtube.com/user/12dModelSoftware [http://forums.12dmodel.com/downloads/images/Twitter_12d.jpg] http://www.twitter.com/12dmodel/ [http://forums.12dmodel.com/downloads/images/Linkedin_12d.jpg] http://www.linkedin.com/groups?home=&gid=3174309 [http://forums.12dmodel.com/downloads/images/Facebook_12d.jpg] http://www.facebook.com/pages/12d-Model/132088923475032 [http://forums.12dmodel.com/downloads/images/Forum_12d.jpg] http://forums.12dmodel.com/

12d Webinarshttps://www.12d.com/community/Webinars.php

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

12d Solutions Pty Ltd is a company registered in Australia ACN 101 351 991.

[anborr]

The document summarizing the proposal: [DOCUMENTATION] geo_ref.pdf

Due to some requirements a re-work of georeferencing is required.

1. Non projected coordinate transformations

2. Support for geographic coordinate systems

3. Local placement reference to a geometric representation context (not in scope of IFC Tunnel for now)

Here are the relevant sections from the IFC-Tunnel Requirements Report (p23) that give the background for these requirements:

The proper usage of geodetic coordinate reference systems (CRS) plays an extraordinarily important role for the design and construction of tunnels due to their potentially very long expansions. Geodetic CRS apply a transformation to project the earth surface approximated by an ellipsoid onto a flat map (map projection ), see Figure 6 1. In the case of the Universal Transversal Mercator (UTM) projection, a cylindrical surface is used as projection surface. The projection and the height reduction to an ellipsoid introduces distortions in lengths (see Figure 6 2). These distortions depend on the coordinate reference system applied and the location on the earth surface .

BIM authoring systems for buildings are typically not able to handle geodetic CRS (large coordinates). For this reason, very often a mere translation of the coordinate system is applied by defining a local coordinate system on a local point of origin. Typically, the geodetic coordinates are provided for this point of origin. However, if the local coordinate system is created by a mere translation (shifting in x and/or y direction by subtracting a fixed value from x and y coordinates), it remains a projected coordinate system with length distortions as described above (see Figure 6 3). However, as now “small coordinates” are used, there is the severe risk that the tunnel model is erroneously interpreted as a distortion-free 1:1 model, potentially resulting in cost-intensive surveying errors on site .

Accordingly, for the proper use of the tunnel model represented by an IFC model, explicit information of the applied Coordinate Reference System is crucial. A strong requirement for using IFC in the context of tunnel projects is therefore the use of the entity IfcProjectedCRS (a subclass IfcCoordinateReferenceSystem) which has been introduced with version 4.0 of the IFC standard. Its attributes GeodeticDatum and VerticalDatum allow the specification of a code standardized by the European Petroleum Survey Group (EPSG), which unambiguously defines the CRS in use.

In addition, the IFC-Tunnel project team strongly recommends not to create a local coordinate system in the IFC model (by using IfcMapConversion), but to only use “large” coordinate values in the original CRS. Doing so will reduce the risk of misinterpreting distances and lengths in the models. If the use of a local coordinate system is unavoidable, the IFC model should be clearly marked by setting an “isDistorted” flag.

The application of the attribute Scale of IfcMapConversion is not recommended as it only allows the specification of a uniform scale factor in x, y and z direction (in its current version of IFC 4.3). Due to the nature of the applied geodetic projection, however, the scale factor is different in the three directions.

The bSI project “Model Setup IDM” recently proposed the introduction of the entity IfcMapConversionSiteExtended allowing to define three independent scale factors. The IFC-Tunnel project team supports this proposal. However, its documentation must unambiguously specify how exactly the scale factor is applied and whether it is supposed to result in an undistorted 1:1 model stored in the local coordinate system. It must also be noted that the scale factor varies with the geographic location, also along the tunnel. Accordingly, for long tunnels, the direct use of “large” coordinates as described above remains the preferred option.

For short tunnels, also the use of a 1:1 modeling approach with an undistorted local coordinate system is possible. However, again this must be clearly specified in the IFC file, e.g. by setting the “IsDistorted” flag to FALSE. It is important to have in mind that for any data imported from GIS and other sources with geodetic CRS (e.g. digital terrain model), a re-projection must be applied to de-distort it (Figure 6 4).

For very large tunneling projects or for tunnels that cross national borders, project-specific CRS are applied that apply non-standard projections to minimize distortions between the projected CRS and the reality. A good example is the Brenner Base Tunnel that crosses the Austrian-Italian border . This introduces the problem that for these project-specific CRS there are no EPSG codes defined. To nevertheless be able to unambiguously define the CRS in use, the IFC-Tunnel project team supports the proposal by Jaud et al. and the bSI project “Model Setup IDM” to make use of “Well-known text” (WKT) to specify the meta-data necessary to specify all parameters of a project-specific CRS .

[anborr]

It is not the scale factor of the projection but the combined scale factor which varies with height.

I totally agree with you. In my view, the EPSG code (e.g. https://epsg.io/5555) conveys all the information needed to calculate the combined scale factor, depending on the object's location within the area of applicability.

And we both know that this combined scale factor can only be approximated to a constant within a small area. Which makes the Scale attribute of IfcMapConversion useless for infrastructure objects.

I agree with @pjanck 's 11: We should remove the scale factors as they are implicitly defined by the chosen IfcProjectedCRS. In the current version, we have redundancy and thus risk of inconsistency. I also doubt that SW packages do fill IfcMapConversion correctly. @LeeGregory12d: For this reason I doubt, that "everything that is needed is contained in IfcMapConversion" in real-world IFC files.

See also https://github.com/bSI-InfraRoom/IFC-Specification/pull/330#issuecomment-1009362066

[Moult]

@anborr the scale is optional.

For small sites with vertical construction, the majority of disciplines will be using local engineering coordinates. Maybe only one or two out of the 10 disciplines are qualified to understand GIS. If the scale is removed, the majority of these disciplines, who lack the domain knowledge of GIS, will be extra likely to make mistakes. This represents a significant portion of the industry.

Edit: I would also add that your proposal of simply recommending people use "large" coordinate values in the original CRS will cause lots of problems with the vertical building industry who uses tools for CG visualisation, concept design, and web-platforms that are not designed for use with large numbers (e.g. BIM360's web viewer breaks with visual glitches on every single "fake-offset" geolocated IFC file). Also, these small site designs work and think in terms of small local coordinates as surface distances. Simply asking them to use large numbers will, as you say, create the problem that they think distances are not distorted. We must allow for both approaches: local engineering as well as map coordinates, and so for the former, scale should exist (whether it is a single scale or axis-dependent is not my area of expertise).

In short: I disagree with removing scale.

Another example is true north. Yes, in theory it is "redundant information", but it is valuable for an architect, and if omitted, no architect will have the GIS knowledge to calculate true north. Therefore, it should be able to be stored.

Or Qto data. Geometry means it can be calculated, but Qto data is not "redundant" - it is there precisely because it is difficult and context sensitive to calculate, and easily available as a reference.

I also doubt that SW packages do fill IfcMapConversion correctly.

The major packages have only recently started to implement IfcMapConversion (and ProjectedCRS too, where I often also see wrong data in there too). In these early stages, jumping to the conclusion that it isn't filled out correctly is wrong (half the IFCs I receive have wrong project names, wrong projected CRS, wrong psets, wrong types, etc, but they should not be removed!). It is also not so much a technical limitation, but a workflow one - the project needs to realise that a qualified professional (e.g. surveyor) is responsible for filling out these parameters.

[LeeGregory12d]

1. RE 11. I'd propose to also drop the Scale.. attributes of IfcMapConversion

I still disagree with this because not all the information is contained in the EPSG code.

The problem is heights. No one uses ellipsoid heights - orthometric heights (geoid or gravity heights) are always used as most people expect water to run downhill.

To do the calculations to produce a combined scale factor for data that only has orthometric heights, you also need N-values (an N-value at a point is the difference between the ellipsoid height and the orthometric height at that point).

So yes, the calculation is possible, but the receiving software must also have access to, or be provided with, N-values, and then be able to do the calculations.

Yes the scale factors are only applicable over a small distance but I thought that the only time IfcMapConversion scales would be anything but one is when a company only had their data in "local engineering coordinates" and needed to supply their original data and the Scales needed to convert it to the Map Coordinates required for the Infrastructure project.

The task is to make such companies aware that there is a difference between "local engineering coordinates" and Map Coordinates.

2. Re: And we both know that this combined scale factor can only be approximated to a constant within a small area. Which makes the Scale attribute of IfcMapConversion useless for infrastructure objects.

I totally agree that the Scale attributes Sx, Sy and Sz are only a constant over a small area. And I totally agree that any infrastructure should be in Map Coordinates.

But in an Infrastructure project, many of the components (and costs) are for buildings and structures that are done by companies who only ever work in small areas of the project (small in square metres and not small in cost) and have only ever used "local engineering coordinates".

And it was for this situation that I thought IFC Model Setup was written. That is, to point out to a company using "local engineering coordinates" that "local engineering coordinates" are only applicable in a small area (eg 1 kiloometre) and if they are working as part of an Infrastructure project, then it is up to their company to work out the required local Helmert Transformation (or Affine Transformation if Sx can be different to Sy) to map to Map Coordinates.

But once they have that, in their IFC file that only contains "local engineering coordinates", all they have to do is add the correct IfcProjectdCRS record and the IfcMapConversion with the appropriate Sx, Sy, Sz (and IfcMapConversion.Eastings, IfcMapConversion.Northings, IfcMapConversion.XaxisAbscissa and IfcMapConversion.XaxisOrdinate for any translation and rotation) to map their "local engineering coordinate" data in the file to the correct Eastings and Northings required for the Infrastructure project.

3. IsDistorted Flag

Yes a "IsDistorted" flag is needed to differentiate the case when the data in the IFC file is already in Map Units ( "IsDistored" is true) but needs to be translated and rotated by IfcMapConversion to get the actual Map Coordinates, and the case when the local Scale factors are one but the data is in "local engineering coordinates" ("IsDistorted" is false).

In the second case, the "IsDistored" flag would warn the receiver that the data is in "local engineering coordinates" and should not be used for extrapolation outside a small area.

4. Re: Edit: I would also add that your proposal of simply recommending people use "large" coordinate values in the original CRS will cause lots of problems with the vertical building industry who uses tools for CG visualisation, concept design, and web-platforms that are not designed for use with large numbers (e.g. BIM360's web viewer breaks with visual glitches on every single "fake-offset" geolocated IFC file)

Yes some software can't handle large coordinates but it should always be pointed out to everyone that is a software problem and not a limitation of Industry or IFC.

We should not be nobbling IFC because at some point in time, certain software can't handle large coordinates.

[anborr]

I still disagree with this because not all the information is contained in the EPSG code. The problem is heights.

IfcProjectedCRS has the Attribute VerticalDatum (inherited from IfcCoordinateReferenceSystem) . In can be used "to provide a String by which the vertical datum is identified. The vertical datum is associated with the height axis of the coordinate reference system and indicates the reference plane and fundamental point defining the origin of a height system. It needs to be provided, if the Name identifier does not unambiguously define the vertical datum as well and if the coordinate reference system is a 3D reference system." An example could be "EVRS2007" for the European Vertical Reference System.

You can also use EPSG codes for defining a Vertical datum, for example EPSG:5783.

At the same time, there are many EPSG codes that combine GeodeticDatum with VerticalDatum.

So indeed, if used properly, all information required to compute the projection/mapping (and thus the scaling) would be provided by IfcProjectedCRS.

[anborr]

This library should be able to compute the scale from the EPSG code: Proj

[anborr]

@Moult

I would also add that your proposal of simply recommending people use "large" coordinate values in the original CRS will cause lots of problems with the vertical building industry who uses tools for CG visualisation, concept design, and web-platforms that are not designed for use with large numbers (e.g. BIM360's web viewer breaks with visual glitches on every single "fake-offset" geolocated IFC file). Also, these small site designs work and think in terms of small local coordinates as surface distances. Simply asking them to use large numbers will, as you say, create the problem that they think distances are not distorted. We must allow for both approaches: local engineering as well as map coordinates, and so for the former, scale should exist (whether it is a single scale or axis-dependent is not my area of expertise).

The proposal comes from the IFC-Tunnel requirements report and was made specifically for large tunnels (>1km). I agree with @LeeGregory12d that in extended infrastructure projects "large coordinates" should be used by default. There is a good reason that any GML-based format (CityGML, InfraGML, OKSTRA) use exclusively "large coordinates".

[TLiebich]

unfortuntely typical BIM authoring tools (and visualizing tools) used in vertical building domain regularly fails when "large" coordinates are used - so if such a recommendation is added, then I would positon it in the MVD for infrastructure domain (e.g. IFC4.3 ABRV). For building domain it has to be mandatory that "large" coordinates are trunkated.

[Moult]

Infrastructure using map coordinates sounds fine to me. I'm just saying that what's best for infrastructure isn't necessarily best for vertical construction, and so both options need to be accommodated.

Large coordinates is one issue, but the bigger issue is that in vertical construction the majority of players work with surface distances, not map distances. From what I understand truncating the numbers is not sufficient, and in fact may be even harmful as it might give the illusion that surface and map distances are equivalent. For this reason, the approximated combined scale factor needs to be stored, along with the rest of the helmert transformation.

For infra projects, they are free to leave this helmert transformation as null and work directly with map coordinates. The attributes are null, but should remain in the specification so that vertical construction can still use it.

[SergejMuhic]

If you look at the proposal #330, you will notice two different types of coordinate operations are proposed. Next to IfcMapConversion which implies that all coordinates must also be transformed an additional operation is proposed (naming as always debatable) IfcTranslationOperation that can be used for "truncating" coordinates or placing the origin of the data set in the context of a geodetic (currently still named geographic) coordinate reference system.

Thereby all cases should be covered. Of course it is debatable whether it makes sense to have only an IfcTranslationOperation the applies to both maps and geodetic CRS's or have two strong typed operations in its place, one for maps the other for geodetic coordinates. It would be great to hear some opinions on the actual data modelling part also. Please comment on the pull request #330 with any suggestions.

Otherwise, also looking forward to seeing everyone in the expert panel.

[anborr]

@Moult

I'm just saying that what's best for infrastructure isn't necessarily best for vertical construction, and so both options need to be accommodated.

That's absolutely clear and was never questioned by anyone. We must support both.

Large coordinates is one issue, but the bigger issue is that in vertical construction the majority of players work with surface distances, not map distances. From what I understand truncating the numbers is not sufficient, and in fact may be even harmful as it might give the illusion that surface and map distances are equivalent.

Correct. We are discussing this issue for ~5 years now. Hopefully we find a good solution now. I think we agree on most of the fundamental aspects. The only disagreement we have is wheter an explicit scale factor creates more harm than good. I propose to replace it by a BOOLEAN IsDistorted to raise awareness regarding the distortion of distances in projected coordinate systems and limit accidental misuse. I really fear that implementers set scale to 1.0 when they are using an undistorted engineering coordinate system (as most systems for vertical construction do). But that would indeed be incorrect, as it is characteristic of the projected coordinate reference system at this location and at most locations the scale differs from 1.0.