Are non-spatial collections supported?

[jratike80]

The GeoPackage standard allows non-spatial tables which hold only attribute data:

Non-spatial attribute data are sets (or tuples or rows) of observations that may not have an explicit geometry property. In GeoPackage, this data is stored in user-defined attribute tables. These tables may contain properties such as an ID or geo-locatable address that allow them to be relationally linkable to rows in other attribute, feature or tile tables

Does OGC API Features support non-spatial collections? If they are supported, should the output be GeoJSON with null as geometry?

Slightly related issue https://github.com/opengeospatial/ogcapi-features/issues/16 but in that the collection is supposed to have a geometry attribute, but user just do not want to get it.

[cportele]

Yes, features that do not have a geometry are valid. In GeoJSON the geometry member is set to null for these features.

If no feature in a collection has a geometry, the collection will not have a spatial extent (path #/extent/spatial):

The member spatial only needs to be provided in the extent object, if features in the feature collection have spatial properties.

[jratike80]

Thanks, that's what I thought but I did not find it explicitly mentioned in the standard text. And because all of the features are not associated with spatial geometries then any bbox query will return the whole collection.

The bbox parameter SHALL match all features in the collection that are not associated with a spatial geometry, too.

[cportele]

Yes. This was also recently discussed in the context of OGC API Records, which uses the building blocks from OGC API Features. See https://github.com/opengeospatial/ogcapi-records/issues/175.

[cportele]

The question has been answered.