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
{{ message }}
This repository has been archived by the owner on Oct 11, 2024. It is now read-only.
I see now that 1900-01-01T00:00:00 refers to the StartTime field. And only the first three values are related to that date. I think this interval is associated to the aggregationType which is here 1 hour.
<swe:values>
1900-01-01T00:00:00,2013-09-08T00:00:00,NOT_SET,NOT_SET,1h,29.0@@
1900-01-01T00:00:00,2013-09-09T00:00:00,NOT_SET,NOT_SET,1h,26.0@@
1900-01-01T00:00:00,2013-09-10T00:00:00,NOT_SET,NOT_SET,1h,16.0@@
<!-- from here the 1h aggregationType associates correctly to StartTime and EndTime -->
2013-09-07T18:00:00,2013-09-07T19:00:00,NOT_SET,NOT_SET,1h,80.0
<!-- following values are truncated for brevity -->
2013-09-10T18:00:00,2013-09-10T19:00:00,NOT_SET,NOT_SET,1h,49.0@@
</swe:values>
However, drawing a timeseries would need a time instant a value was measured at. Perhaps we can discuss if it might better to use the middle of the aggregation time period to be that time instant and add kind of validFrom and validUntil fields.
TopicCenter has freezed the encoding format so the interval won't change anymore. I might have to check the OxF to use either start time, end time or calculate the middle of the time interval.
However, the issue with StartTime being 1900-01-01T00:00:00 remains.
Sending a request containing timespan
temporalFilter=om:phenomenonTime,2013-09-07T20:50:32.416+0200/2013-11-06T19:50:32.416+0100
returns an observation collection withThe text was updated successfully, but these errors were encountered: