-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clock synchronisation between Sensors/Things #47
Comments
To my understanding, clock-synchronization is way beyond what the standard covers and probably should cover. However, there might be a simple solution to your problem. According to the standard, Observation has a property So basically this is exactly what you propose with the |
@mjacoby, yes but only using I would like to have a more general solution to address this issue whatever the possibilities of a |
@mjacoby The question is: if this problem is a common issue when using the model, would not it be interesting to take it into account by the model instead of letting users develop their own solutions? |
@abourdon Thanks for providing the background of the potential issue. Can you please write a precise description or a definition of this attribute you propose? It will help the SWG to understand the proposed attribute better. Thanks. |
@liangsteve To sum up my proposal I would say: Create a new Thinking about this further, I finally don't think it is necessary for a client to override it. This way, value will not be provided by client but always generated by the SensorThings server and available when requesting This way, it could solve my issue without being too specific about it (and be more in phase with standard vision, @mjacoby). What do you think? |
What would happen to this time instant when the entity is updated? |
@hylkevds, in this case, the And as we talk about the term entity, we could also generalize these |
@abourdon I get your point and without deeper analysis adding the property Therefore, I would propose to change the standard to explicitly focus on extensibility. This could be done either by allowing additional fields in JSON instead of failing (what is currently the defined behaviour) or by adding an attributes This way it would be possible to easily adjust an existing server implementation, for example to provide the additional properties you suggested. |
@mjacoby I totally agree to keep the core model as simple as possible. And to go further with your idea of extension, we could imagine to define a set of optional model properties that a server implementation could allow following a specific request option or specific server configuration. If an optional model property make sense to be available whatever the server implementation, we could include it to the SensorThings API specification to restrict any server implementation to follow the same naming convention. As a direct application, we could imagine our two For instance, based on FROST-Server configuration, it could be defined like this: <context-param>
<description>Display additional entity's timestamps as creation and update time instants. </description>
<param-name>entity.EnableTimestamps</param-name>
<param-value>true</param-value>
</context-param> This way, any time we get a SensorThings's entity, we will get its associated {
"@iot.id": 1,
"@iot.selfLink": "http://example.org/v1.0/Things(1)",
"@iot.createdAt": "2018-03-17T07:00:00+01:00",
"@iot.updatedAt": "2018-04-19T08:00:00+01:00",
"Locations@iot.navigationLink": "Things(1)/Locations",
"Datastreams@iot.navigationLink": "Things(1)/Datastreams",
"HistoricalLocations@iot.navigationLink":
"Things(1)/HistoricalLocations",
"name": "Oven",
"description": "This thing is an oven.",
"properties": {
"owner": "Noah Liang",
"color": "Black"
}
} What do you think? |
That would be one possible way of doing it. However, these are quite ground-breaking ideas that would introduce lots of other problems. Therefore my current proposal for the standard would be to just allow additional properties in JSON for any entity and to write down that a server should rather ignore unknown properties instead of failing. This is very straight forward to implement and opens up the standard to be easily extended to application needs. |
One approach is to write an OGC Engineering Report or even better, a Best Practice (with conformance classes), to define a standard way to use it. |
@mjacoby maybe I was not clear about my thoughts. I propose to have 2 types of optional properties:
All of these properties can be activated following a dedicated configuration (from a configuration file or request option or whatever). |
Ok, so we are basically on the same side about the functionality.
|
Short question for clarification - how does createdAt differ from the resultTime? |
@KathiSchleidt Here is the definition of resultTime according to 7.2.2.3 of OGC 10-004r3 Observation and Measurement - |
@liangsteve This was why I was thinking in this direction, as the act of the sensor providing the measurement to STA sounds a lot like "the time when the result became available"; while the result was formally physically "available" on the sensor earlier, this availability is constrained enough to be useless. |
@KathiSchleidt STA and SOS follow O&M. As a result, resultTime SHALL follow the definition of mentioned above. The time an Observation is made publicly available (assuming via STA?) means differently from resultTime as defined in OGC 10-004r3. As a result, The time an Observation is made publicly available (assuming via STA?) should be using a different attribute. |
There are also use cases where there is a significant difference between the resultTime and the createAt time. Essentially anything that involves laboratory work.
With a bit of luck we might even see this in the BRGM data set :) |
so createAt could be understood as the digital object lifespan - would make sense to add |
We use different |
Hi,
We have a use case that uses more than 2
Sensor
s that sendObservation
s about the sameObservedProperty
. To have a global view of allObservation
s about this sameObservedProperty
, we then have to consolidate allSensor
'sObservation
s.But to correctly do that, we have to make sure that all
Sensor
s (or associatedThing
s) share the same clock. This way, we will be able to sortObservation
s against theirphenomenonTime
s orresultTime
s. Otherwise, it would be difficult to have a temporal view of our data.A possible solution to our problem would be to have a reference time for each
Observation
. Thus, whatever the time offset between multipleSensor
sObservations
, we will be able to synchronize them with this reference time.A simple implementation of this solution could be to add a
createdAt
(or name it as you want)Observation
's property that will be set before anyObservation
is sent to our SensorThings service. This way, we will need to have an ad-hoc solution (any solution could be imagined) that set this reference time anytime we send anObservation
.However, this implementation needs to have this ad-hoc solution, and so anytime someone will face this issue, he will need to have this additional layer, that could be a drag on the use of the SensorThings API.
A better implementation could be to have this
createdAt
value as anObservation
's attribute (so handled by the SensorThins API model and no more as an implementation-specific property). This way, this value could be set either:What do you think about it? Maybe I'm totally wrong and there is another way to do it, that's why I will be happy to know your opinion on it :-)
Regards,
Aurélien
The text was updated successfully, but these errors were encountered: