Vertical Coordinate Systems

[tedhabermann]

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.

[EmDevys]

This issue is addressed in DGIWG profile. DGIWG may help to contribute on this, I could help as necessary.

[rouault]

The issue is described in detail in https://trac.osgeo.org/geotiff/ticket/24

[max-martinez]

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.

[rouault]

@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:

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.

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.

[RogerLott]

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.

[EmDevys]

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 @RogerLotthttps://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 @RogerLotthttps://github.com/RogerLott, @rouaulthttps://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-martinezhttps://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 @RogerLotthttps://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 GitHubhttps://github.com/opengeospatial/geotiff/issues/7#issuecomment-449515411, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIZzaonDi2-OkYhOUir30unsuV520-QWks5u7WKQgaJpZM4DCPmZ.

[rouault]

In addition, this solution is already supported by GDAL.

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.

[max-martinez]

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).

It [GDAL] wil report an invalid CompoundCRS made of EPSG:4326 for the horizontal part + EPSG:4979 for the vertical part.

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.

[rouault]

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

[EmDevys]

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 GitHubhttps://github.com/opengeospatial/geotiff/issues/7#issuecomment-449556555, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIZzag33pud_ZLHuHiey2gGiVB0Oc78Eks5u7fWmgaJpZM4DCPmZ.

[desruisseaux]

(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)

Actually it was not cover in ISO 19111:2007 but is now covered by ISO 19111:2018. It would be a ProjectedCRS associated with a three-dimensional CartesianCS, in the same way that we can have GeographicCRS associated to three-dimensional EllipsoidalCS.

[rouault]

It would be a ProjectedCRS associated with a three-dimensional CartesianCS

agreed. Retracting that part of my comment.

[RogerLott]

> It would be a ProjectedCRS associated with a three-dimensional CartesianCS,

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. (Further description of the issues of how to handle absolutely nothing to do with vertical CRSs)

[RogerLott]

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

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)

[RogerLott]

See post just made to issue #52.

[EmDevys]

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, ...) A) Using Geographic 3D (and soon Projected 3D - as should be provided by EPSG register) CRS codes (but no Vertical Geokey), or Geographic 2D/Projected 2D + Vertical CRS 1D Pro: "Abstract Topic 2 cosher", and thus more easy implementable for software that uses such modeling directly or indirectly (through WKT for example). This is the version proposed by Roger Lott in material for update. a) Geographic 3D (and possible definition of Projected 3D CRS) Example of Geographic 3D CRS GTModelTypeGeoKey = 2 (Geographic CRS) GeodeticCRSGeoKey = 4979 (WGS84 3D)

Example of user-defined Projected 3D CRS GTModelTypeGeoKey = 1 (Projected CRS) ProjectedCRSGeoKey = 32767 user defined GeodeticCRSGeoKey = 4979 (WGS84 3D) ProjectedGeoKey = 16031 (UTM 31North)

Example of Projected 3D CRS (once Projected 3D CRS are available in EPSG dataset) GTModelTypeGeoKey = 1 (Projected CRS) ProjectedCRSGeoKey = to_be_defined (UTM 31N WGS84 3D)

In this sub-case, Vertical***GeoKeys are not used Consequence: the vertical unit is constrained by the definition of the GeodeticCRS or ProjectedCRS (depending on above subcases) b) """CompoundCRS""": Horizontal CRS + Vertical CRS Example of Geographic 2D CRS + 1D Vertical CRS GTModelTypeGeoKey = 2 (Geographic CRS) GeodeticCRSGeoKey = 4326 (WGS84 2D) VerticalCRSGeoKey = 3855 (EGM2008)

Example of Projected 2D CRS + 1D Vertical CRS GTModelTypeGeoKey = 1 (Projected CRS) ProjectedCRSGeoKey = 32631 (UTM 31N WGS84) VerticalCRSGeoKey = 3855 (EGM2008)

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) GeographicCRSGeoKey should only contain Geographic 2D CRS ProjectedCRSGeoKey should only contain Projected 2D CRS This conforms with the current practice of GeoTIFF that only lists codes for 2D CRS. Pro: GeoTIFF readers ignoring the vertical part and only dealing with 2D horizontal CRS can read such files Pro: used by DGIWG GeoTIFF profile (only for 4979 currently) - use of Geographic 3D CRS is not significant. a) Geographic 2D + "patch" use of Geographic3D to definie Vertical Reference Example of Geographic 3D CRS GTModelTypeGeoKey = 2 (Geographic CRS) GeodeticCRSGeoKey = 4326 (WGS84 2D) VerticalGeoKey = 4979 (WGS84 3D) being aware that this is a "patch" use of a geographic 3D code for defining the vertical reference, which is only acceptable as an interim solution.

The geodetic datum of the GeodeticCRSGeoKey and VerticalGeoKey must be identical (here 6326 = WGS 84 datum) Example of a Projected 3D CRS GTModelTypeGeoKey = 1 (Projected CRS) ProjectedCRSGeoKey = 32631 (UTM 31N WGS84) VerticalGeoKey = 4979 (WGS84 3D) The geodetic datum of the base CRS of the ProjectedCRSGeoKey and VerticalGeoKey must be identical (here 6326 = WGS 84 datum) b) """CompoundCRS""": Horizontal CRS + Vertical CRS Example of Geographic 2D CRS + 1D Vertical CRS GTModelTypeGeoKey = 2 (Geographic CRS) GeodeticCRSGeoKey = 4326 (WGS84 2D) VerticalCRSGeoKey = 3855 (EGM2008)

Example of Projected 2D CRS + 1D Vertical CRS GTModelTypeGeoKey = 1 (Projected CRS) ProjectedCRSGeoKey = 32631 (UTM 31N WGS84) VerticalCRSGeoKey = 3855 (EGM2008)

[max-martinez]

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.

[rouault]

which implies that option B is somehow not kosher with respect to AT 2.

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 ProjectedCRSGeoKey = 32631 (UTM 31N WGS84) + VerticalGeoKey = 4979, you will for example start by instanciating a ProjectedCRS from the EPSG:32631 entry, and when seeing VerticalGeoKey = 4979, you'll have to "patch" it by replacing its baseCRS from EPSG:4326 (implied by EPSG:32631)

[max-martinez]

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. Opening the 3D door to the PCS/GCS keys increases this risk merely to accommodate a small subset of use cases to which GeoTIFF applies.

 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.

[rouault]

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

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.

[EmDevys]

All I carefully read again the discussion, and my final proposal is Option B which is preferred because:

• better backward-compatibility because no additional use of3D CRS codes in GeographicCRSGeoKey et ProjectedCRSGeoKey (as GeoTIFF 1.0)
• usage by DGIWG and NGA (though this usage seems limited up to now)
• introduction of 3D CRS codes might create more inconsistencies in this minor revision.

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. I understand that geodetist may scratch their head in the case Geographic 3D codes are used as Vertical reference system, so if necessary we may rename the VerticalCRSGeoKey VerticalGeoKey, in order to avoid nasty criticism. Here we are in the GeoTIFF grids / raster and may have specific usages to describe the content of the grid (called range according to coverage model). Here we are not describing the other usual geometries of OGC and TC211 standards. Let's remember that we also have to provide the metdata for Transforamtion tags accoring to long, lat, height (in the GeoTIFF tag), even if we use WGS84.

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. Of course, this proposal will be finally approved by the working / editing team in the coming telecon.

[RogerLott]

I have no objection to option B, that is for Requirement http://www.opengis.net/spec/GeoTIFF/0.0/GTModelTypeGeoKey.value The GTModelTypeGeoKey value SHALL be: ... • 1 to indicate that the Model CRS is a 2D projected coordinate reference system from the GeoTIFF standard CRS register or user defined, indicated by the value of the ProjectedCRSGeoKey; or • 2 to indicate that the Model CRS is a geographic 2D coordinate reference system from the GeoTIFF standard CRS register or user defined, indicated by the value of the GeodeticCRSGeoKey ...

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 VerticalGeoKey values in the range 1024-32766 SHALL be either EPSG vertical CRS codes or EPSG geographic 3D CRS codes. NOTE: In GeoTIFF v1.0 the ranges were 5000-5099 and 5200-5999. As at 2018-05-29 no EPSG vertical CRSs have been or are in this range. Values in this range have been and are used as EPSG vertical datum codes; in this document their use as codes for vertical CRSs is deprecated.

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.

[EmDevys]

So let's go for this option, and change the requirements and related annexes as you propose. In my opinion, we arechanging VerticalCSTypeGeoKey (in GeoTIFF 1.0) to VerticalGeoKey (and we had VerticalCRSGeokey in the word version that you proposed recently, which was strictly limited to 1D gravity-related CRS). I see no reason for adding another GeoKey in this minor revision, so there should be no addition of VerticalCRSGeoKey in this version. We should presumably add some explanatory text such as the explanation you provided ... where VerticalCRS term may be used. I can try and do the adjustments in the asciidoc draft, so that the consolidated version (and pdf) that should be generated by Wed. reflects this decision and key topic correctly. Of course, it will need to be reviewed thoroughly.