items vs. a type name - From presentations at TC

[ogc-leedahl]

Looking at other Open API proposed schemes from the TC, it became clear that the scheme of things is {base url}/collections/{collection id}/{type}/{type id}. Where types are tiles, jobs, etc. However, WFS uses items which doesn't lead to any kind of distinction API type definition. Why are we using items and not features? It would be easier to classify the type of collection that it is. For a component point of view, couldn't we have a collection that has features, tiles and jobs in the collection. For example, I have a process that creates features and a map. Why can't I host the features and the map in the same collection as the process. Then I could have https://www.myapp.com/collections/products/(job | feature | tile) where products is my collection id that represents a process for creating products from product requirements via a job to create a set of features and maps.

[cportele]

The use of "items" is intentional since "features" is a term that mainly GIS developers will understand. For most developers, "feature" has a different meaning. And "items" is a natural term for the entities in a collection, which is why we ended up with what we have today.

In extensions like STAC (SpatioTemporal Asset Catalog) I think that "items" is also a more natural term for most users of the API.

In the Spatial Data on the Web Best practices we generally avoid the term "feature", too. The terminology is discussed in a separate section.

[leedahl]

Then is it you expression that a WMTS standard should be collections/"name"/item/"id" as well and the same for WPS. Thus there is no distinction between what type of collection we are dealing with?

[cportele]

No, in the ISO/OGC abstract specifications (see e.g. ISO 19101-1 and ISO 19109), a dataset consists of features. That is why the "items" refers to features as the items in the collection(s) are features. If you publish the data of the dataset in a different partitioning, e.g., tiles, you will use a different path as the tiles are separate resources with a different character. I.e., for the same collection

• .../collections/buildings/items/1 will return the building feature with id "1"
• .../collections/buildings/tiles/GoogleMapsCompatible/13/4255/2781 will return a tile with the features in that tile

In both cases, the requested media type will determine the representation of the resource in the response, depending on the media types a server supports for each resource.

[ogc-leedahl]

I still feel that item is too generic. We are a geospatial organization. I would pick some geospatial term. Perhaps geometry or something else. At the very least I would not call the standard feature and the type item. The name should reflect the type. Thus under the current type this is a Web Item API which I think is more confusing internationally then feature is. Just my two cents.

[cportele]

15-April-2019 Teleconference: Keep "items" as it seems well accepted, also in the OGC API Common discussions. Add a discussion about the term "feature" early in the draft spec (see also #189).

[cportele]

resolved by #208