Add track and frame field in the EO/SAR extension

[p3dr0]

These fields are defined as

• track (or path or wrsLongitudeGrid) : string : A string providing the coordinate of the product on the across track (east/west) axis of the reference system used.
• frame (or row or wrsLatitudeGrid) : string : A string providing the coordinate of product along track (north/south) axis of the reference system used.

These are quite generically used in satellites following a polar or sun-synchronous orbit (ENVISAT, LANDSAT, Sentinel-1) so assigning them to a sensor specific extension would be quite cumbersome because we would need to replicate it across several ones.

Another possibility would be to create an extension for satellite following a polar orbit.

[cholmes]

In #350 @matthewhanson said:

track and frame don't apply to sensors not using a reference system, such as taskable satellites. I think it probably doesn't belong in the EO extension, but instead as sensor specific metadata, e.g., "landsat:wrs_path", "landsat:wrs_row".

I have been thinking of the EO extension as a set of fields that can be used, but don't have to be things that every single sensor will use. Constellation is one that doesn't apply to every satellite.

I definitely don't think having each specific sensor make an extension for track and frame makes sense. If we don't want it in the EO extension directly then a little extension for satellites following a polar orbit could make a ton of sense. And if it gets wide usages we can evolve it to be a direct part of the EO spec.

[matthewhanson]

Well that is certainly true @cholmes, they don't have to be used, and there are quite a few sensors that use some sort of x,y tiling for publication, so maybe it would be a good addition.

@p3dr0 I'm not sure track, frame, row, or path are all generic enough though. Sentinel retiles their swaths into multiple scenes across track, Landsat has been distributed using other tiling schemes not path/row (WELD, the initial Landsat ARD beta). MODIS uses a horizontal/vertical tile grid.

What about something like "eo:xtile" and "eo:ytile". A provider could then provide a link to the GeoJSON of the reference grid if desired. Maybe 'tile' isn't a great term either though, to avoid confusion with web tiles.

[m-mohr]

Generally seems to be a good idea, now we are bikeshedding a name. ;-)
Maybe eo:grid: [x,y] or similar? Or eo:row and eo:column?

[fredliporace]

I'd suggest a recommendation to keep the tiling scheme consistent within a collection, not mixing for instance Landsat WRS and WELD tiling. The use of distinct tiling schemes is one drive to organize the data in distinct collections.

About the name, 'tile' reminds me of no, or a very small, overlapping. This is certainly not the case for WRS and MGRS, which are defined as "Reference Systems". I'd go then with row/column or grid.

[matthewhanson]

I like "eo:row" and "eo:column" the best

[m-mohr]

STAC sprint result: We don't add this to eo or sar extension as the satellites work quite differently with this concept or don't have it at all. So it's up to users to use more specific extensions such as a specific one for landsat etc. to get row and column.