saul at gfz-potsdam.de
Thu Nov 27 07:43:53 PST 2014
Chad Trabant wrote on 11/26/14 21:25:
> The data availability sub-system at the DMC is updated every 12 hours
> for archive data. Data is added to the archive (i.e. from the real time
> collection system) on a regular basis and is usually all in place ~18
> hours after arriving, often sooner, but it varies depending on system
> load. The data availability you see our our fdsnws-station service is
> determined by the combination of those activities.
> To report the near real-time data as available when setting
> matchtimeseries=TRUE, our service assumes that data that has been
> archived within the last 36 hours is still flowing into the data center.
> This is documented in the Data Availability section of the Help for
> the service: http://service.iris.edu/fdsnws/station/docs/1/help/
Indeed, thanks for pointing that out. It is now clear that this
behaviour is not a mistake, so I can work around it in my client.
On the other hand, quoting from the documentation:
"Extents are not modified in real-time. The archive will likely be out
of sync by up to a day, meaning:
The service assumes that if channel data was archived within the
last 36 hours, then data for the last 36 hours is available."
Based on these assumptions and considering that any end time within the
last 36 hours is equivalent to "this stream is probably producing
near-real-time data now", wouldn't it be safe to set the end time of the
availability time span to something very far in the future? I do
understand that it may look odd to claim availability of not yet
recorded data... but a similar trick is already used for the end times
in other contexts, like e.g. "2500-12-31T23:59:59" as the "end time" for
the IU network. One might also leave the end time unset to indicate
This would eliminate the need for additional logic at the client code.
Implementation of such a logic requires some knowledge of the
operational internals of the particular server, which may also be
subject to changes.
As an additional benefit the future end time would only require an
update in the case of a prolonged data outage.
Just an idea.
More information about the webservices