International Federation of Digital Seismograph Networks

Thread: StationXML location code

None
Started: 2014-09-03 03:33:56
Last activity: 2014-09-10 04:02:42
Sleeman, Reinoud (KNMI)
2014-09-03 03:33:56
Dear WG-II members,

A recent discussion initiated by IRIS DMC on the representation of
empty location ID's in the FDSN StationXML format is taking place
mainly via the mailing list 'webservices<at>iris.washington.edu':
http://www.iris.washington.edu/pipermail/webservices/
Part of the initial discussion also took part within the FDSN WG2 mailing
list and via bi-lateral mail exchange between datacenters.

Core issue in the discussion is the need for a clear and umabigious
definition of how to represent the "empty" SEED location ID in StationXML,
which in SEED is encoded using two spaces. Chad Trabant phrased it as:

" There now exists another fdsnws-station implementation that returns
StationXML with the locationCode attribute set to an empty string
when the SEED value is empty. The justification is that this follows
the SEED rules of trimming the padding spaces from the values.

Unfortunately this means there are now flavors of StationXML that are
incompatible in the core channel name identifiers. In other words,
two StationXML documents for the same SEED channel appear, without
extra field translation, to be different channels.
"

Clearly we must NOT allow multiple flavors of StationXML. As chair of
Working Group II "Data Format and Data Centers " I like to enforce a decision
on this issue based on the various views and input by a number of contributors.
Their opinion, based on common practice, theoretical considerations and specific
implementations are very valuable and urge for a common agreement at the same
time.

In my opinion there is a prevailing number of contributors pleading for the use
of an empty string in the locationCode in StationXML in case the corresponding
location ID in SEED contains two spaces. I do support this view.

The SEED manual is clear on the location code and this must be applied directly
onto the representation of the location ID in StationXML:

- a location code is required; therefore "no location code" does not exist.
- SEED defines only A-Z and digits 0-9 as allowable characters in location codes
- by definition spaces are not allowed to represent a location code; therefore two
spaces in the SEED location field represent an empty location code;

Thus a two space location-ID field in SEED represents an empty location code
and must be represented in StationXML as:

LocationCode=""

In StationXML, the 2 spaces in SEED are not only unneeded to represent an empty
location code, they are illegal within a location code. We should not perpetuate an
unwanted SEED feature into StationXML.

Unless there are any other arguments beyond those that have been
brought in in the above mailing lists -and within 2 weeks - I will close this
discussion with the above definition.

