Database Reference
In-Depth Information
extensions created for the use case. For instance, since features of interest in
SSN can have geometric relations, it is possible to have a feature of interest for
a building, containing features of interest for each floor, containing features of
interest for each room. The building-feature could have an associated datastream
listing all the observations in the entire building, while each floor has one listing
the observations on that floor and so on. This set-up seems to be very much in
the spirit of the idea behind datastreams, since the description of datastreams
explicitly mentions having the same observed property being the only constraint,
however the SensorThings API also specifies that each observation links to only 1
datastream and this set-up would have observations be in multiple datastreams.
When an observation is requested the service could return only the datastream
with the smallest semantic distance to the feature of interest of the observation.
Regardless of which query is used to implement the datastreams, when using
virtual datastreams the creation of a new datastream through the SensorThings
API is not possible. However, it might be possible to accept datastream-creation
commands without actually creating new datastreams. When creating a new
datastream through the SensorThings API, a client has to specify both a thing
and an observed property. Since the server is free to assign an identifier to a
newly created datastream, it can map this identifier to the identifier of one of
the virtual datastreams, and return that. From the perspective of the client it
would seem like the create command was successful.
The disadvantage of doing things this way with virtual datastreams is that
when two clients both create a datastream for the same observed property and
thing, they will receive the same datastream identifier, and will end up posting
observations to the same datastream, even though they might not expect this.
For read-only operation this implementation of virtual datastreams would work
adequately.
3.5 Observations
There is little difference in the concept of observations as used in the OGC
SensorThings API and in OpenIoT. In OpenIoT an observation is split into
the concepts “Observation” and “ObservationValue”, but since there is a 1-1
relationship between the two, this makes no difference for the mapping of the
two data models.
There is a difference in that the OpenIoT observation has a direct relation
to the observed property, while in the SensorThings API this relation goes over
a datastream object. The SensorThings API specifies that when a client/sensor
creates a new observation, it has to specify the datastream for this observation,
but not an observed property. To store the observation in the OpenIoT data
format, the server will have to connect the observation to an observed property.
When using virtual datastreams one way to do this is to encode the identifier of
the observed property into the identifier of the datastream. That way the server
can deduce the observed property from the datastream-identifier that is specified
when observation is created.
Search WWH ::
Custom Search