Open dpmcgarry opened 6 years ago
How to use SensorThings API for moving objects depends on the use case. Here are the two use cases I can think of:
For the second scenario it may worth that we discuss adding MQTT create for Location. We can discuss it in the next meeting.
How the server handles large number of HistoricalLocations (and other entities in general) is up to the implementation. It is out of the scope of specification and there is no specific architecture defined there. Sampling and/or expiration mechanism can be two approaches that can be implemented by the server as extra features, while the server is still compliant to SensorThings.
Thanks for your comment. In our case we are tracking moving "things" e.g. vehicles / persons which may or may not have an observation that is a feature of interest (unless the location of that "thing" could be the feature of interest), which per your explanation does not seem to be the correct approach. It would be a nice enhancement to support thing location update over MQTT for the future.
Has there been any updates on the moving sensors since this discussion? We also have a case where a single sensor would generate probably thousands of timestamp - location - observation -combinations on daily basis and would need to figure out a way to do searches in a way that a heatmap can be generated of the observed area.
Could you give us a description of your use-case? Since the Tasking part is almost done we'll be looking at updating the Sensing specification soon. Having a good description of a use-case, including where the use-case does not fit the current spec, would be very helpful.
In our case the one use case is an AQ sensor network based on up to 100 sensors mounted on top of the tram, running 18 hours a day and transmitting observations at the rate of 1 Hz. It does not necessary need to be based on MQTT but I understood from the previous messages that one option would be adding location support for MQTT. The bandwidth available is quite low so efficiency would be a good thing.
Also, as a best practise, is there anything coming from the other initiatives such as the UAS that would affect on interoperability? The use of HistoricalLocations would probably require an implementation of the server that could scale elastically for the search functions. We can experiment a bit but should start to operate within 2-3 months.
I think your use case is part (1) of my answer which you can use embedded FeatureOfInterest in your Observation request. Please correct me if there is a part that I haven't understood well.
One other alternate solution for part (2) of my answer, is using Observation for keeping track of the Location. In this case, Location is presumably the GPS sensor reading which is actually an Observation. This is only good if the purpose is just to keep the trajectory, because the geospatial functions may not work on Observations.
For a combination of trajectory and sensor readings, I think we can discuss MQTT creation of Locations and the issue will be resolved.
Building on what was documented for #29 we are a bit confused about tracking a moving object. Is that updating a thing's location or would it be updating a feature of interest?
If it is updating the thing's location there is the issue pointed out of not being able to do that over MQTT. Further since locations are referenced by an ID (both in feature of interest and location) how does this coincide with the location concept? In the STAPI example locations were for pre-defined places with a name and description, however for a moving object this doesn't make a lot of sense.
In addition there is the challenge of a frequently updated position creating a TON of both locations and historical locations that would need to be tracked.