You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A second point is the names we use for times. Currently the proposal has:
Datastream/phenomenonTime
Datastream/resultTime
Observation/phenomenonTime
Observation/resultTime
Observation/validTime
Deployment/deploymentTime
HistoricalLocation/time
PreparationStep/time
Sampling/samplingTime
This is rather inconsistent, since sometime just time is used, while sometimes the name is spelled out completely (deploymentTime, samplingTime). For the Datastream and Observation it is obvious a shorter name can not be used, since there are multiple times, but Deployment, HistoricalLocation, PreparationStep and Sampling all only have one time.
We could either
Use time for these four times
Use the full name for these four, but what name to use?
historicalLocationTime and preparationStepTime are very ugly.
HistoricalLocation/arrivalTime? That would be semantically clearer.
In STAv1.1 we have:
2018-01-01T02:00:00Z
)2018-01-01T02:00:00Z/2018-01-01T03:00:00Z
)OData only defines TM_Instant (EDM_DateTimeOffset), not intervals.
The proposal is to model TM_Object as a complex property with a start (mandatory) and an end (optional).
Disadvantage is that even if the Observation phenomenonTime is an instant, you'll still see an object with a "start" property.
The text was updated successfully, but these errors were encountered: