GeoTIFF for elevation data: handling Z dimension for ModelTiepointTag and ModelPixelScaleTag

[edevys]

When GeoTIFF contains elevation values (e.g. a DTM), VertCS should be specified and the Z dimension of ModelPixelScaleTag and ModelTiepointTag, respectively Z scaling factor and Z component of offset should be handled, read and written by GDAL driver, instead of being equal to 0 (as for 2D raster). Therefore Z scaling factor should be 1 (when the unit is the Vertical Unit associated to VertCS), or could be any decimation factor (e.g 0.01 if unit is cm). Z component of offset may be different from 0 if the elevation is provided relatively to a reference height. This is presently not handled by GDAL, which has therefore a limited support for Z dimension. More details (as GeoTIFF specification loosely specifies Vertcal dimension) is available in DGIWG GeoTIFF profile available under ​http://www.dgiwg.org/dgiwg/htm/documents/standards_implementation_profiles.htm

[Jukka Rahkonen]

Could you re-evaluate if priority=high and severity=critical still feels reasonable even if you try to think how mosts users are using GDAL?

[edevys]

Sure there may be several arguments in support of this severity and priority levels, though the common (bad) practise is ignorance of the VertCS and Z-dimension in these parameters (tags).

In other words, GDAL is (in the defaut mode) hiding the Z (even for altimetric files) in order to avoid creating disturbance to users that - in order to "make it work" have chosen to handle the Vertical CS and Z dimension outside the GeoTIFF tags. The (relatively recent) developement of the use of GeoTIFF for elevation due to INSPIRE and other production programs has pointed out these issues, and interest for communities to cleanup the handling of 2D1/2 (DTM) in GeoTIFF on basis of the specification principles (though Vertical was an extension to base of original GeoTIFF). The fact that GDAL toolkit has encouraged keeping this "bad practise statu quo" and users have been used to work around this outside the GeoTIFF mechanisms is (in my opinion as well as that of DGIWG) not to serve as a good reason to decrease the severity and priority levels. I have not put it at the highest level though, because users (such as DGIWG) have been used to try and work with it aside of these deficiencies. But it is high time that the GDAL toolbox handles this 3rd dimension correctly, as well as all COTS relying on GDAL. Note: the OGC (Open Geospatial consortium) is also in the process of revising GeoTIFF, and clarify / illustrate the use of GeoTIFF for elevation. This should be done in a similar way as the one submitted here.

[Jukka Rahkonen]

I do play a bit with orthophotos and DEMs and I have nothing against vertical datums. I suppose that we already have them in the GeoPackage raster driver even the Tiled Gridded Elevation extension got delayed by OGC. I would say that better handling of Z in GeoTIFF is a nice feature request.

What made me to write my unpolite comment, that I apologize, was that I rather see this request as a welcome improvement than being just one step below a "blocker" that prevents releasing new versions of GDAL. I still think that "critical" is quite heavy classification, comparable to something like creating shapefiles which cannot be opened by any other software. Well, that might be a "blocker" indeed.

[Jukka Rahkonen]

Hi @edevys,

I suppose that you could also add some good comments into ​https://trac.osgeo.org/geotiff/wiki/VerticalCS.

[edevys]

Replying to Jukka Rahkonen:

Hi @edevys,

I suppose that you could also add some good comments into ​https://trac.osgeo.org/geotiff/wiki/VerticalCS.

Hi Jukka I could gladly contribute to this wiki page, and the limitation of curent specification of geoTIFF: EPSG vertical datum code : requested to be between 5000 to 5299.

It seems an issue to me, also when users have an interest in Geoidal heights with modern Geoid such as EGM08, whose EPSG code is 3855. And widely used nowadays.

But as this wiki page is right now, there seem to be no placeholder for such use case.

[edevys]

Replying to Jukka Rahkonen:

I do play a bit with orthophotos and DEMs and I have nothing against vertical datums. I suppose that we already have them in the GeoPackage raster driver even the Tiled Gridded Elevation extension got delayed by OGC. I would say that better handling of Z in GeoTIFF is a nice feature request.

What made me to write my unpolite comment, that I apologize, was that I rather see this request as a welcome improvement than being just one step below a "blocker" that prevents releasing new versions of GDAL. I still think that "critical" is quite heavy classification, comparable to something like creating shapefiles which cannot be opened by any other software. Well, that might be a "blocker" indeed.

Well, I have to adjust my request, there is here nothing that is "a blocker", but the issue for Defense community is that GDAL in GeoTIFF is not able to deliver as is Vertical / elevation data in conformance with GeoTIFF principles, with a Z scaling factor that is correct. The fact that The GDAL Z-scaling factor is egal to 0 may provide some issues (If I dare I would say such a flat vision of the terrain). With a workflow with several GDAL transformations, in order to patch / force this Z-scaling factor to 1, it is possible for a software engineer to generate a correct file. However needless to say that COTS using GDAL are not doing this effort, and the result is the production and dissemination of data that is not correct. Subsequently, the adjustment of GDAL on this is considered as important (and critical for users of elevation data in geoTIFF, not for the delivery of the next version of GDAL). As regards GeoPackage for elevation, it does not solve this GeoTIFF issue, using a GPKG table to handle the documentation of vertical "metadata". Emmanuel

[Even Rouault]

In 41141:

GTiff: read/write Z dimension for ModelTiepointTag and ModelPixelScaleTag and translate it into/from band scale and offset, when there's a SRS with a vertical component (fixes #7093)

[Even Rouault]

In 41142:

gdal_translate: document newly introduced -a_scale / -a_offset (refs #7093)

[Even Rouault]

In 41143:

Commit forgotten file (refs #7093)