Sentinel-2 data via Coverages

[m-mohr]

What to do if I want to expose Sentinel-2 via Coverages for which the storageCrs would be multiple UTM zones?

[jerstlouis]

@m-mohr A coverage needs to be in a single storageCrs, so that a client can request data that combines content across those different UTM zones.

So you can either:

• A) Have a separate coverage for each UTM zone
• B) Have a single coverage supporting CRS84 output and make that the storageCrs

If you choose to go with B, then you can also implement Scenes where the storageCrs of /collections/{collectionId}/scenes/{sceneId}/coverage can be in the native UTM zone of that particular scene.

Note that the requirement about CRS84 is only for the description of the extent of the collection if it contains Earth data, and the storageCrs can differ. It is not mandatory to have CRS84 in the list of supported output CRS either (the crs array property at the top level of the collection), but it greatly helps with interoperability.

[m-mohr]

storageCrs says it describes the native CRS, but if I choose B it's not the native CRS anymore once I reprocessed all on-the-fly into EPSG:4326 for example. So this is confusing to me...

A) That's not what people expect, they don't want to load data from X different collections for sure...

[jerstlouis]

@m-mohr

but if I choose B it's not the native CRS anymore once I reprocessed all on-the-fly into EPSG:4326 for example.

The definition of the "native CRS" is somewhat loser. I don't recall where we wrote that, but it is essentially the CRS in which the server can most efficiently return the data.

In the case of sentinel-2 across multiple zones, there is not a single CRS, so CRS84 is likely the "native" aka storageCrs.
And one of the main reasons for /scenes is specifically to still be able to return the true native/storage CRS, but only one scene at a time.

[m-mohr]

The definition of the "native CRS" is somewhat loser. I don't recall where we wrote that,

7.2.2. -> req. 2J: "The storageCrs property SHALL be set to the native CRS of the coverage, also corresponding to the default output CRS"

Maybe that should simply be:

"The storageCrs property SHALL be set to the default output CRS of the coverage, often the native CRS."

but it is essentially the CRS in which the server can most efficiently return the data.

Most efficiently is pretty ambiguous, but "most efficient" would probably be understood as no reprojection, so UTM zones. So from that description the storageCrs should not be CRS84.

And one of the main reasons for /scenes is specifically to still be able to return the true native/storage CRS, but only one scene at a time.

Not interested in scenes, I already have a more commonly adopted STAC API.

[jerstlouis]

Maybe that should simply be:

That could work.

So from that description the storageCrs should not be CRS84.

CRS84 would likely still be the most efficient CRS that you can request any scene and data across scenes, since there are no better choices.

Not interested in scenes, I already have a more commonly adopted STAC API.

/scenes and /scenes/{sceneId} can pretty much return exactly the same as /items and /items/{itemId} when negotiating the STAC media types for these, so that should be easy to re-reroute to your existing STAC API.
And you could include the [ogc-rel:coverage] link to /scenes/{sceneId}/coverage in the native zone.

You would also have the assets as well, but the coverage might be a more dynamic endpoint returning multiple bands and itself supporting subsetting etc., combining the bands of the assets.

The scenes could also differ from the STAC items.

For example, in sentinel-2 the granules are small tiles, so you could combine multiple source granule items into a single scene corresponding to single capture before it being tiled.

[chris-little]

@m-mohr We had a similar issue in API-EDR. Most 'native' NWP models mix the surface and vertical levels together in one structure, but this goes against the 'one CRS' principle. The meteorology communituy are recognising that separate Collections are needed to maintain the homogeneous CRSs to make the API work simply and effectively. The server side maintenance overhead is considered part of the trade-off for the downstream benefits.
In my view, the end users of a Coverage API are significantly different from EDR end users, so the extra API-Coverage complexity may be acceptable to them.
HTH.

[chris-little]

@m-mohr As for mandatory CRS84, we relaxed it in API-EDR, to support, for example, engineering coordinates, space-based, medical tomograph 3D scan, etc.

[jerstlouis]

@chris-little

engineering coordinates, space-based, medical tomograph 3D scan, etc.

These are also "relaxes" in Coverages / Common, through the clause "for data referenced to the Earth".

This whole CRS84 being needed is only about the description of the spatial extent for discovery -- there is no requirement that the Coverage (or Maps) be available in CRS84, but that is strongly recommended to facilitate interoperability (again, for data referenced to the Earth only).

[jerstlouis]

SWG 2024-11-27: Here are the actions we can take:

• Improve on https://docs.ogc.org/DRAFTS/19-087.html#_extended_collection_description_response_collectionscollectionid requirement 7.2.2 Requirement 2 J regarding what is the storageCrs
• Add a note describing the sentinel-2 / LANDSAT use case where the individual parts are likely internally stored in different native CRSs, and the storageCrs is recommended to be CRS84 as it is the easiest way to provide a global coverage sourced from all constituent granules / scenes
• The Scenes requirements class will further help with this use case to additionally provide the ability to retrieve a coverage from single parts in their true native CRS, but it was agreed to move this to a future part (Scenes API as a separate part #196)