International Federation of Digital Seismograph Networks
Thread: StationXML location code
Sleeman, Reinoud (KNMI)
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
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
-
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
-
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
-
Chad Trabant