server
server copied to clipboard
How to query last Observations for Thing in single GET?
Did not find a public STA mailing list, so posing the question here: need to get the last Observations
for a single Thing
(or better from a series of Things
from a properties.project
query). Question was posed on our SE issue tracker:
https://github.com/Geonovum/smartemission/issues/79
Started a SE STA Cookbook where I will add any recipes.
I know this can be solved in multiple steps:
- GET list of
Things
with$expand
edDatastreams
- for each
Datastream
GET the lastObservation
(think$top=1
)
But I am seeking to do the 2nd step in one GET. Scenario: typically a web viewer that shows a map with AQ Stations, clicking on a Station will show all last station's last sensor (Observation
) values. Example: http://data.smartemission.nl/smartapp/.
something like this? http://localhost:8080/v1.0/Things(1)?$expand=Datastreams/Observations($top=1)
Getting only the last observation for a thing is not possible, you can however request the related datastreams and the latest observation for the datastream.
Example GET a list of Things based on a property with expanded datastreams and last observation:
https://gost.geodan.nl/v1.0/Things?$expand=Datastreams($select=id),Datastreams/Observations($select=id,phenomenonTime,result;$top=1)&$filter=properties/owner eq 'TimE'&$select=id,name,description
You can findout more about SensorThings and ODATA here: https://gost1.docs.apiary.io/#reference/odata
Thanks for the quick responses! I've adapted the SE STA Cookbook after experimenting with various GET options.
Example 1
Get the last Observation
for each Datastream
from a Thing
queried by device_id
in a single GET ( @bertt suggestion): http://data.smartemission.nl/gost/v1.0/Things?$filter=name eq ‘20010001’&$expand=Datastreams/Observations($top=1))
Example 2
Using $select
, to receive less data attributes. Here query for Device id 20010001
last Observations
showing only id
and name
of each Datastream
(@tebben suggestion):
Somehow the part Observations($select=id,phenomenonTime,result;$top=1)
did not work (complains about parenthesis mismatch). Using Docker geodan/gost:0.5
.
It's possible that some queries do not work on version 0.5, latest version has better query support.
Ok, I see e.g. #129 fixed separated inline options.
One last Thing: need to find a query to get all Observations related to single Thing for time interval in particular last 48 hours. Tried ISO 8601 intervals without success.
This (phenomenonTime
with gt
, lt
) works on all Observations
:
but how to realize for single Thing
?
Should be something like
http://data.smartemission.nl/gost/v1.0/Things(1)?$expand=Datastreams/Observations($filter=date(phenomenonTime) le date(now()) and date(phenomenonTime) ge date('2018-01-01');$select=result,phenomenonTime,parameters)&$select=id,name
however, I found a problem with parsing of string/date/time on inline queries, I'm looking into it now
Yes, I tried similar $filter
constructs and found date/time parsing issues as well, but was using ISO 8601 strings directly, not using the date()
function like date('2018-01-01')
. At some point I was not sure if $filter
could even be used inside Entity()
brackets. Remember we are using 0.5.
Using ISO 8601 strings should also be fine I just used date() as an example, The odata code is now updated to get the mentioned example working, strings weren't parsed properly inside $expand queries. There is still some work to do to get all queries working inside the $expand operation, an issue is created for this: https://github.com/gost/server/issues/147
Tried gost:latest
Docker image (on 09.02.2018, 16:00). Can confirm that multiple inline options work like ;$top=1
and that it is possible to get all Things
with their Location
and last Observation
for each Datastream
:
Only this returns 13
Things
out of 184 with no nextLink
. This possibly related to issue #146.
Also in theory getting the last Observations for a time period works, but with same nextLink
issue, getting one Thing
, possibly not all Observations
, but on the other hand I can imagine that keeping a nextLink
here would be quite complicated, maybe even a flaw in the standard..:
Related to issue #146, should be fixed. We are aware of possible complications around not having a nextlink on expanded entity arrays, the STA standard does not specify this and is indeed complicated to implement, however we are planning to implement this and making this an optional feature in the feature.