Robert Casey
Dear Data Services Users-
Following up on our migration from the historical IRIS/FDSN metadata infrastructure to a StationXML 1.1 compliant service stack this week, we want to provide a recap of what has occurred since the past couple of days to let you know where things stand:
* The station service is running smoothly and follows a few new rules of output, such as omitting ending times for presently operational station/channel epochs.
* Despite extensive testing, we discovered a few utilities in the production area were not compatible with changes in certain specific instances.
* A majority of metadata was being served successfully. We encountered unforeseen edge cases that were not being extracted by the new station service, and we immediately developed fixes.
* We discovered some gaps in our new database metadata holdings through direct record-by-record comparison. These were patched over the past two days and we now deem the current database to be complete.
There are just a few outstanding issues that have yet to be addressed:
* The Fedcatalog service and MDA are both functional, but new channel entries containing polynomial responses may not yet be available by the service. These types of responses are mostly related to environmental time series channels, such as pressure or wind speed.
* Empty values in the text output format of the station service may place a 'null' string instead of being blank.
* The irisFetch.m Matlab client requires a library update to handle the new empty end time output when asking for SACPZ metadata.
* The 'matchtimeseries' feature of the station service might fail on empty end times.
* The tracedsp web service might fail on empty end times. The rotation service has already been fixed for this same issue.
What will happen next?
On Monday, we plan to deploy a station service update, refresh the Fedcatalog service, and address remaining peripheral issues such as the tracedsp service. This should address all but the irisFetch.m issue, which we expect can be quickly resolved afterward.
Thank you for your patience as we tighten down this new infrastructure. There are a lot of complicated pieces that have to work together and it certainly taught us a few things for future infrastructure upgrades.
Regards,
The IRIS Data Services team
-
Hi
First thanks for all the work you have done to improve the station web
service and to respond to the issues that came up. However, I found
this upgrade more difficult that I was expecting, and I feel that when
the next major change to one of your web services is planned, it would
be highly useful for those of us that develop client software to have
an opportunity to test our client code against the new web service
before it replaces the existing one. There shouldn't be any technical
reason why you could not run both in parallel for some short period of
time and it would help my users if I could find and fix issues and
have an upgrade ready before the switchover is made.
thanks
Philip
On Fri, Feb 7, 2020 at 6:42 PM Rob Casey <rob<at>iris.washington.edu> wrote:
Dear Data Services Users-
Following up on our migration from the historical IRIS/FDSN metadata infrastructure to a StationXML 1.1 compliant service stack this week, we want to provide a recap of what has occurred since the past couple of days to let you know where things stand:
* The station service is running smoothly and follows a few new rules of output, such as omitting ending times for presently operational station/channel epochs.
* Despite extensive testing, we discovered a few utilities in the production area were not compatible with changes in certain specific instances.
* A majority of metadata was being served successfully. We encountered unforeseen edge cases that were not being extracted by the new station service, and we immediately developed fixes.
* We discovered some gaps in our new database metadata holdings through direct record-by-record comparison. These were patched over the past two days and we now deem the current database to be complete.
There are just a few outstanding issues that have yet to be addressed:
* The Fedcatalog service and MDA are both functional, but new channel entries containing polynomial responses may not yet be available by the service. These types of responses are mostly related to environmental time series channels, such as pressure or wind speed.
* Empty values in the text output format of the station service may place a 'null' string instead of being blank.
* The irisFetch.m Matlab client requires a library update to handle the new empty end time output when asking for SACPZ metadata.
* The 'matchtimeseries' feature of the station service might fail on empty end times.
* The tracedsp web service might fail on empty end times. The rotation service has already been fixed for this same issue.
What will happen next?
On Monday, we plan to deploy a station service update, refresh the Fedcatalog service, and address remaining peripheral issues such as the tracedsp service. This should address all but the irisFetch.m issue, which we expect can be quickly resolved afterward.
Thank you for your patience as we tighten down this new infrastructure. There are a lot of complicated pieces that have to work together and it certainly taught us a few things for future infrastructure upgrades.
Regards,
The IRIS Data Services team
----------------------
Web Services
Topic home: http://ds.iris.edu/message-center/topic/webservices/ | Unsubscribe: webservices-unsubscribe<at>lists.ds.iris.edu
Sent from the IRIS Message Center (http://ds.iris.edu/message-center/)
Update subscription preferences at http://ds.iris.edu/account/profile/
Philip Crotwell
