tree structure vs features api

[pvgenuchten]

I may have missed this aspect in the preparations of oapi's...

Oapi-cov uses a tree structure of /collection/coverages/... where oapi-ft uses a structure of /collection/items (which are the features).

At the pyGeoApi group we were discussing how a software product can support both oapi-cov as well as oapi-ft. It should either have to identify the relevant service-type by a unique string, or allow a mixture of features and coverages in a single collection.

Some questions that came to my mind...

• Shouldn't a coverage be considered as a collection of grid-rows (like features in a ft collection)?
• Is a coverage-series (collection) a very common use case in the coverage domain? I guess so, because satellites produce many observation on a single flight.
• Do you envision an api supporting both features as well as coverages in a single collection?

[pebau]

I may have missed this aspect in the preparations of oapi's...

your thoughts are more than welcome! :)

Oapi-cov uses a tree structure of /collection/coverages/... where oapi-ft uses a structure of /collection/items (which are the features).

no problem, an "item" in feature world corresponds to a coverage in coverage world :) it is just that vectors and rasters have some intrinsic differences, so the operations will be different (like scaling = reducing resolution of a coverage, which does not have a direct counterpart in feature world).
However, I am not sure whether I should have a headache since I seem to have heard that WFS now is starting to define coverages.

At the pyGeoApi group we were discussing how a software product can support both oapi-cov as well as oapi-ft. It should either have to identify the relevant service-type by a unique string, or allow a mixture of features and coverages in a single collection.

hm, oapi-cov and oapi-ft already distinguish, don't they?
For this first cut IMHO mixed collections are too far reaching, we have to finish some homeworks first. For example, features and collections have different ways of expressing subsetting, it's as basic as that currently.

Some questions that came to my mind...

* Shouldn't a coverage be considered as a collection of grid-rows (like features in a ft collection)?

no. In a multi-dimensional grid there is no preference, all axes are at the same level. No row collection, column collection, etc. - would make life terribly complicated and misrepresent reality.

* Is a coverage-series (collection) a very common use case in the coverage domain? I guess so, because satellites produce many observation on a single flight.

yes, that is not uncommon. In the extreme case: stereo image = a pair of images of same resolution etc.
Of course one could also think of (user-defined) nested collections, but we are just about to establish the very first cut, so concentrating on the basics.

* Do you envision an api supporting both features as well as coverages in a single collection?

definitely of interest, use case: GMLJP2, GeoPackage, etc which all like to combine vector, raster, meta data. Already 2+ years ago I presented the idea of an overarching query language to OGC, but OAB did not enjoy the idea.

[tomkralidis]

(it's been awhile since the this issue was opened, so some things may have changed over time as the OGC API efforts become more clear/aligned)

As I understand it, /collections/{collectionId} can provide data in a variety of approaches.

• /collections/{collectionId}/items: features
• /collections/{collectionId}/coverage: coverages/CIS
• /collections/{collectionId}/tiles: tiles

In addition, the EDR API also provides Query Types which follow this design pattern.

So a given software implementation can provide a collection accordingly (depending on the native data type and mechanism of representing same).

[pomakis]

There's also /collections/{collectionId}/map for requesting map layers. And in Testbed 15 we were experimenting (rather successfully IMO) with a /collections/{collectionId}/images set of endpoints for managing the set of source images of a coverage.

[Schpidi]

20200902: Coverages SWG call: We believe this has been overcome by events e.g. opengeospatial/ogcapi-common#140 Please reopen if you think this is still relevant.