[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