[fdsn-wg2-data] StationXML location code

[Chad Trabant]

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