Opened 14 months ago

Closed 12 months ago

Last modified 12 months ago

#7093 closed defect (fixed)

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

Reported by: edevys Owned by: warmerdam
Priority: high Milestone:
Component: GDAL_Raster Version: unspecified
Severity: critical Keywords: GeoTIFF elevation Z-component
Cc:

Description

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

Change History (9)

comment:1 Changed 14 months ago by 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?

comment:2 Changed 14 months ago by 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.

comment:3 Changed 14 months ago by 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.

comment:4 Changed 14 months ago by Jukka Rahkonen

Hi @edevys,

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

comment:5 in reply to:  4 Changed 14 months ago by 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.

comment:6 in reply to:  3 Changed 14 months ago by 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

comment:7 Changed 12 months ago by Even Rouault

Resolution: fixed
Status: newclosed

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)

comment:8 Changed 12 months ago by Even Rouault

In 41142:

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

comment:9 Changed 12 months ago by Even Rouault

In 41143:

Commit forgotten file (refs #7093)

Note: See TracTickets for help on using tickets.