[gdal-dev] Tag for units in GeoTIFF

Even Rouault even.rouault at spatialys.com
Thu Oct 26 10:10:23 PDT 2023


Le 26/10/2023 à 18:50, David Shean a écrit :
> Hi Even and Javier,
> For the special case of a DEM, would it make more sense to specify the 
> units with a vertical CRS?  This approach would define the LENGTHUNIT 
> and the associated vertical datum.
>
> Example for EPSG:4979:
>
>         AXIS["ellipsoidal height (h)",up,
>             ORDER[3],
>             LENGTHUNIT["metre",1]],
>
> Example for EPSG:5703:
>
> VERTCRS["NAVD88 height",
>     VDATUM["North American Vertical Datum 1988"],
>     CS[vertical,1],
>         AXIS["gravity-related height (H)",up,
>             LENGTHUNIT["metre",1]],
> ...
>
> More complicated than specifying the generic UNITTYPE in raster 
> metadata, but seems like best practice.

This is actually already implemented (deducing the value of 
GetUnitType() from the vertical component):

$ gdal_translate byte.tif out.tif -a_srs EPSG:4269+5703
$ gdalinfo out.tif | grep Unit
   Unit Type: foot

$ gdal_translate byte.tif out.tif -a_srs EPSG:4269+8228
$ gdalinfo out.tif | grep Unit
    Unit Type: foot


> -David
>
>
>> On Oct 26, 2023, at 4:45 AM, Javier Jimenez Shaw via gdal-dev 
>> <gdal-dev at lists.osgeo.org> wrote:
>>
>> Thanks!
>>
>> On Thu, 26 Oct 2023 at 12:27, Even Rouault via gdal-dev 
>> <gdal-dev at lists.osgeo.org> wrote:
>>
>>     Javier,
>>
>>     Le 26/10/2023 à 11:59, Javier Jimenez Shaw via gdal-dev a écrit :
>>>     Hi
>>>
>>>     Using a GeoTIFF with a single band and float values can be very
>>>     useful to show any distribution over the terrain. One typical
>>>     example is DSM (digital surface model), where the value is the
>>>     elevation on every point.
>>>
>>>     Is there any standard (or accepted) metadata to say the units of
>>>     those values?
>>
>>     API wise in GDAL, you should use the
>>     GDALRasterBand::SetUnitType() to set the unit
>>
>>     For TIFF, this will be encoded in the GDAL_METADATA TIFF tag like
>>     the following:
>>
>>     <GDALMetadata>
>>       <Item name="UNITTYPE" sample="0" role="unittype">foo</Item>
>>     </GDALMetadata>
>>
>>     Regarding the value itself, it is mostly unspecified by GDAL. It
>>     could be a good practice to suggest to use strings recognized by
>>     the "udunits" package (when possible), like done in the netCDF CF
>>     conventions
>>     (http://cfconventions.org/Data/cf-conventions/cf-conventions-1.10/cf-conventions.html#units)
>>
>>     Even
>>
>>>
>>>     In the typical case of DSM it is usually "meter" or "foot". But
>>>     it can be something else, like "people/km2" for population, or
>>>     "mm" for rain precipitation, or "kg/ha" for agricultural yield.
>>>
>>>     Thanks
>>>     .___ ._ ..._ .. . ._. .___ .. __ . _. . __..  ... .... ._ .__
>>>
>>>     _______________________________________________
>>>     gdal-dev mailing list
>>>     gdal-dev at lists.osgeo.org
>>>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>     -- 
>>     http://www.spatialys.com
>>     My software is free, but my time generally not.
>>
>>     _______________________________________________
>>     gdal-dev mailing list
>>     gdal-dev at lists.osgeo.org
>>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20231026/fe9f6a5c/attachment.htm>


More information about the gdal-dev mailing list