Thread: Cannot get a list of data centers through fed catalog

Started: 2016-07-30 03:14:53
Last activity: 2016-08-04 22:00:14
Topics: Web Services

Hello,
In the not very distant past I was able to get a JSON-formatted list of data centers using the URL:http://service.iris.edu/irisws/fedcatalog/1/datacenters

Today I tried and got a 404 error.
However on the page http://service.iris.edu/irisws/fedcatalog/1 the text implies it is still possible. E.g.



"FDSN Data Centers

A list of FDSN data centershttp://service.iris.edu/irisws/fedcatalog/1/datacenters (returns JSON) contributing to the combined catalog is available in JSON format and includes web service endpoints at each data center.”


Thanks!

  • Good morning Doug,

    Thank you for bringing this to our attention. There appears to have been a configuration issue with the fedcatalog service that has now been addressed. The datacenters request is now functional again, but please inform me if you continue to encounter problems.

    Apologies for the inconvenience and thanks for your patience.

    Kindly,
    Robert

    _______________________________
    Robert Weekly
    Quality and Deployment System Engineer
    [e] rtweekly<at>iris.washington.edu



    On Aug 2, 2016, at 9:37 AM, Doug Dodge <dodge1<at>llnl.gov> wrote:


    Hello,
    In the not very distant past I was able to get a JSON-formatted list of data centers using the URL:http://service.iris.edu/irisws/fedcatalog/1/datacenters

    Today I tried and got a 404 error.
    However on the page http://service.iris.edu/irisws/fedcatalog/1 the text implies it is still possible. E.g.



    "FDSN Data Centers
    A list of FDSN data centers <http://service.iris.edu/irisws/fedcatalog/1/datacenters (returns JSON) contributing to the combined catalog is available in JSON format and includes web service endpoints at each data center.”

    Thanks!


    ----------------------
    Web Services (http://ds.iris.edu/message-center/topic/webservices/)

    Sent via IRIS Message Center (http://ds.iris.edu/message-center/)
    Update subscription preferences at http://ds.iris.edu/account/profile/


    • Suzan van der Lee
      2016-08-03 05:28:59
      Hello,

      I have been wondering about the options for different web serices having to with time series. Example: timeseries and rotation.
      They both understand the options for net=, location=, starttime=, station name=, output=, etc.
      They can both convert digital counts to m/s but for one it’s via “scale=auto” and for the other it’s “correct=scale”.
      They both understand the “endtime=…” option, but only one of them can also understand the “duration=…”, and the other doesn’t.
      One of them can “demean=true”, the other cannot.
      The first one shows only one channel at a time, e.g. “cha=BHZ”, while the other can show three, “chaset=BH&components=ZNE”

      I woudl love it if these options could be a bit more homogeneous. For example
      Can rotation accept the duration option?
      Can the option for scaling with stage 0 sensitivity have the same syntax between services?
      Can rotation be given the demean option?

      Suzan

      • Philip Crotwell
        2016-08-03 02:54:03
        +1 on a consistent set of parameters.

        I would like to see duration on the dataselect service as well.

        Philip


        On Tue, Aug 2, 2016 at 6:59 PM, Suzan van der Lee
        <suzan<at>northwestern.edu> wrote:
        Hello,

        I have been wondering about the options for different web serices having to
        with time series. Example: timeseries and rotation.
        They both understand the options for net=, location=, starttime=, station
        name=, output=, etc.
        They can both convert digital counts to m/s but for one it’s via
        “scale=auto” and for the other it’s “correct=scale”.
        They both understand the “endtime=…” option, but only one of them can also
        understand the “duration=…”, and the other doesn’t.
        One of them can “demean=true”, the other cannot.
        The first one shows only one channel at a time, e.g. “cha=BHZ”, while the
        other can show three, “chaset=BH&components=ZNE”

        I woudl love it if these options could be a bit more homogeneous. For
        example
        Can rotation accept the duration option?
        Can the option for scaling with stage 0 sensitivity have the same syntax
        between services?
        Can rotation be given the demean option?

        Suzan


        ----------------------
        Web Services (http://ds.iris.edu/message-center/topic/webservices/)

        Sent via IRIS Message Center (http://ds.iris.edu/message-center/)
        Update subscription preferences at http://ds.iris.edu/account/profile/


      • Charles Ammon
        2016-08-03 17:13:57
        Consistency is good.

        You can leave the existing commands implemented for a while so people
        who may have scripted them (I haven't) can change them.

        On 2 Aug 2016, at 17:59, Suzan van der Lee wrote:

        Hello,

        I have been wondering about the options for different web serices
        having to with time series. Example: timeseries and rotation.
        They both understand the options for net=, location=, starttime=,
        station name=, output=, etc.
        They can both convert digital counts to m/s but for one it’s via
        “scale=auto” and for the other it’s “correct=scale”.
        They both understand the “endtime=…” option, but only one of
        them can also understand the “duration=…”, and the other
        doesn’t.
        One of them can “demean=true”, the other cannot.
        The first one shows only one channel at a time, e.g. “cha=BHZ”,
        while the other can show three, “chaset=BH&components=ZNE”

        I woudl love it if these options could be a bit more homogeneous. For
        example
        Can rotation accept the duration option?
        Can the option for scaling with stage 0 sensitivity have the same
        syntax between services?
        Can rotation be given the demean option?

        Suzan

        ----------------------
        Web Services (http://ds.iris.edu/message-center/topic/webservices/)

        Sent via IRIS Message Center (http://ds.iris.edu/message-center/)
        Update subscription preferences at http://ds.iris.edu/account/profile/


        ================================mb===================================
        Charles J. Ammon, Department of Geosciences
        Penn State University / 440 Deike Bldg / University Park, PA 16802
        VOICE: (814) 865 2310 / FAXES: (814) 863 7823 or (814) 863 8724
        http://eqseis.geosc.psu.edu/~cammon/
        http://www.personal.psu.edu/faculty/c/j/cja12/

        • Anthony Lomax
          2016-08-04 00:27:20
          I would vote for always leaving the existing commands implemented - lack
          of consistency (backwards compatibility) is a disaster for all the "one
          project" / "one funding cycle" / "one temporary developer who moved on"
          software we all use and depend on in seismology.

          Very unfortunately the people at Python and GMT do not think consistency
          is necessary... lots of $$$ and/or breakage for us...

          Anthony


          On 03/08/2016 17:14, Charles Ammon wrote:
          Consistency is good.

          You can leave the existing commands implemented for a while so people
          who may have scripted them (I haven't) can change them.

          On 2 Aug 2016, at 17:59, Suzan van der Lee wrote:

          Hello,

          I have been wondering about the options for different web serices
          having to with time series. Example: timeseries and rotation.
          They both understand the options for net=, location=, starttime=,
          station name=, output=, etc.
          They can both convert digital counts to m/s but for one it’s via
          “scale=auto” and for the other it’s “correct=scale”.
          They both understand the “endtime=…” option, but only one of
          them can also understand the “duration=…”, and the other
          doesn’t.
          One of them can “demean=true”, the other cannot.
          The first one shows only one channel at a time, e.g. “cha=BHZ”,
          while the other can show three, “chaset=BH&components=ZNE”

          I woudl love it if these options could be a bit more homogeneous. For
          example
          Can rotation accept the duration option?
          Can the option for scaling with stage 0 sensitivity have the same
          syntax between services?
          Can rotation be given the demean option?

          Suzan

          ----------------------
          Web Services (http://ds.iris.edu/message-center/topic/webservices/)

          Sent via IRIS Message Center (http://ds.iris.edu/message-center/)
          Update subscription preferences at http://ds.iris.edu/account/profile/

          ================================mb===================================
          Charles J. Ammon, Department of Geosciences
          Penn State University / 440 Deike Bldg / University Park, PA 16802
          VOICE: (814) 865 2310 / FAXES: (814) 863 7823 or (814) 863 8724
          http://eqseis.geosc.psu.edu/~cammon/
          http://www.personal.psu.edu/faculty/c/j/cja12/

          ----------------------
          Web Services (http://ds.iris.edu/message-center/topic/webservices/)

          Sent via IRIS Message Center (http://ds.iris.edu/message-center/)
          Update subscription preferences at http://ds.iris.edu/account/profile/


          --
          Sent from my iClayTablet

          ------------------------------------------------------------------------

          *Anthony Lomax*
          *320 Chemin des Indes, 06370 Mouans-Sartoux, France*
          *tel: +33 (0)4 92 92 29 79 e-mail: anthony<at>alomax.net
          <anthony<at>alomax.net> web: http://www.alomax.net
          <http://www.alomax.net/ *

          *Twitter: * *@ALomaxNet <http://twitter.com/ALomaxNet*
          *Science & Special Topics: * *http://www.alomax.net/science*
          *Software: * *http://www.alomax.net/software* *- updates: *
          *https://twitter.com/ALomaxNet*
          ------------------------------------------------------------------------

      • Chad Trabant
        2016-08-04 03:04:53

        Hi Suzan (and others that responded),

        You brought up a number of different issues of varying complexity, let me try to address them one at a time.

        1) A demean option for rotation. We can probably add this without too much difficulty. If there are other, specific options that you would like to see in rotation please let us know.

        2) Consistent parameter for applying Stage 0 (total sensitivity) scaling to data. Most of our parameters are pretty darn consistent, this processing action is admittedly an exception. In two of the three services where we do Stage 0 scaling the option also does other and different things, so we struggled a bit with names. Here is the current situation:

        irisws-timeseries <http://service.iris.edu/irisws/timeseries/1/ service:
        scale parameter, accepts a number to scale the sample values or auto to apply stage 0 sensitivity
        correct parameter, a boolean for doing full instrument correction

        irisws-rotation <http://service.iris.edu/irisws/rotation/1/ service:
        correct parameter, accepts one of none, scale, or response (where scale does stage 0 sensitivity)

        irisws-timeseriesplot <http://service.iris.edu/irisws/timeseriesplot/1/ service:
        earthunits parameter, a boolean to apply stage 0 sensitivity.

        Ideally, we would add a parameter to one or two of the services to provide a consistent way to request the application of the scaling in Stage 0. For example, we could add earthunits (a boolean) to irisws-timeseries and irises-rotation. Alternatively we could add scale (that accepts auto) across them all. We can't use correct, it already has conflicting values. I'd like to avoid a completely new parameter if possible. I am leaning towards adding earthunits, but it's not a perfect description. Feedback encouraged.

        For those worried about us removing or changing options, don't, we will avoid that whenever possible. Options might become deprecated, even undocumented, but the current ones will work for some time barring a major conflict.

        3) The duration parameter. This is a legacy parameter that we stopped using in order to provide clarity and to reduce the number of alternative ways of doing this to reduce bugs and complexity. After all, this is just an alternate way to specify an end time. The irisws-timeseries service is one of the few remaining original services still running and so still has it. If there is enough interest in this bit of syntactic convenience I would prefer to add it the same way we did in the irisws-timeseriesplot service where, if the end time is specified as a number it is interpreted as a duration in seconds instead of a date-time. As opposed to propagating a whole new 'duration' parameter.

        If we really want to be consistent we would do it in every service that has 'endtime'. For the FDSN services it would be an extension of the standard and certainly not supported at any other data centers anytime soon. So if you are writing software that uses FDSN services you'd have to calculate the end time anyway since that's the only way it would work beyond IRIS (or until the specification changes and everyone updates). Worth it?

        Again, feedback welcome.

        4) irisws-timeseries can plot only a single seismogram while irisws-rotation can plot 3 seismograms. Making irisws-timeseries handle more than a single time series is unlikely any time soon; this is basically asking for a "bulk processed time series" service, which we simply do not have the resources to support. The alternative is to simply call irisws-timeseries multiple times as many already do.


        A bit lengthy, but I hope that clarifies a few things.

        Thanks for the feedback, we'll start working on a #1 and continue to discuss the rest.

        Chad



        On Aug 2, 2016, at 3:59 PM, Suzan van der Lee <suzan<at>northwestern.edu> wrote:

        Hello,

        I have been wondering about the options for different web serices having to with time series. Example: timeseries and rotation.
        They both understand the options for net=, location=, starttime=, station name=, output=, etc.
        They can both convert digital counts to m/s but for one it’s via “scale=auto” and for the other it’s “correct=scale”.
        They both understand the “endtime=…” option, but only one of them can also understand the “duration=…”, and the other doesn’t.
        One of them can “demean=true”, the other cannot.
        The first one shows only one channel at a time, e.g. “cha=BHZ”, while the other can show three, “chaset=BH&components=ZNE”

        I woudl love it if these options could be a bit more homogeneous. For example
        Can rotation accept the duration option?
        Can the option for scaling with stage 0 sensitivity have the same syntax between services?
        Can rotation be given the demean option?

        Suzan

        ----------------------
        Web Services (http://ds.iris.edu/message-center/topic/webservices/)

        Sent via IRIS Message Center (http://ds.iris.edu/message-center/)
        Update subscription preferences at http://ds.iris.edu/account/profile/


        • Chad Trabant
          2016-08-04 22:00:14

          2) Consistent parameter for applying Stage 0 (total sensitivity) scaling to data. Most of our parameters are pretty darn consistent, this processing action is admittedly an exception. In two of the three services where we do Stage 0 scaling the option also does other and different things, so we struggled a bit with names. Here is the current situation:

          irisws-timeseries <http://service.iris.edu/irisws/timeseries/1/ service:
          scale parameter, accepts a number to scale the sample values or auto to apply stage 0 sensitivity
          correct parameter, a boolean for doing full instrument correction

          irisws-rotation <http://service.iris.edu/irisws/rotation/1/ service:
          correct parameter, accepts one of none, scale, or response (where scale does stage 0 sensitivity)

          irisws-timeseriesplot <http://service.iris.edu/irisws/timeseriesplot/1/ service:
          earthunits parameter, a boolean to apply stage 0 sensitivity.

          Ideally, we would add a parameter to one or two of the services to provide a consistent way to request the application of the scaling in Stage 0. For example, we could add earthunits (a boolean) to irisws-timeseries and irises-rotation. Alternatively we could add scale (that accepts auto) across them all. We can't use correct, it already has conflicting values. I'd like to avoid a completely new parameter if possible. I am leaning towards adding earthunits, but it's not a perfect description. Feedback encouraged.

          Hi all,

          Rob Casey had a good idea for a harmonizing these, I modified it slightly, but this seems pretty good:

          scale=
          [number] - value to scale by
          sensitivity - scale by stage 0, aka total sensitivity
          response - scale by full response curve
          none - apply no scaling

          Not all services would support all options and some services might have different defaults, but this would provide a consistent way to request the application of scaling.

          Let us know soon if anyone really doesn't like that pattern or has an alternate suggestion.

          Chad




Page built 03:17:28 | v.92bc2cb9