<div dir="ltr">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,<div><br></div><div>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.</div><div><br></div><div>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, <a href="https://climatedataguide.ucar.edu/climate-data">climatologies</a> , 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.</div><div><br></div><div>Best,</div><div>Simon</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 13, 2022 at 6:49 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Simon,<br>
<br>
metadata is a tricky subject. To my knowledge, up to know most data <br>
producers of GeoTIFF files have used minimalist embedded metadata in the <br>
TIFF file itself (mostly using the ImageDescription, Copyright field), <br>
but rather using text or xml side car files to provide their own <br>
metadata model. See <br>
<a href="https://github.com/OSGeo/gdal/tree/master/gcore/mdreader" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/tree/master/gcore/mdreader</a> for a number of <br>
metadata importers. Those metadata importers expose the "raw" metadata <br>
from the side car files, but also try to gather and expose a very <br>
minimum set of information in a IMAGERY metadata domain: <br>
<a href="https://gdal.org/user/raster_data_model.html#imagery-domain-remote-sensing" rel="noreferrer" target="_blank">https://gdal.org/user/raster_data_model.html#imagery-domain-remote-sensing</a><br>
<br>
The TIFF tag mechanism makes it impractical to add "arbitary" metadata <br>
keys beyond what the baseline TIFF spec defines. So an option is to use <br>
a generic "container" like the GDAL_METADATA tag. Other options could be <br>
the GEO_METADATA one <br>
(<a href="https://www.awaresystems.be/imaging/tiff/tifftags/geo_metadata.html" rel="noreferrer" target="_blank">https://www.awaresystems.be/imaging/tiff/tifftags/geo_metadata.html</a> <br>
using a full ISO metadata model). Someone on the TIFF mailing list also <br>
mentioned the possibility of using XMP <br>
(<a href="https://www.awaresystems.be/imaging/tiff/tifftags/xmp.html" rel="noreferrer" target="_blank">https://www.awaresystems.be/imaging/tiff/tifftags/xmp.html</a>). From a <br>
pure GDAL perspective, the GDAL_METADATA one is the most straightforward <br>
as this is what will be always reported by a gdalinfo dump for example.<br>
<br>
I feel an initiative gathering a representative set of GeoTIFF <br>
geospatial products would make sense to define standardized metadata (to <br>
start with decide which existing TIFF tag should be the holder of the <br>
metadata, and then standardize metadata items) would make sense with COG <br>
growing adoption (possibly inspired by what STAC provides), rather than <br>
pushing quickly something for ad-hoc needs. Not sure which forum would <br>
be the best for that. Probably some dedicated github repository.<br>
<br>
I'd see a first metadata item that would make sense, a METADATA_PROFILE <br>
/ METADATA_CONVENTION that would be a URL to a spec defining <br>
standardized metadata (similar to the Conventions item of the netCDF CF <br>
spec)<br>
<br>
Regarding your need for start/end date times, I can already see an <br>
ambiguity: for some use cases, it could be understood as the start/end <br>
of acquisition of the scene, and for others (like weather forecast like <br>
you pointed in the initial TIFF discussion), or the start/end of <br>
validity of the information.<br>
<br>
Even<br>
<br>
Le 13/05/2022 à 01:35, Simon (Vsevolod) Ilyushchenko a écrit :<br>
> (Reposting from the tiff list on Even's suggestion)<br>
><br>
> Hi,<br>
><br>
> I work on the Google Earth Engine team. Our users are asking about a <br>
> standard way to set start/end time on geotiffs exported from Earth <br>
> Engine. I know about TIFFTAG_DATETIME, but it has no timezone. In any <br>
> case, we'd like to use two different time tags for start and end.<br>
><br>
> What would be the most standards-compliant way of setting datetimes?<br>
><br>
> Thanks,<br>
> Simon<br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
</blockquote></div>