Time in Historical Locations

[manuGil]

The entity 'HistoricalLocations' automatically stores system time. According with requirement 8 of the standard, when a new 'Location' is created a historical location shall be automatically created. This great. However, it offers some disadvantages:

1. The time assigned to the to a historical location is a system time (or database time). This generates inconsistencies between the time a new location is registered into the API and the 'actual' time in which the change of location was reported to the API. Specially important in networks with a big latency.
2. Drawbacks on handling moving Things (sensors attached to objects that change location very fast: cars, airplanes, people, etc). Again, the latency of the network may add errors between the actual location of a Thing and the time a request reaches the API. More importantly, this means that the 'resulTime' in the Observation entity won't match the 'time' in HistoricalLocation. As a result, one can request the 'result' of an observation for time 'X', but one cannot be sure of what was the precise location of the Thing (producing the observation) at that time, and vice-versa.

My recommendation: To modify the entity model and the requirements around locations and historical locations to avoid these disadvantages.
A previous issue already suggested to allow updates to the HistoricalLocations entity. In my opinion, for the case of moving Things (objects), location of a Thing is nothing more than an observation produce by a sensor (e.g. GPS), and it should be treated as that. Whichever changes will be more suitable, the standard should include functionality to answer the question: What was the Location of a Thing when an Observation was made? in which Location is a variable.

[taniakhalafbeigi]

In order to answer the question 'What was the Location of a Thing when an Observation was made?' the best way is to use FeatureOfInterest instead of Thing's Location. In that case each Observation request has embedded FeatureOfInterest in MQTT or HTTP request and we don't have the timing issue anymore.

However, for some cases HistoricalLocation is needed as I discussed in issue #33 . Other possible use case that we need to change time in HistoricalLocation is when we want to load some historical data into SensorThings.

The specification supports update for HistoricalLocation and that could be one way. Using deep insert for HistoricalLocation inside Location creation request can be another way to specify the time. But, this needs minor change in the spec. We can discuss it in next SensorThings meeting.

[hylkevds]

Maybe a solution would be to add something like this to the spec:

When a user directly adds new HistoricalLocation, and the time of this new HistoricalLocation is later than the latest HistoricalLocation for the Thing, then the Locations of the Thing are changed to the Locations of this new HistoricalLocation.

This allows both the current, automatic generation of HistoricalLocations with the current time, by changing the Locations of a Thing, and also changing the Locations of a Thing, with a time other than the current time.

[image357]

I am currently working on a project that uses Sensorthings in order to store sensor data. A common occurence is that some data is collected offline with very specialized instruments or that some sensors lose connectivity for a short period of time. For these instances we would need an easy way to use our own timestamps in the HistoricalLocation (HL) entity. I agree with @hylkevds proposal to update the Thing Location when a more recent HL is linked to the Thing entity.

[liangsteve]

issue assigned to me, in case we miss this issue in Sep TC.

[hylkevds]

Fixed with the publication of Sensing v1.1.