Request for explicit non-spatial collections

[RoelvandenBerg]

OGC API Features (or OGC API's in general) lack a way to clearly, explicitly, identify related collections that do not hold geodata. We would like the standard to provide a generic way to include collections that relate to OGC API Features collections (with geodata). This has been discussed to some extent in this thread, for example here (the fact users might want multiple sorts of data), here (what geo things are: features with or without geometries) and here (the wish for streamlined API's).

I presented this issue request in an OGC Open Standards Code sprint a month ago.

Note 1: this request is explicitly focussed on datasets and its distributions that are (mainly) geodata (distributions). We focus on clients and implementations that will implement the spatial aspect of a dataset and provide a generic way to also optionally implement the related non-spatial collection. The goal is to make the non-spatial collections explicit so clients may implement them or ignore them appropriately.
We do not propose a generic object API that also is useful for geo.

Note 2: We recognize that it is already possible to serve non-spatial data in collection form, but we advocate to do this more explicitly.

This last point means we need to justify:

• why it is warranted or even desirable to have a standardized way to serve non-spatial related collections in a standard meant for distributing geodata
• make clear why and how a more explicit way is warranted
• make clear why this should be added to the standard

Examples - Why serve non-spatial data in an OGC API?

Why serve non-spatial collections in an API for geodata to begin with? One important reason is for related data that gives context to the geometries and belongs to the same dataset. See also the aforementioned comment. OGC API's are meant for geodata as a geodata distribution. So whereever possible it would be a best practice to denormalize data on feature level or "flatten" them. So to add attributes of non-spatial data to features wherever possible. This way the spatial viewpoint is best served. Which allows spatial clients to act on the data. There are however examples where denormalization creates problems.
Some datasets do not only contain geodata but also contain related data where this related data cannot be added to the existing geofeatures.
Where non-spatial is related in a 1:1 fashion can be added to the geo features themselves. This has preference above adding this data as non-spatial data. With OAS based OGC API's it is possible to combine different aspects of a dataset in one API. Since OGC API's are geo API's these API's main focus must be geo.

I will give three examples, but more can be thought of:

Spatial planning data
Spatial planning combines geographic and legal / administrative data. An administrative boundary can be related to many instances of rules. This makes a dataset that is fully denormalized on geo hard to use. This leads to loads of duplicate polygon features. It is possible to model the data in a way that is useful from a spatial viewpoint, e.g. by using existing categorizations of the rules and other common attributes. Still the rules or administrative data with a 1:n (feature:administrative data) relation is useful to add to the API. This way a user of such an API can relate the specific rules to a location.

Monitoring nets or monitoring research
Monitoring data can be expressed as Sensorthings API's. Some datasets are aggregates of sensordata, but do include information on the monitoring nets with aggregate data, which makes a sensorthings API less appropriate. In some cases monitoring nets make use of different permutations of the same set of measuring stations. And in some cases a dataset does not (only) contain the monitoring data (i.e. the timeseries), but also the derived data and/or the documents that describe this. Monitoring nets and research comes and goes. So to know where and when monitoring takes place (the spatiotemporal aspect - why we want to use an OGC API) is useful. Additionally it is useful to know more about this monitoring and what kind of research reports are made based on these locations or even to be directed to these reports through links. This related data tends to have a 1:n relation to features.

Statistical data
Statistical data is an aggregate that in many cases can relate to a in many cases changing geometry. For example yearly statistics for administrative boundaries. This can be expressed through redundant geometries or through related collections. When to do one or the other fully depends on the level of aggregation. But at some point it becomes useful to add the data in a seperate collection.

The Problem - why more explicit

The OGC API Features provides us with a couple of ways to serve non-spatial data.

• Serving features with null Geometries
• Leaving the spatial extent of a collection null
• Limiting certain collections to only serve JSON instead of GeoJSON.

All these methods do partially fulfill the need to serve non-spatial data. But are implicit, doing the above might lead to (somewhat) confusing or hard(er) to use API's. An OGC API Features collection that has null geometries will return all features when accessed by a GIS client by design even though a GIS client might not be interested in these features. Or leads to lots of unwanted downloads (every feature needs to be checked) before the situation is clear. This becomes problematic when a non-spatial collection is very large.

A non-spatial collection can still have a spatial extent without having geometries in a particular collection. Furthermore the way I read the spec it states collection extents are optional see halfway the core overview:

An optional extent that can be used to provide an indication of the spatial and temporal extent of the collection - typically derived from the data;

Forcing this to be used, means one must either know this about, or derive this information from the data, which tends to be harder than knowing whether a collection is not spatial. Either way it this means a generic client cannot reliably infer wether no extent is given because of the collection not being spatial or otherwise. So this is not a complete solution. Without explicitly stating a collection as non-spatial it becomes impossible to differentiate between (partially) sparse geocollections (for example a collection that for whatever reason returns records with NULL geometries for the first page) without introspection of said collection.

Both of the latter points make it hard or impossible to create a generic client implementation on non-spatial collections. A client might want to do so, since these add value to the spatial collections.

In short: using implicit ways of serving non-spatial data in collections means the usage of the API must rely on the assumptions of the user or client about the collection using fields or attributes that serve another purpose.

The proposed solution

Make the fact that a collection is non-spatial explicit through an itemType e.g. non-spatial. In an earlier proposal I proposed attribute analog to the geopackages standard that differentiates between amongst others feature and attribute tables. This clearly communicates the fact that a collection as a whole does not contain spatial data. And makes it possible for GIS clients to implement a solution for non-spatial collections. For example QGIS nicely interfaces with Geopackage attribute tables, which is possible because this is made explicit.

Why add this to an or this OGC API standard

For one to create a standard solution that makes it possible for clients to built on. At this moment it is possible to add our own itemType. The problem with that solution however is that clients cannot anticipate on such a custom itemType which defeats the purpose. Furthermore I expect this proposal to have little negative impact; since the feature itemType is the default and therefore left out of most implementations for OGC API Features collections. At last for that same reason it is possible to add to API's with collections that currently use the more implicit solutions without breaking changes.

[cportele]

Meeting 2025-12-01:

• We agree it would be helpful to add text to the revision v1.1 to Part 1.
• itemType should remain feature also for cases where features in a collection have no geometries. It would be more appropriate to add a new flag in the collection to indicate that the features in the collection have no new geometries. This keeps compatibility with existing API that use feature for those cases.
• Adding the flag would be recommended.

[rouault]

• Adding the flag would be recommended.

rather than a flag, a "geometryType" key could be useful for some clients, with values like "none", "any", "Point", "LineString", "Polygon", "MultiPoint", "MultiLineString", "MultiPolygon", "GeometryCollection", and possibly an array of them if there are mixed

[cportele]

That approach would work for me, too.