[gdal-dev] best tiff tag names for start and end datetimes?

Javier Jimenez Shaw j1 at jimenezshaw.com
Fri May 13 11:27:20 PDT 2022


My experience with XMP was positive.
Some time ago I did a couple of PRs to store the XMP in the original TIFF
tag (not in GDAL metadata), and to copy it properly when creating(copying)
a COG.
GDAL is not parsing the XML content, it is your task. We are using exiv2,
but I hope there are other/better solutions. One benefit with GDAL respect
to exiv2 is that it can work with BigTIFF files, that exiv2 doesn't (but it
works if I provide directly the XML string).

One good and bad thing is that using an easily configurable XML you can use
the convention that you want, but it probably does not match with other
people's conventions.

About the lack of timezone in Exif and tifftag datetime, I was really
disappointed when I discovered it. Yes, please, use an ISO format with
timezone.

Cheers,
Javier
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.


Simon,

metadata is a tricky subject. To my knowledge, up to know most data
producers of GeoTIFF files have used minimalist embedded metadata in the
TIFF file itself (mostly using the ImageDescription, Copyright field),
but rather using text or xml side car files to provide their own
metadata model. See
https://github.com/OSGeo/gdal/tree/master/gcore/mdreader for a number
of
metadata importers. Those metadata importers expose the "raw" metadata
from the side car files, but also try to gather and expose a very
minimum set of information in a IMAGERY metadata domain:
https://gdal.org/user/raster_data_model.html#imagery-domain-remote-sensing

The TIFF tag mechanism makes it impractical to add "arbitary" metadata
keys beyond what the baseline TIFF spec defines. So an option is to use
a generic "container" like the GDAL_METADATA tag. Other options could be
the GEO_METADATA one
(https://www.awaresystems.be/imaging/tiff/tifftags/geo_metadata.html
using a full ISO metadata model). Someone on the TIFF mailing list also
mentioned the possibility of using XMP
(https://www.awaresystems.be/imaging/tiff/tifftags/xmp.html). From a
pure GDAL perspective, the GDAL_METADATA one is the most straightforward
as this is what will be always reported by a gdalinfo dump for example.

I feel an initiative gathering a representative set of GeoTIFF
geospatial products would make sense to define standardized metadata (to
start with decide which existing TIFF tag should be the holder of the
metadata, and then standardize metadata items) would make sense with COG
growing adoption (possibly inspired by what STAC provides), rather than
pushing quickly something for ad-hoc needs. Not sure which forum would
be the best for that. Probably some dedicated github repository.

I'd see a first metadata item that would make sense, a METADATA_PROFILE
/ METADATA_CONVENTION that would be a URL to a spec defining
standardized metadata (similar to the Conventions item of the netCDF CF
spec)

Regarding your need for start/end date times, I can already see an
ambiguity: for some use cases, it could be understood as the start/end
of acquisition of the scene, and for others (like weather forecast like
you pointed in the initial TIFF discussion), or the start/end of
validity of the information.

Even

Le 13/05/2022 à 01:35, Simon (Vsevolod) Ilyushchenko a écrit :
>* (Reposting from the tiff list on Even's suggestion)
*>>* Hi,
*>>* I work on the Google Earth Engine team. Our users are asking about a
*>* standard way to set start/end time on geotiffs exported from Earth
*>* Engine. I know about TIFFTAG_DATETIME, but it has no timezone. In any
*>* case, we'd like to use two different time tags for start and end.
*>>* What would be the most standards-compliant way of setting datetimes?
*>>* Thanks,
*>* Simon
*>>* _______________________________________________
*>* gdal-dev mailing list
*>* gdal-dev at lists.osgeo.org
<https://lists.osgeo.org/mailman/listinfo/gdal-dev>
*>* https://lists.osgeo.org/mailman/listinfo/gdal-dev
<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/20220513/92b52d30/attachment-0001.htm>


More information about the gdal-dev mailing list