Misleading title "D.3. Geographic 3D CRS (case of ellipsoidal height)"

[rouault]

Paragraph "D.3 Geographic 3D CRS (case of ellipsoidal height)" of http://docs.opengeospatial.org/is/19-008r4/19-008r4.html#section-D-3 describes in its option b) what is actually a projected 3D CRS, so this doesn't match the title of the paragraph.

It should probably go into its own dedicated paragraph. And then the mention "In this document there are two possible means of describing a geographic 3D CRS." would be correct with the options being the current a) and c)

[EmDevys]

Hi Roger Maybe you received this (below), if not I prefer to ensure you get it. As Annex D is your contribution, could you please have a look and provide feedback?

Thanks in advance Cheers Emmanuel

De : Even Rouault [mailto:notifications@github.com] Envoyé : lundi 12 octobre 2020 17:31 À : opengeospatial/geotiff Cc : Subscribed Objet : [opengeospatial/geotiff] Misleading title "D.3. Geographic 3D CRS (case of ellipsoidal height)" (#82)

Paragraph "D.3 Geographic 3D CRS (case of ellipsoidal height)" of http://docs.opengeospatial.org/is/19-008r4/19-008r4.html#section-D-3 describes in its option b) what is actually a projected 3D CRS, so this doesn't match the title of the paragraph.

It should probably go into its own dedicated paragraph. And then the mention "In this document there are two possible means of describing a geographic 3D CRS." would be correct with the options being the current a) and c)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/geotiff/issues/82, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACDHG2S2Y5QZGI5AUCPPAVTSKMOK3ANCNFSM4SM6KWYQ.

[RogerLott]

In the ISO 19111 (OGC Abstract Spec Topic 2) data model an ellipsoidal height cannot exist as a 1D CRS, only as the height component of a geographic 3D CRS. GeoTIFF v1.0 does not cater for this. For reasons of retaining backward compatibility to GeoTIFF v1.0 specification without changing the overall scope of v1.1, this issue was not fixed in GeoTIFF v1.1 and there is no GTModelTypeGeoKey for a geographic 3D CRS. D.3 is documenting various work-arounds for carrying an ellipsoidal height in GeoTIFFv1.1.

Although perhaps not as clear as it might be, D.3(a) and D.3(b) are variations of the same thing. They both permit a geog3D CRS code to be given using the VerticalGeoKey but being vetical this should not lead to a geogCRS definition. Options (a) and (b) then need to find a way of defining an appropriate geodetic CRS, and are two different ways for defining a geog2D CRS. (a) is direct, (b) is indirect using the base CRS of a projected CRS.

Meanwhile we have an alternative in D.3(c) using an identified geographic 2D CRS and and a code from GeoTIFF v1.0 that is not and never has been an EPSG code to identify an ellipsoid height.

So D.3 offer three work-arounds for identifying ellipsoid height - D.3(a), D.3(b) and D.3(c) - and the first two of these, D.3(a) and D.3(b), describe a geographic 3D CRS.

D.3(b) is not a projected3D CRS. A proper definition of a projected3D CRS would not require any use of VerticalGeoKey. A GTModelTypeGeoKey value of 1 (if projected could be 2- or 3-D) or (more likelyand better) a yet-to-be-defined value for GTModelTypeGeoKey for projected3D would suffice.

But there is an error in the heading of table D.1 which should read Table D.1 - Deprecated codes from GeoTIFF v1.0 indicating Geographic 3D CRS ellipsoid heights (corresponding to option c)

[rouault]

Although perhaps not as clear as it might be, D.3(a) and D.3(b) are variations of the same thing. They both permit a geog3D CRS code to be given using the VerticalGeoKey but being vetical this should not lead to a geogCRS definition. Options (a) and (b) then need to find a way of defining an appropriate geodetic CRS, and are two different ways for defining a geog2D CRS. (a) is direct, (b) is indirect using the base CRS of a projected CRS. [... snip... ] D.3(b) is not a projected3D CRS.

I'm sorry, but I have really a hard time comprehending this. What's D.3(b) then ? Its horizontal part is a projected CRS, right ? So we can't decently call the resulting CRS a "Geographic 3D CRS" ? The projected nature can't be ignored, certainly. Or we have created a big ugly monster, if we allow people to use ProjectedCRSGeoKey + VerticalGeoKey to be a Geographic3D CRS ! In GDAL, this is interpreted as a Projected3D CRS.

[RogerLott]

In D.3(b) the key sentence is "The projected CRS should have as its base CRS the geographic 2D CRS which is the horizontal component of the geographic 3D CRS". (b) is a way of finding the base CRS. The baseCRS is geographic2D, not projected.

[RogerLott]

The recommendation is to use D.3(a).

[rouault]

In D.3(b) the key sentence is "The projected CRS should have as its base CRS the geographic 2D CRS which is the horizontal component of the geographic 3D CRS". (b) is a way of finding the base CRS. The baseCRS is geographic2D, not projected.

I agree with that. This is a matter of consistency. So if we use ProjectedCRSGeoKey = 32631 and VerticalGeoKey = 4979, we satisfy that requirement. But what is the CRS resulting from this combination ? We can't decently call this a Geographic3D CRS. That really makes no sense

[RogerLott]

Why not? The mechanism of combining with a genuine CRS identifier through ProjectedCRSGeoKey allows you to declare 4979, a geog3DCRS, which VerticalGeoKey alone cannot do. You have three work-arounds. I don't think you can expect three work-arounds to be consistent. Else one would do. But I suppose it depends on your definition of consistent. This will never be fixed without an extension/correction to GeoTIFF.

[rouault]

Why not? The mechanism of combining with a genuine CRS identifier through ProjectedCRSGeoKey allows you to declare 4979, a geog3DCRS, which VerticalGeoKey alone cannot do.

I'm sorry, but I don't see the usefulness of option 3b, if it really means what I understand of what you write. I'm still really really really surprised we would use GTModelTypeGeoKey = 1 (indicates that the Model CRS is a 2D projected coordinate reference system) + ProjectedCRSGeoKey + VerticalGeoKey to mean a Geographic 3D CRS. A Geographic 3D CRS implies that the X,Y values of a tie point would be geographic coordinates. Is there a valid reason to keep 3b ? I'm not aware this would be for backward compatibility. I guess everybody would be confused by such a combination. For me, the only meaning of 3b is Projected3D CRS. If we don't want to allow a Projected 3D CRS in this version of GeoTIFF, then at the very least, we should remove the possibility of 3b. It is extremely confusing.

@EmDevys opinion ?

[EmDevys]

Even, Roger and all I remember the discussions we had on this, and about the need to allow for Projected2D CRS + ellipsoidal heigth. This is a real use case, though not that common, and I guess it was possible (or rather not impossible) with GeoTIFF 1.0 (though very badly addressed), and in GeoTIFF 1.1 we did our best not to exclude this use case.

Of course, in D.3, the title “Geographic 3D CRS (case of ellipsoidal height)” does not imply that the CRS is geographic, but Geographic 3D CRS is the background (of ISO 19111) that has to be used – there is no other way – for handling this use case. May be the title should rather be “D.3. Use of Geographic 3D CRS (case of ellipsoidal height)”, in order to avoid such confusion than the one pushed by Even.

As Roger mentioned, there is a typo error in the title of Table D.1, which should be corrected to “(corresponding to option b)”. So at the same time, is there any clarification that could be added, and do you believe that changing the title to D.3. Use of Geographic 3D CRS (case of ellipsoidal height) would help ? @Roger and @Even does it make sense to you?

As mentioned by Roger, the clean and full resolution of this needs a significant change of GeoTIFF, when the requirements and resources may be made available for this. In the meantime, I hope GDAL may support GeoTIFF 1.1 as is (or slightly clarified) as it supported GeoTIFF 1.0.

Emmanuel

De : Even Rouault [mailto:notifications@github.com] Envoyé : lundi 12 octobre 2020 22:34 À : opengeospatial/geotiff Cc : Emmanuel Devys; Mention Objet : Re: [opengeospatial/geotiff] Misleading title "D.3. Geographic 3D CRS (case of ellipsoidal height)" (#82)

Why not? The mechanism of combining with a genuine CRS identifier through ProjectedCRSGeoKey allows you to declare 4979, a geog3DCRS, which VerticalGeoKey alone cannot do.

I'm sorry, but I don't see the usefulness of option 3b, if it really means what I understand of what you write. I'm still really really really surprised we would use GTModelTypeGeoKey = 1 (indicates that the Model CRS is a 2D projected coordinate reference system) + ProjectedCRSGeoKey + VerticalGeoKey to mean a Geographic 3D CRS. A Geographic 3D CRS implies that the X,Y values of a tie point would be geographic coordinates. Is there a valid reason to keep 3b ? I'm not aware this would be for backward compatibility. I guess everybody would be confused by such a combination. For me, the only meaning of 3b is Projected3D CRS. If we don't want to allow a Projected 3D CRS in this version of GeoTIFF, then at the very least, we should remove the possibility of 3b. It is extremely confusing.

@EmDevyshttps://github.com/EmDevys opinion ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/geotiff/issues/82#issuecomment-707332291, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACDHG2VC3MVP5SQIN6G7CBLSKNR33ANCNFSM4SM6KWYQ.

[rouault]

I remember the discussions we had on this, and about the need to allow for Projected2D CRS + ellipsoidal heigth.

I agree this is useful, and it is supported by GDAL. Maybe the resulting CRS/object should not be called a Projected 3D CRS, if that term has another meaning in geodesy.

As Roger mentioned, there is a typo error in the title of Table D.1, which should be corrected to “(corresponding to option b)”.

You probably meant "(corresponding to option c)"

and do you believe that changing the title to D.3. Use of Geographic 3D CRS (case of ellipsoidal height) would help ?

That would not be enough. The sentence just before exposing option a) is "In this document there are two possible means of describing a geographic 3D CRS." and this is equally confusing.

[RogerLott]

D.3 is really "Temporary provisions for including ellipsoidal height as one of the coordinates in GeoTIFF". They key term is ellipsoidal height, not Geographic 3D CRS. I do not think changing the title will help much, as what is missing is a description of the concept.

[RogerLott]

But changing "In this document there are two possible means of describing a geographic 3D CRS" to "In this document there are three possible means of describing ellipsoidal height as one of the coordinates in a GeoTIFF v1.1 file. All are temporary solutions".

[rouault]

@RogerLott I like your suggestions. I've stacked them in https://github.com/opengeospatial/geotiff/pull/83 . I've also tried to clarify the content of options a) and b)

One last thing I don't find fully satisfactory is the mention in a) "(this is the recommended option)". This is the recommended option compared to c) certainly, but a) isn't really an alternative to b)

[EmDevys]

You probably meant "(corresponding to option c)" Yes, of course (my bad)

De : Even Rouault [mailto:notifications@github.com] Envoyé : lundi 12 octobre 2020 23:23 À : opengeospatial/geotiff Cc : Emmanuel Devys; Mention Objet : Re: [opengeospatial/geotiff] Misleading title "D.3. Geographic 3D CRS (case of ellipsoidal height)" (#82)

I remember the discussions we had on this, and about the need to allow for Projected2D CRS + ellipsoidal heigth.

I agree this is useful, and it is supported by GDAL. Maybe the resulting CRS/object should not be called a Projected 3D CRS, if that term has another meaning in geodesy.

As Roger mentioned, there is a typo error in the title of Table D.1, which should be corrected to “(corresponding to option b)”.

You probably meant "(corresponding to option c)"

and do you believe that changing the title to D.3. Use of Geographic 3D CRS (case of ellipsoidal height) would help ?

That would not be enough. The sentence just before exposing option a) is "In this document there are two possible means of describing a geographic 3D CRS." and this is equally confusing.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/geotiff/issues/82#issuecomment-707352432, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACDHG2URMNNTMJJ234ZPW3DSKNXT7ANCNFSM4SM6KWYQ.

[EmDevys]

One last thing I don't find fully satisfactory is the mention in a) "(this is the recommended option)". This is the recommended option compared to c) certainly, but a) isn't really an alternative to b) I agree (at least partly). @RogerLott what is your opinion on this? For sure, Option a/ is the best option for use of ellipsoidal height. Option b/ is a work-around, for a possible use case, which is not that common.

De : Even Rouault [mailto:notifications@github.com] Envoyé : mardi 13 octobre 2020 00:11 À : opengeospatial/geotiff Cc : Emmanuel Devys; Mention Objet : Re: [opengeospatial/geotiff] Misleading title "D.3. Geographic 3D CRS (case of ellipsoidal height)" (#82)

@RogerLotthttps://github.com/RogerLott I like your suggestions. I've stacked them in #83https://github.com/opengeospatial/geotiff/pull/83 . I've also tried to clarify the content of options a) and b)

One last thing I don't find fully satisfactory is the mention in a) "(this is the recommended option)". This is the recommended option compared to c) certainly, but a) isn't really an alternative to b)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/geotiff/issues/82#issuecomment-707370817, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACDHG2SIAEGIHCUYNSKBTLDSKN5IXANCNFSM4SM6KWYQ.

[RogerLott]

A 'height' associated with a projected CRS (i) in practice would be most likely would be gravity-related (in the case of a compound CRS, which GeoTIFF v1.1 cannot describe but D.2 offers a work-around), (ii) would be ellipsoidal in the case of a projected 3D CRS (which GeoTIFF v1.1 cannot identify), and (iii) in current practice may actually be an observation or measurement incorrectly described as a coordinate. So there is potential for ambiguity. In a geographic3D CRS the height element is ellipsoidal height; it cannot be gravity-related. So option D.3(a) is to be preferred because if the 'height' genuinely is an ellipsoidal height, the risk of ambiguity is reduced. Conversely, the very fact that this issue is being discussed at all perhaps suggests that D.3(b) is the more confusing of these two options. There is also slightly less work to do to confirm that the CRS codes represent related geog2D and geog3D CRSs than there is in confirming that a projCRS and geog3D CRS are related, but this is a very minor issue. So some small reasons to prefer D.3(a) over D.3(b). But it is actually going to depend upon whether the horizontal coordinates are graticule or grid. There are problems with GeoTIFF v1.1 inherited from v1.0 in that it does properly deal with height. But it does properly deal with horizontal 2D CRS being geog2D or projcted and these should be correctly documented. D.3(c) most closely follows the provisions of GeoTIFF v1.0 but these are technically very incorrect and from my perspective this is the poorest of the three work-around options.

[hobu]

This is a real use case, though not that common, and I guess it was possible (or rather not impossible) with GeoTIFF 1.0 (though very badly addressed),

A lot of these edge cases are coming from ASPRS LAS' use of GeoTIFF to define its coordinate system descriptions.