Moving Features

[hylkevds]

Things can move, and can have HistoricalLocations.
Since in V2, the thing is better specified to be the OMS:Host, and we now have an UltimateFeatureOfInterest relation, should we make Features movable too?

Ideally somewhat light-weight, with just the geometry and time:

HistoricalFeature
time: TM_Instant
encodingType: String
feature: Geometry

Potentially related to #33

[humaidkidwai]

HistoricalLocation is useful for keeping track of the trajectory information of a Thing. When a Thing is moving, as the Feature(ofInterest) changes, would it be useful to keep track of the historical Features(ofInterest)?

Having a minimal entity is good for maintaining some additional information, but would it be as useful?

It is better (semantically and to query) to have independent Datastreams for every Feature(ofInterest) than to have one Datastream composed of a series of Observations, with only a subset linked to one Feature at a time.

[hylkevds]

Moving Features have nothing to do with moving Things. If my thing is a Bus, then each location where it takes a measurement is a Feature (a Sample) in itself. These Features don't move.

In some cases the Feature itself moves. Like a river that changes its course, or a person that is being tracked by several cameras. We don't want to model the river or the person as a Thing, since they're not the Host of the Sensor, but we may want to track their movement.

Another way to model this, is to remove the geometry from Feature, and link Feature to Location, just like Thing. That would also de-duplicate quite some data, since each Location generally has also a Feature.