Have better way to specify a time period in GeoTIFF

[joanma747]

On Tue, May 31, 2022 at 6:01 AM Simon (Vsevolod) Ilyushchenko <simonf@google.com> wrote:
Hi Joan,

Frank Warmerdam suggested that I contact you. I'm the data ingestion lead on the Google Earth Engine team.

Our users have been asking for a standard to encode image start/end times in geotiffs, and I'm wondering what the best way to support that would be. 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.

Frank said that you and Charles Heazel are co-chairs for the GeoTIFF SWG - is this something you are interested in discussing?

Thanks,
Simon

[simonff]

Hi - this was requested by me. I'm also in contact with GDAL and COG (Cloud-optimized geotiff) folks about this.

[koimic]

Hello folks,

Our users have been asking for a standard to encode image start/end times in geotiffs, and I'm wondering what the best way to support that would be.

Recently we had exactly same requirements when we set up an OGC WMS (with time dimension) server, and want to see standardized way established which will be widely accepted by various implementations.

This WMS server is currently working at following to provide images derived from JAXA's satellite data.

https://eodashboard.org/explore?poi=World-E10e

Behind this, we prepared GeoTIFF files which have "GEO_METADATA" tag with ISO XML metadata as their values. They can be recognized by Apache SIS.

For example, "2022-01-16" data ("2022-01-16T11:59:30.000Z" in GetCapabilities) has "2022-01-01T00:00:00Z" as "gml:beginPosition" and "2022-01-31T23:59:00Z" as "gml:endPosition". (*1)

While preparing this service, we also searched standardized and widely accepted way to specify image start/end times in GeoTIFFs, but could not find obvious one. So we discussed about appropriate way with one of Apache SIS PMC members. GEO_METADATA and GDAL_METADATA were two candidates, and we finally selected "GEO_METADATA" as we thought it would be most standardized way. (The downside was, as you can see, it seemed to be a little bit complicated way to specify two ISO 8601 datetime values)

(*1) quotes from gdalinfo:

...
Metadata:
...
  GEO_METADATA=<?xml version='1.0' encoding='utf8'?>
<gmd:MD_Metadata xmlns:gmd=["http://www.isotc211.org/2005/gmd"](http://www.isotc211.org/2005/gmd) xmlns:gml=["http://www.opengis.net/gml/3.2"](http://www.opengis.net/gml/3.2) xmlns:xsi=["http://www.w3.org/2001/XMLSchema-instance"](http://www.w3.org/2001/XMLSchema-instance) xsi:schemaLocation=["http://www.isotc211.org/2005/gmd https://www.isotc211.org/2005/gmd/gmd.xsd http://www.isotc211.org/2005/gmx https://www.isotc211.org/2005/gmx/gmx.xsd"](http://www.isotc211.org/2005/gmdhttps://www.isotc211.org/2005/gmd/gmd.xsdhttp://www.isotc211.org/2005/gmxhttps://www.isotc211.org/2005/gmx/gmx.xsd)>
   <gmd:identificationInfo>
     <gmd:MD_DataIdentification>
       <gmd:extent>
         <gmd:EX_Extent>
           <gmd:temporalElement>
             <gmd:EX_TemporalExtent>
               <gmd:extent>
                 <gml:TimePeriod>
                   <gml:description>Acquisition period</gml:description>
                   <gml:beginPosition>2022-01-01T00:00:00Z</gml:beginPosition>
                   <gml:endPosition>2022-01-31T23:59:00Z</gml:endPosition>
                 </gml:TimePeriod>
               </gmd:extent>
             </gmd:EX_TemporalExtent>
           </gmd:temporalElement>
         </gmd:EX_Extent>
       </gmd:extent>
     </gmd:MD_DataIdentification>
   </gmd:identificationInfo>
</gmd:MD_Metadata>
...

[joanma747]

The TIFF Tag DateTime is documented here: https://www.awaresystems.be/imaging/tiff/tifftags/datetime.html. As said before, timezone is unclear and it only allows for one instant.

The solution proposed by @koimic seems correct and generalizable to other metadata. https://www.awaresystems.be/imaging/tiff/tifftags/geo_metadata.html

If the previous solution seem too verbose or too much XML, from the GeoTIFF group we could define a new GeoTIFF key (type STRING) to encode a time interval if needed. We could use the ISO8601 used in the annex D of the WMS 1.3. Something like "2022-01-01T00:00:00Z/2022-01-31T23:59:00Z" will work.

It is up to the group to decide if this is necessary in a revised GeoTIFF standard.

[simonff]

I think koimic's solution is indeed too verbose for a simple datetime field, though maybe it can be used for a secondary more complex field that needs to be more general.

The ISO8601 time interval seems fine for me. Another option is to have two separate fields - one for start and another for end date, both in ISO8601 format.

[koimic]

I think koimic's solution is indeed too verbose for a simple datetime field, though maybe it can be used for a secondary more complex field that needs to be more general.

Agreed. I think time period is worth for having standardized and dedicated fields for it.

Our solution thought to be (hopefully acceptable) workaround until definition of them. And, for example, in case someone wants to specify time period of something which can not be inferred implicitly in GeoTIFF, it might be useful even after definition of time period fields. (In our case, because "Acquisition period" seem to be obvious, we will be able to switch to them after their definition and implementation) .

[joanma747]

depends on #112 and we will wait to solve that one first