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

Simon (Vsevolod) Ilyushchenko simonf at simonf.com
Fri May 13 11:33:56 PDT 2022


Ivan: I thnk the problem with using filenames is that it creates a
different de facto standard that doesn't necessarily suit everyone - eg,
what if the data have hours, minutes, and seconds? Also, it means that
moving files out of the directory loses temporal metadata,

Even: I like your suggestions. Let me try to get someone from the COG and
TIFF communities involved, and then we can start discussing the details.

Regarding ambiguity about start/end times - we did not find this to be a
problem so far because each dataset falls either into one or the other
category. There is also a third category, climatologies
<https://climatedataguide.ucar.edu/climate-data> , when the data represent
averages over multiple years - eg, the January data are not for any
specific January, but for averages of all Januaries between 1960 and 1990.
But this is a fairly niche case.

Best,
Simon

On Fri, May 13, 2022 at 6:49 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> 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
>
> --
> 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/41ab5153/attachment.htm>


More information about the gdal-dev mailing list