Remove STAC extension fields from the spec

[m-mohr]

So now that we have properties and other_properties it doesn't make much sense any longer to describe the STAC fields from the extensions (e.g. eo, sar) in the openEO API itself. Implementers must be encouraged to find suitable fields theirself otherwise the spec would get very long as we would need to define all fields twice, once as a single value, once a a summary for other_properties. Currently, we use a mixed approach, which is not very elegant nor intuitive.

Edit: Instead we should link to https://open-eo.github.io/openeo-api/v/0.4.1/collections/ and get more into detail there. For example, which fields fit well in which part of the properties etc.

[huhabla]

Can you please explain why the STAC "properties" and "other_properties" are required in the full metadata for a specific dataset schema? IMHO these parameters should be optional and not required. We already have an extent parameter in which we must specify the spatial and temporal extents. What about raster images or vector data that do not have a temporal extent?

[m-mohr]

@huhabla First of all, properties and other_properties will be merged to summaries in the next version (with the content being similar to other_properties). So there's just one field left. That's due to changes in STAC, which make it easier for us to describe our collections. It will still be required as we require the field cube:dimensions inside of the summaries as these information are fundamental to use the openEO processes. Without knowing them, the collections returned as data cubes by load_collection can't be processed very well. For the same reason, the properties and other_properties are required, although one of them can be empty, I think.

Indeed, cube:dimensions and extent duplicate some information, but I can't remove extent as this is required information in STAC and WFS3, so we would loose compatibility with them. I don't this it is a big deal to output the information in both places.

What kind of data should that be that has no temporal extent? Basically all data have at least an implicit temporal extent, for example boundaries have a date range it is valid for. In any case, if you have data that has no temporal extent, I'd suggest to set both ends to being open, i.e. temporal: [null, null]. That's discouraged by the specification (at the moment, maybe remove that restriction?), but not validated at any point. This way you indicate your data is always valid.

[m-mohr]

Oh, and to clarify further, I think you misunderstood the extent that is in the "second level" of other_properties. This extent is for additional metadata, for example something like

{
  "other_properties: {
    "eo:cloud_cover": {
      "extent": [0, 33]
    }
  }
}

It's not the best example, but should work for clarification...

[huhabla]

Thanks for the answer,

What kind of data should that be that has no temporal extent? Basically all data have at least an implicit temporal extent, for example boundaries have a date range it is valid for.

Elevation data for example does not have a temporal extent and so are many raster and vector data that is located in the databases of common geoinformation systems. There are plenty of GeoTiff images and vector files that do not have an assigned temporal extent, since this was not possible to add in the existing GIS. Hence, theoretically all geographical data has a temporal relation in reality, but most GIS users did not set the extent to their data since it was not supported by their GIS.

[m-mohr]

Elevation data also changes over time so should have a temporal extent. Without knowing the temporal extent the data may not be very useful at all. Not sure whether a data provider should add data that is lacking such important metadata. Anyway, the workaround from above should work fine and we could check removing the restriction from the written spec that data can't have both values set to null.