-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Misleading title "D.3. Geographic 3D CRS (case of ellipsoidal height)" #82
Comments
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 GitHub<#82>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACDHG2S2Y5QZGI5AUCPPAVTSKMOK3ANCNFSM4SM6KWYQ>.
|
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 |
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. |
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 |
The recommendation is to use D.3(a). |
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 |
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. @EmDevys opinion ? |
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.
@EmDevys<https://github.com/EmDevys> opinion ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#82 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACDHG2VC3MVP5SQIN6G7CBLSKNR33ANCNFSM4SM6KWYQ>.
|
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.
You probably meant "(corresponding to option c)"
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. |
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. |
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". |
Fixes opengeospatial#82 Wording provided by Roger Lott.
Fixes opengeospatial#82 Part of wording provided by Roger Lott.
Fixes opengeospatial#82 Part of wording provided by Roger Lott.
@RogerLott I like your suggestions. I've stacked them in #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 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 GitHub<#82 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACDHG2URMNNTMJJ234ZPW3DSKNXT7ANCNFSM4SM6KWYQ>.
|
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)
@RogerLott<https://github.com/RogerLott> I like your suggestions. I've stacked them in #83<#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 GitHub<#82 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACDHG2SIAEGIHCUYNSKBTLDSKN5IXANCNFSM4SM6KWYQ>.
|
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. |
A lot of these edge cases are coming from ASPRS LAS' use of GeoTIFF to define its coordinate system descriptions. |
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)
The text was updated successfully, but these errors were encountered: