-
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
Vertical Coordinate Systems #7
Comments
This issue is addressed in DGIWG profile. DGIWG may help to contribute on this, I could help as necessary. |
The issue is described in detail in https://trac.osgeo.org/geotiff/ticket/24 |
Resolving/refining the specification of the vcs keys doesn't address the DEM use case completely. This was discussed a bit in email but I summarize here. The Refining GeoTIFF suggestion does not appear to present a viable case for ellipsoidal height because the example given (GCS_WGS_84) doesn't make much sense. Why would I understand the pixel values to represent heights if a 2D geographic CRS is specified? The DGIWG approach seems better to me (though would need to be clearly explained). There seems to be only one sample case (4979) but you could generalize it thusly: if you specify a 3D Geographic code for the value of the VerticalCSType key, its geodetic datum must match that explicitly supplied by the geog* or implied by the proj* keys defining the horizontal information and it should be taken to mean that the pixel values are ellipsoidal heights in the system so referenced. Likewise, for non-standard info, a geodetic datum code could be supplied for the value of the VerticalDatum key with the same matching requirement and it would be interpreted as ellipsoidal height. I am assuming these codespaces do not intersect in EPSG but haven't confirmed. |
@max-martinez Your proposal could technically work, with the strong assumption that codes for GeographicCRS and VerticalCRS will never ever intersect in the EPSG dataset (perhaps @RogerLott could confirm or inform this assumption), and similarly for Geodetic datum vs Vertical Datum. However it makes me a bit uneasy:
That would seem odd to me to put a Geographic CRS code in a key called VerticalCSType, although that seems what DGIWG suggests. I assumed we would want VerticalCSType to be only a EPSG VerticalCRS code. If you want a ellipsoidal height for a geographic CRS, then you could set a Geographic3D CRS code in GeographicTypeGeoKey, and don't set VerticalCSType at all. Otherwise, as you raised, someone could define a GeodeticCRS with a datum, and a Geographic3D CRS with another datum, which would be non sense.
Yes, they don't intersect (currently at least), as this is a single table for both geodetic and vertical datum in the EPSG dataset. But same remark as above: putting a Geodetic datum code in a key called VerticalDatum would seem odd to me. |
I can confirm that in the EPSG Dataset there is no overlap between any subtypes of CRS - all CRSs share a common code allocation, so there will not be vertical or 3D geographic CRSs (or any other subtypes of CRS) with identical EPSG CRS codes. Similarly for all subtypes of datum. However CRS codes and datum codes operate in different urn/uri space, differentiated by the object-type element of the string, and there can be (indeed is) overlap in code values as both CRS and datum (and all other object types) now use the full range 1024-32766 and are each allocated vacant values sequentially upwards within their own range. I too find the entry of a geographic 3D CRS code in a key intended for a vertical CRS rather strange (to put it mildly). But I understand it to be a [rather unfortunate] Community practice. Vertical CRS is a gravity-related height, with a datum usually approximating the geoid = +/- MSL. Like @rouault I feel that entry of a geographc 3D CRS code in GeographicTypeGeoKey is far more logical. However the EPSG code alone is insufficient for determining whether the geographic CRS is 2D or 3D. GeoTIFF ought, in my view, to create further values for GTModelTypeGeoKey to permit this distinction. But that is for the future. For this porting I am intending to explain entries of either a true vertical CRS or a geographic 3D into the VerticalCSTypeGeoKey. Once we have a revision with extended GTModelTypeGeoKey codes then the entry of an EPSG geographc 3D CRS code into VerticalCSTypeGeoKey should be deprecated. Is there any usage of a geographic 3D CRs code in GeographicTypeGeoKey? If definitely not then we could at least clarify that GTModelTypeGeoKey = 2 = geographic 2D. |
Apparently, the Geographic CS Type Codes in existing GeoTIFF are Geographic 2D codes, with no Geographic3D codes.
Roger and myself discussed this in Charlotte, and because we don’t want to re-engineer GeoTIFF and break backward compatibility in this version, the solution was the kind of “patch” that DGIWG has proposed, and which was believed as acceptable by Roger. I let @RogerLott<https://github.com/RogerLott> confirm, and others validate (or object). In addition, this solution is already supported by GDAL.
The generalization proposed by Max seems acceptable to me (and here also I let @RogerLott<https://github.com/RogerLott>, @rouault<https://github.com/opengeospatial/geotiff/issues?q=is%3Aissue+is%3Aopen+author%3Arouault> and others validate).
Presumably, in the future, an improved model for CRS in GeoTIFF is to designed.
De : Even Rouault [mailto:notifications@github.com]
Envoyé : vendredi 21 décembre 2018 23:37
À : opengeospatial/geotiff
Cc : Emmanuel Devys; Comment
Objet : Re: [opengeospatial/geotiff] Vertical Coordinate Systems (#7)
@max-martinez<https://github.com/max-martinez> Your proposal could technically work, with the strong assumption that codes for GeographicCRS and VerticalCRS will never ever intersect in the EPSG dataset (perhaps @RogerLott<https://github.com/RogerLott> could confirm or inform this assumption), and similarly for Geodetic datum vs Vertical Datum. However it makes me a bit uneasy:
if you specify a 3D Geographic code for the value of the VerticalCSType key
That would seem odd to me to put a Geographic CRS code in a key called VerticalCSType, although that seems what DGIWG suggests. I assumed we would want VerticalCSType to be only a EPSG VerticalCRS code. If you want a ellipsoidal height for a geographic CRS, then you could set a Geographic3D CRS code in GeographicTypeGeoKey, and don't set VerticalCSType at all. Otherwise, as you raised, someone could define a GeodeticCRS with a datum, and a Geographic3D CRS with another datum, which would be non sense.
(What that wouldn't cover is a ProjectedCRS as the horizontal CRS and an ellipsoidal height of the base CRS of this ProjectedCRS, but that cannot be modeled currently in Topic 2 or EPSG as far as I know)
I am assuming these codespaces do not intersect in EPSG but haven't confirmed.
Yes, they don't intersect (currently at least), as this is a single table for both geodetic and vertical datum in the EPSG dataset. But same remark as above: putting a Geodetic datum code in a key called VerticalDatum would seem odd to me.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#7 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIZzaonDi2-OkYhOUir30unsuV520-QWks5u7WKQgaJpZM4DCPmZ>.
|
Hum, just tested it,but that doesn't work very well if you put 4979 for VerticalCSTypeGeoKey and 4326 for GeographicTypeGeoKey. It wil report an invalid CompoundCRS made of EPSG:4326 for the horizontal part + EPSG:4979 for the vertical part. |
In the absence of major re-work, the use of Vertical* keys to reference vertical or geodetic identified objects (and just amending the documentation for the keys) seems more practical and the lesser of two evils. It allows you to be consistent about the georeferencing (the raster data is always georeferenced to a 2D CRS, as it should be) without doing any hand-waving. It retains the clarity and simplicity of understanding when the attribute values represent some sort of height (i.e,, when the Vertical* information is present).
Yes, 1.1 data won't all be able to be backwardly compatible. But there's nothing out there now that can be said to be working according to spec for this case that will get broken. |
OK, I can see the advantage of having Vertical* keys referencing vertical or geodetic identified objects and leaving GeographicTypeGeoKey referencing 2D CRS only for existing GeoTIFF readers that don't handle the vertical part at all |
Sounds good, thanks Max for advocating this « lesser of two evils » solution. Therefore 1.0 would probably not allow this (so in other words not allow for any use of ellipsoidal height), and 1.1 version would allow it.
In order not to dramatize this issue – no ellipsoidal 3D reference system - for version 1.0, I would add that most elevation data produced nowadays uses orthometric height (geoid or MSL), whether it is DTM, DSM or bathymetric data.
De : Even Rouault [mailto:notifications@github.com]
Envoyé : samedi 22 décembre 2018 10:05
À : opengeospatial/geotiff
Cc : Emmanuel Devys; Comment
Objet : Re: [opengeospatial/geotiff] Vertical Coordinate Systems (#7)
OK, I can see the advantage of having Vertical* keys referencing vertical or geodetic identified objects and leaving GeographicTypeGeoKey referencing 2D CRS only for existing GeoTIFF readers that don't handle the vertical part at all
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#7 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIZzag33pud_ZLHuHiey2gGiVB0Oc78Eks5u7fWmgaJpZM4DCPmZ>.
|
Actually it was not cover in ISO 19111:2007 but is now covered by ISO 19111:2018. It would be a |
agreed. Retracting that part of my comment. |
That is correct. But right now there are no projected 3D CRSs in the EPSG Dataset to refer to. We have yet to decide how to handle them and do not want to load any until this is finalised. Our plan is to finalise our decision during our late March 2019 meeting. |
But that is not the complete picture. GeographicTypeGeoKey can also be used to reference a geocentric (Cartesian 3D) CRS. Constraining GeographicTypeGeoKey to geographic 2D would break any use of this. This might be rather academic as I can't imagine much if any use so far of the model CRS being geocentric Cartesian. (This will be the way of the future, so to be planned for, but not something for this porting of GeoTIFF v1.0) |
See post just made to issue #52. |
We have 2 options for handling Vertical reference system in this minor revision of geoTIFF, and must decide one (only). Thanks in advance to send objections (if any) to any of these options, or vote for any option, in order to allow for a consensus in this revised version (before finalizing an initial draft version). We have tried to illustrate in details how the 2 options could be handled, 1st one being a way forward for GTModel (which would be able to handle not only 2D reference systems but also 3D), and 2nd one more a "patch" which would not allow for 3D reference system, but via the use of Vertical Reference system for defining all standardized use cases / reference systems: height above geoid, above sea level, and above ellipsoid (the latter one resulting in the use of a geographic 3D code – from EPSG register - for defining the Vertical reference (which would then NOT be called Vertical CRS but something like VerticalGeoKey). Two approaches for handling Vertical reference definition for elevation data (such as DTM, DSM, ...) Example of user-defined Projected 3D CRS Example of Projected 3D CRS (once Projected 3D CRS are available in EPSG dataset) In this sub-case, Vertical***GeoKeys are not used Example of Projected 2D CRS + 1D Vertical CRS B) Using a VerticalGeoKey (renamed from VerticalCSGeoKey) that can contain the code of a geographic 3D CRS or vertical CRS (or soon a projected 3D CRS) The geodetic datum of the GeodeticCRSGeoKey and VerticalGeoKey must be identical (here 6326 = WGS 84 datum) Example of Projected 2D CRS + 1D Vertical CRS |
A Pro has been put forth for option A (“Abstract Topic 2 cosher”) which implies that option B is somehow not kosher with respect to AT 2. Can you either explain briefly how it is not kosher or clarify that option B is also “Abstract Topic 2 cosher” (assuming proper explanation of re-naming/re-purposing of the VerticalCSType, VerticalDatum, etc. geokeys)? If option B is truly not AT 2 kosher, that would be of some concern. I’ll also note that, in addition to DGIWG, NGA in the U.S. not surprisingly includes the use of a 3D Geographic code as a value for the VerticalCSType in its GeoTIFF profile (http://www.gwg.nga.mil/ntb/baseline/docs/nga.ip.0001_1.0-geotiff/NGA.IP.0001_2.0.pdf). Can’t say to what degree they’ve utilized that. I favor option B but that might change with your additional elaboration on AT 2 (non)suitability. |
The summary naming "Abstract Topic 2 cosher" is mine and probably not that great :-), so I guess I must explain it a bit. Option A is a direct mapping of objects of AT 2. In Option B, the VerticalGeoKey (that should also be used as a name in B)b) by the way) mixes different subtype of objects and has the potential risk of leading to inconsistencies in case a Geographic3D CRS code is used in VerticalGeoKey, whose geodetic datum is not the same as the one of GeographicCRSGeoKey or the one implied by ProjectedCRSGeoKey. So in that respect, it is less close to AT 2. It is workable, but for implementations that are close to topic 2 cases like |
OK, thanks for clarifying the discomfort. Let me make a few additional observations. AT 2 does not appear to me to make any claims that any piece of metadata representing the AT 2 CRS concept needs to have constraints providing that only one subtype of CRS is allowed to be represented. If so, the OGC would already be non-kosher in many specifications including GML (SRS ID), and the SWE Common Data model (referenceFrame in various places) and probably many other locations. This constraint doesn’t actually even seem to be a traditional GeoTIFF constraint, as the 1.0 specification (presumably, though not clearly) allowed both Geocentric and Geographic CRS codes to be referenced from the Geog* GeoKeys. has the potential risk of leading to inconsistencies Well, if we go with (A), your implementation is happy when it finds 4979 (3D WGS 84) in the GCS info and it’s happy when it finds 4326 (2D WGS 84) in the GCS and 3855 (EGM 2008) in the Vertical, but then it starts scratching its head when it finds 4979 in the GCS and 3855 in the Vertical. Or worse, it finds 6893 (Compound WGS 84 / World Mercator + EGM 2008) in the PCS and 5773 (EGM 96) in the Vertical. There is no end to the inconsistencies that can be created no matter which way you go. for implementations that are close to topic 2 I think you need to explain why you feel that an implementation that always attempts to combine the horizontal and vertical information into a single 3D CRS in the case of DEMs is any closer to AT 2 than an implementation that deals with two independent CRS definitions, one that defines the CRS to which the coverage is referenced and the other that defines the context in which its range values are interpreted. The latter will consult the horizontal reference for full context if and when required. |
I don't care enough about this use case to argue more :-) My gut feeling was that A) is (a bit) cleaner than B), but I agree with your objections that A) can also lead to inconsistent CRS. With the points you made, I think I'm rather indifferent now on either option. |
All
Clearly, even if it is the way forward for the future version of GeoTIFF, allowing 3D CRS in the present GeographicCRSGeoKey and ProjectedCRSGeoKey is a major extension, that would need a better re-engineering of GeoTIFF tags in order to allow alignment with EPSG register. Therefore, unless there is a major objection in the days to come, I propose to update the asciidoc according to this option, and forget about Geographic and PRojected 3D in this minor revision (this should also slightly simplify the requirements and annex-b. |
I have no objection to option B, that is for Requirement http://www.opengis.net/spec/GeoTIFF/0.0/GTModelTypeGeoKey.value as long as the verticalCS key name is changed to VerticalGeoKey. I think that going forward the best option for GTModelTypeGeoKEY values 1 and 2 is to restrict them to 2D (and create extra values for other model types), so introducing this explicit statement now when use of them for 3D is limited is a good thing. However going forward it is important that verticalCRS is a 1D gravity-related CRS and that ellipsoidal height cannot be 1D, only as the height part of a geographic 3D CRS. So if codes of both 1D gravity-related CRS and geographic 3D CRS are to be put into this single key it must not be called VerticalCSGeoKey or VerticalCRSGeoKey. VerticalCRSGeoKey must be used for genuine 1D vertical CRS as defined in Topic 2. VerticalGeoKey is acceptable for the joint key name. Then: Requirement http://www.opengis.net/spec/GeoTIFF/0.0/**VerticalGeoKey**.EPSG Question: Are both VerticalGeoKey and VerticalCRSGeoKey being included in this v1.1? A consequence of this is that several of the options I described in revised Annex D.2 need to be removed: (a) and (b) become invalid so should be removed. Current (e) will become option (c) and remain the recommendation in this v1.1. |
So let's go for this option, and change the requirements and related annexes as you propose. |
This problem is described by Frank Warmerdam on the Refining GeoTIFF page.
The information on vertical coordinate systems in the GeoTIFF Specification was pretty slim (see 2.5.3.4 and 6.3.4) and and it has taken a long time to establish industry practice on this topic. An effort has been made to suggest best practice at VerticalCS and after review I suggest this make it's way into the specification in some form.
The text was updated successfully, but these errors were encountered: