Closed manuGil closed 2 years ago
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.
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.
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.
issue assigned to me, in case we miss this issue in Sep TC.
Fixed with the publication of Sensing v1.1.
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:
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.