[fdsn-wg2-data] StationXML location code

[Sleeman, Reinoud (KNMI)]

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