Additional moving object issue

[dpmcgarry]

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.

[taniakhalafbeigi]

How to use SensorThings API for moving objects depends on the use case. Here are the two use cases I can think of:

1. The information that is valuable for the client is what Observation is happened at which Location. In other words, client always access the location data together with Observation and an independent trajectory of the Thing is not of interest. In this case the best approach is to let FeaturesOfInterest keep track of location. For that, each Observation MQTT message should have embedded FeatureOfInterest (as in deep insert). The example of this case could be Buses that are carrying air quality sensors. In that case the pure Trajectory of the bus is not the topic of interest and the air quality readings together with the recorded location is always needed.

2. Trajectory of the Thing is the topic of interest and user needs to access it separately from the Observations. In this case Location entity needs to be used. With current spec, you can only create a Location with HTTP request. In that case the moving object should send a HTTP request every time to create and link a new Location. There are multiple ways of doing that. Client can send a POST request to /Things(id)/Locations with new Location information. Post request can be also sent to /Locations with reference to Thing's id inside the request. The Thing's id can be kept in the device as a state or it can be derived with the method Hylke stated in issue #34 . The name and description for Location is for the client to better understand Location and are mostly helpful for static Things. While it is best practice to reuse the Locations and use meaningful name and description with real places' names for static Things, there is no specific rule for using pre-defined places, and for the case of moving objects name and description can be filled arbitrarily, as that Location most probably will be used only with that device.

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.

[dpmcgarry]

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.

[timoruohomaki]

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.

[hylkevds]

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.

[timoruohomaki]

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.

[taniakhalafbeigi]

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.