Proposal to clarify documentation for tricky IfcProjectedCRS.Name attribute situations

[Moult]

As shown here when presented with a complex combination of EPSG codes (which may or may not be valid, not my area of expertise!), there is an interesting fact mentioned:

... for the usage of CRS systems in IFC the definition is based on the GML standard ...

Can this be communicated in the documentation to prevent further questions like stefan's from arising? Given that it is a mandatory field, I think it is good to show more examples of how it could be filled out so that assumptions are not made.

Ping @LeeGregory12d

[Moult]

Bump and ping @LeeGregory12d :)

[LeeGregory12d]

Dion, Luckily all the major infrastructure projects here in Australia are in either MGA94 and AHD, or MGA2020 and AHD. And they are the only ones presently asking for IFC files. So the Authorities haven't had to grapple with arbitrary Horizontal and Vertical Datums and Map Projections as yet.

Not that they are asking for IFC 4 files as yet - it is still usually IFC 2x3.

[Moult]

Cheers, but if they did ask, do you think Andreas' suggestion of following the GML example makes sense? Is that something that other infra people would understand?

[Moult]

Ping @pjanck @SergejMuhic is this still relevant? The current spec calls for "WKT", but has no mention of concatenating EPSG codes.

[pjanck]

Yes, it is relevant, e.g. after my conversation with @evandroAlfieri for his PR https://github.com/bSI-InfraRoom/MVD-Infra-Test-Instructions/pull/37, especially: https://github.com/bSI-InfraRoom/MVD-Infra-Test-Instructions/pull/37#discussion_r808789720 .

It is unclear to me, how to convey combinations of horizontal and vertical EPSG codes, where the combination's EPSG does not exist. The way I understand it, it is currently not possible in the IFC standard.

Possible solutions:

1. Add WKT string as I've proposed here - in this way, any combination imaginable, even without EPSG codes, is possible. Modelling within IFC schema is still under discussion following @SergejMuhic proposal - see https://github.com/bSI-InfraRoom/IFC-Specification/pull/330 .
2. Follow @arch1501 proposal to concatenate EPSG codes in IfcProjectedCRS::Name attribute using comas , - similar to how GML standards are doing it.
3. As proposed in the forum post: relax that IfcProjectedCRS::Name is mandatory and introduce a where rule to IfcProjectedCRS, which mandates:
   • either Name has to be provided
   • or GeodeticDatum, VerticalDatum, MapProjection, MapZone have to be provided

I don't really have a preference; all three solutions seem ok. It may be, that there is a fourth solution I'm not seeing right now. Happy to discuss this further.

[Moult]

@pjanck isn't your solution 1 already implemented? Or have I misunderstood?

The docs for ProjectedCRS say this, which I interpret as if you have a custom thing just name your CRS "WKT" and dump the WKT in the Description attribute:

# Name
> NOTE 2 The name shall be 'WKT' if an EPSG code does not exist for the CRS.

# Description
NOTE In case Name equals 'WKT' the Description is well-known text that corresponds to ISO 19162 definition specifying the necessary parameters for the coordinate reference system.

Example for ellipsoid: ELLIPSOID[,,,]

[pjanck]

@Moult yes and no. I see this is an "intermediary" solution, hijacking the Description attribute. I'd much more prefer a distinct WKT attribute on the entity IfcProjectedCRS; thus option 1.

[Moult]

OK so that's not going to happen in the next couple of days as it's a ton of work so let's put this on hold, and at least we have a workaround :)

[SergejMuhic]

IFC4X3 schema I would say just does not have this feature.