Best regards,
Reinoud


  • Chad Trabant
    2014-09-09 17:48:53

    Dear Reinoud,

    Thank you for addressing this important issue. I am curious how you determined the prevailing number of responders, in my opinion it was approximately half wanting an ID with something versus empty, a surprising amount of variation in fact.

    Given the current state of SEED, we at the IRIS DMC agree that representing the empty location ID in SEED with an empty string in StationXML is acceptable. As this would mean a change for the IRIS DMC's web service and a transition for all users of our service we will take the time necessary to minimize the disruption for our users.

    But we consider this an incomplete solution and believe that it should be addressed in a future version of SEED. In particular, a new version of miniSEED will be needed to accomodate expanded network codes and other limitations of SEED. A transition to a new data record will afford us an opportunity to address required (non-empty) identifiers.

    regards,
    Chad, Tim & Rick


    On Sep 2, 2014, at 1:33 PM, Sleeman, Reinoud (KNMI) <reinoud.sleeman<at>knmi.nl> wrote:

    Dear WG-II members,

    A recent discussion initiated by IRIS DMC on the representation of
    empty location ID's in the FDSN StationXML format is taking place
    mainly via the mailing list 'webservices<at>iris.washington.edu':
    http://www.iris.washington.edu/pipermail/webservices/
    Part of the initial discussion also took part within the FDSN WG2 mailing
    list and via bi-lateral mail exchange between datacenters.

    Core issue in the discussion is the need for a clear and umabigious
    definition of how to represent the "empty" SEED location ID in StationXML,
    which in SEED is encoded using two spaces. Chad Trabant phrased it as:

    " There now exists another fdsnws-station implementation that returns
    StationXML with the locationCode attribute set to an empty string
    when the SEED value is empty. The justification is that this follows
    the SEED rules of trimming the padding spaces from the values.

    Unfortunately this means there are now flavors of StationXML that are
    incompatible in the core channel name identifiers. In other words,
    two StationXML documents for the same SEED channel appear, without
    extra field translation, to be different channels.
    "

    Clearly we must NOT allow multiple flavors of StationXML. As chair of
    Working Group II "Data Format and Data Centers " I like to enforce a decision
    on this issue based on the various views and input by a number of contributors.
    Their opinion, based on common practice, theoretical considerations and specific
    implementations are very valuable and urge for a common agreement at the same
    time.

    In my opinion there is a prevailing number of contributors pleading for the use
    of an empty string in the locationCode in StationXML in case the corresponding
    location ID in SEED contains two spaces. I do support this view.

    The SEED manual is clear on the location code and this must be applied directly
    onto the representation of the location ID in StationXML:

    - a location code is required; therefore "no location code" does not exist.
    - SEED defines only A-Z and digits 0-9 as allowable characters in location codes
    - by definition spaces are not allowed to represent a location code; therefore two
    spaces in the SEED location field represent an empty location code;

    Thus a two space location-ID field in SEED represents an empty location code
    and must be represented in StationXML as:

    LocationCode=""

    In StationXML, the 2 spaces in SEED are not only unneeded to represent an empty
    location code, they are illegal within a location code. We should not perpetuate an
    unwanted SEED feature into StationXML.

    Unless there are any other arguments beyond those that have been
    brought in in the above mailing lists -and within 2 weeks - I will close this
    discussion with the above definition.

    Best regards,
    Reinoud

    _______________________________________________
    fdsn-wg2-data mailing list
    fdsn-wg2-data<at>iris.washington.edu
    http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data



    • Sleeman, Reinoud (KNMI)
      2014-09-10 04:02:42
      Dear Chad,

      thank you for your positive reply - I'm really glad to read that IRIS DMC agrees on accepting
      the empty location ID in SEED to be represented with an empty string in StationXML.

      I realize this will require efforts to change the DMC web services - and I sincerely regret
      this as it takes time and manpower - and a transition time is needed. Thanks for taking care
      of this in smooth way, both for the users and for the FDSN.

      I agree there is a diversity in arguments and views on this topic, but I believe the call for
      the empty string was most favourable in common. Also important for me was to enforce
      a decision as the call for defining a standard was required by many, both in the mails
      and also off-line discussions. Personally I believe the justification I gave is the valid
      one in the strict sense, and I counted my (unweighted) vote as well. I have not seen
      any counter argument afterwards.

      Concerning modifications in (mini)SEED I believe the working group is open for any suggestions.

      Best regards,
      Reinoud

      ________________________________________
      From: fdsn-wg2-data-bounces<at>iris.washington.edu [fdsn-wg2-data-bounces<at>iris.washington.edu] on behalf of Chad Trabant [chad<at>iris.washington.edu]
      Sent: 09 September 2014 19:48
      To: fdsn-wg2-data<at>iris.washington.edu
      Subject: Re: [fdsn-wg2-data] StationXML location code

      Dear Reinoud,

      Thank you for addressing this important issue. I am curious how you determined the prevailing number of responders, in my opinion it was approximately half wanting an ID with something versus empty, a surprising amount of variation in fact.

      Given the current state of SEED, we at the IRIS DMC agree that representing the empty location ID in SEED with an empty string in StationXML is acceptable. As this would mean a change for the IRIS DMC's web service and a transition for all users of our service we will take the time necessary to minimize the disruption for our users.

      But we consider this an incomplete solution and believe that it should be addressed in a future version of SEED. In particular, a new version of miniSEED will be needed to accomodate expanded network codes and other limitations of SEED. A transition to a new data record will afford us an opportunity to address required (non-empty) identifiers.

      regards,
      Chad, Tim & Rick


      On Sep 2, 2014, at 1:33 PM, Sleeman, Reinoud (KNMI) <reinoud.sleeman<at>knmi.nl> wrote:

      Dear WG-II members,

      A recent discussion initiated by IRIS DMC on the representation of
      empty location ID's in the FDSN StationXML format is taking place
      mainly via the mailing list 'webservices<at>iris.washington.edu':
      http://www.iris.washington.edu/pipermail/webservices/
      Part of the initial discussion also took part within the FDSN WG2 mailing
      list and via bi-lateral mail exchange between datacenters.

      Core issue in the discussion is the need for a clear and umabigious
      definition of how to represent the "empty" SEED location ID in StationXML,
      which in SEED is encoded using two spaces. Chad Trabant phrased it as:

      " There now exists another fdsnws-station implementation that returns
      StationXML with the locationCode attribute set to an empty string
      when the SEED value is empty. The justification is that this follows
      the SEED rules of trimming the padding spaces from the values.

      Unfortunately this means there are now flavors of StationXML that are
      incompatible in the core channel name identifiers. In other words,
      two StationXML documents for the same SEED channel appear, without
      extra field translation, to be different channels.
      "

      Clearly we must NOT allow multiple flavors of StationXML. As chair of
      Working Group II "Data Format and Data Centers " I like to enforce a decision
      on this issue based on the various views and input by a number of contributors.
      Their opinion, based on common practice, theoretical considerations and specific
      implementations are very valuable and urge for a common agreement at the same
      time.

      In my opinion there is a prevailing number of contributors pleading for the use
      of an empty string in the locationCode in StationXML in case the corresponding
      location ID in SEED contains two spaces. I do support this view.

      The SEED manual is clear on the location code and this must be applied directly
      onto the representation of the location ID in StationXML:

      - a location code is required; therefore "no location code" does not exist.
      - SEED defines only A-Z and digits 0-9 as allowable characters in location codes
      - by definition spaces are not allowed to represent a location code; therefore two
      spaces in the SEED location field represent an empty location code;

      Thus a two space location-ID field in SEED represents an empty location code
      and must be represented in StationXML as:

      LocationCode=""

      In StationXML, the 2 spaces in SEED are not only unneeded to represent an empty
      location code, they are illegal within a location code. We should not perpetuate an
      unwanted SEED feature into StationXML.

      Unless there are any other arguments beyond those that have been
      brought in in the above mailing lists -and within 2 weeks - I will close this
      discussion with the above definition.

      Best regards,
      Reinoud

      _______________________________________________
      fdsn-wg2-data mailing list
      fdsn-wg2-data<at>iris.washington.edu
      http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


      _______________________________________________
      fdsn-wg2-data mailing list
      fdsn-wg2-data<at>iris.washington.edu
      http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data