Moving Features

[keewis]

A few months ago I, with help from several community members, started creating a STAC catalog for the CMEMS marine in-situ TAC (see this dashboard if you want to get a feel of the data), which for long-term storage provides aggregates over multiple time intervals and for different kinds of sensor types (the data provider calls these "platform types"). The captured data itself can range from single measurements over time (1-dimensional) to area measurements over time (3D).

In the following, I'll use this collection of datasets as an example, but I imagine there's lots of other use cases.

Most of these are more-or-less stationary, which means that the spatial extent does not change over time or their movement is negligible. An example for the former might be tide gauges (ignoring solid earth movement), an example for the latter is what the catalog calls "moorings": buoys that are anchored and drift with the currents / winds as far as the chain allows, which usually is not much more than ±50 m (but this depends on the tide and the length of the chain). Thus, with space and time being approximately orthogonal, these can easily be cataloged using STAC, and the search result usually is helpful.

However, there are also some categories that even within a month cross significant parts of the earth. A more extreme example for this is the thermosalinometers, which are ship-mounted sensors that measure ocean temperature and salinity. Searching catalogs that treat space and time as orthogonal for these "platform types" will usually not be useful, as the returned items might not actually contain data for the query.

To work around this, I wonder how easy it would be to create an extension that replaces the GeoJSON in the base spec with JSON-encoded OGC moving features? Naively, I'd imagine that for static catalogs this would be easy (just add a appropriately named datetimes property), but for dynamic catalogs this might require changes to the backends?

cc @m-mohr who recommended I propose something during the STAC BoF at the BiDS 2023 conference this week (not sure if this is what you meant, though)

[m-mohr]

I was just thinking about an open discussion how something like this could work, I had no specific action in mind. Opening an issue here is a good start.

One idea could be that we create an extension to STAC Items that that adds the additional fields missing from STAC Items. In principle a Feature looks (at first look) very similar to GeoJSON anyway: https://docs.ogc.org/is/19-045r3/19-045r3.html#mfeature

[keewis]

it took me a while, but I've started drafting a STAC extension: moving-features (work-in-progress, in particular the json schema does not exist yet). Since I don't have a use case for Prism objects, the more general object, I've decided to focus on Trajectory objects (moving points) instead.

Trajectory objects are GeoJSON Feature objects with a LineString geometry with at least two nodes and an additional property called datetimes that contains one timestamp for each node of the LineString, in monotonic increasing order.

In the future, I'm hoping to also be able to define behavior for STAC API backends, but for now I'm filtering the result of a standard search using the additional metadata from this extension.