<div dir="ltr">SEED is a fixed width record format, most likely the reason for blank padded fields. I'd recommend not carrying that over into the XML format.<div><br></div><div>The primary purpose of the channel code is to be a unique identifier, and an empty string is distinct from any non-empty value.<div>
<br></div><div><br></div><div>Jeremy<br><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 12, 2014 at 12:53 PM, Doug Neuhauser <span dir="ltr"><<a href="mailto:doug@seismo.berkeley.edu" target="_blank">doug@seismo.berkeley.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been following this thread, and thought it was time to chime in.<br>
<br>
IMHO, the FDSN web services should follow the SEED convention.<br>
The SEED convention states that station, network, channel, and location<br>
are all blank-padded fields of fixed lengths.<br>
To me, this means that that we should either use the full blank-padded<br>
fields for ALL of these identifiers, or for none of them.<br>
<br>
eg:<br>
<br>
<Network code="G " ><br>
<Station code="KIP "><br>
<Channel locationCode=" " code="BHZ"><br>
<br>
or<br>
<br>
<Network code="G" ><br>
<Station code="KIP"><br>
<Channel locationCode="" code="BHZ"><br>
<br>
Personally I think the latter (blank trimmed) is better.<br>
<br>
I agree that the blank location code is a pain when dealing with<br>
Oracle, white-space delimited fields such as command lines, etc,<br>
but unless we change the SEED convention, I don't see that making<br>
an aliases of "-" or "--" in FDSN station XML improves the situation.<br>
<br>
AFAIK, the ONLY reason that we struggle with the two-blank issue is<br>
that certain software (eg Oracle) cannot distinguish between the<br>
the empty string (string of length 0) and NULL. Therefore, the DMC,<br>
NCEDC, AQMS, etc have been forced to not use a blank-trimmed string<br>
for the location code.<br>
<br>
Unless we propose to change the SEED standard, all of our data in<br>
our archives, and all of our current acquisition systems, I think<br>
that we have to live with "emtpy" location codes.<br>
<br>
I have not seen any compelling argument for representing a blank (empty)<br>
location code in FDSN station XML as anything but the empty string.<br>
<br>
If you want to have "" and " " be equivalent in FDSN station XML,<br>
you can simply change the schema definition of the field to be a "token"<br>
rather than a "string", in which case any representation with blanks will<br>
be reduced to the empty string. Problem solved?<br>
<br>
I note that the NCEDC implementation currently uses 1 blank " "<br>
for empty location code. I have no problem changing this if we can<br>
agree on a convention.<br>
<br>
I also note ironically that the TA network run by IRIS is one of the<br>
largest networks in terms of stations, and uses blank location codes.<br>
<br>
My 2 cents...<br>
<br>
- Doug N<div class="HOEnZb"><div class="h5"><br>
<br>
On 07/23/2014 10:30 AM, Chad Trabant wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hello WS users and developers,<br>
<br>
A recent discussion between FDSN data centers is centered on<br>
representation of empty location IDs in StationXML, the default<br>
format returned by the fdsnws-station web service. The DMC may be<br>
changing how it represents location ID in XML and text formats based<br>
on these discussions. We are asking for input as any such change will<br>
effect users of our metadata service.<br>
<br>
Some background: In the SEED channel naming scheme there is a<br>
hierarchy of network, station, location and channel identifiers. Of<br>
these, it is only the location ID that is commonly accepted to be<br>
empty. In the SEED format the location ID is a two-character field,<br>
where the value is left justified and padded with spaces if needed.<br>
When the value is empty the field is simply two spaces of padding.<br>
<br>
Historically, and presumably to avoid having an empty location ID,<br>
the DMC has represented “empty” location IDs as a string of two<br>
spaces. Following this practice, we express this in StationXML by<br>
setting the locationCode attribute to a string of two spaces. We have<br>
done this so long we sometimes forget that it is not compliant with a<br>
strict reading of SEED, at best it falls into the vagaries of SEED,<br>
on the other hand we have been doing it for years with no apparent<br>
problems (in fact it has helpfully avoided an empty core<br>
identifier).<br>
<br>
There now exists another fdsnws-station implementation that returns<br>
StationXML with the locationCode attribute set to an empty string<br>
when the SEED value is empty. The justification is that this follows<br>
the SEED rules of trimming the padding spaces from the values.<br>
<br>
Unfortunately this means there are now flavors of StationXML that are<br>
incompatible in the core channel name identifiers. In other words,<br>
two StationXML documents for the same SEED channel appear, without<br>
extra field translation, to be different channels.<br>
<br>
As most of you are users of SEED and StationXML metadata (at some<br>
level) and some of you have written code to parse these formats and<br>
manage the data returned by the DMC and other FDSN data centers, we<br>
are asking for your input regarding the potential solutions.<br>
<br>
Here are the options being considered for mapping an empty location<br>
ID in SEED to StationXML:<br>
<br>
1) Set locationCode to two spaces. While the DMC and users have been<br>
using this for a long while, it is not precisely the SEED value (but<br>
the mapping could be formalized). Also, whitespace in attributes does<br>
have some theoretical challenges: the wonky rules for XML attributes<br>
related to whitespace handling require removal of spaces in some<br>
cases (we have never heard of problems though).<br>
<br>
2) Set locationCode to an empty string. This would match the strict<br>
value present in SEED, an empty identifier.<br>
<br>
3) Set locationCode to “--“ (two dashes). This avoids issues with<br>
whitespace in XML attribute values and avoids issues with an empty<br>
identifier. Also, this matches the request mechanisms where “--“ is<br>
accepted as a synonym for an empty location ID.<br>
<br>
All of these solutions are viable in that we can make them work in<br>
code, it is a matter of choosing one for future FDSN metadata, pick<br>
your poison so to speak.<br>
<br>
In my personal opinion, an empty location ID is an unfortunate quirk<br>
of SEED that we should rectify in StationXML. An empty identifier can<br>
be confused for “unknown” if the programmer is not careful, which is<br>
semantically very different than “set to empty”. The two-space<br>
strings that the DMC is currently using are also not ideal, they are<br>
hard for humans to read and potentially weird with XML rules. The<br>
dashed location ID avoids these issues but requires the most change.<br>
I also think requiring all readers of StationXML to translate (e.g.<br>
remove padding) is a bad idea, the values in SEED should be uniquely<br>
mapped to values in StationXML.<br>
<br>
Thanks for reading this far. Your opinion and input is appreciated.<br>
<br>
regards,<br>
Chad<br>
<br>
<br>
______________________________<u></u>_________________<br>
webservices mailing list<br>
<a href="mailto:webservices@iris.washington.edu" target="_blank">webservices@iris.washington.<u></u>edu</a><br>
<a href="http://www.iris.washington.edu/mailman/listinfo/webservices" target="_blank">http://www.iris.washington.<u></u>edu/mailman/listinfo/<u></u>webservices</a><br>
<br>
</blockquote>
<br></div></div><span class="HOEnZb"><font color="#888888">
-- <br>
------------------------------<u></u>------------------------------<u></u>------------<br>
Doug Neuhauser University of California, Berkeley<br>
<a href="mailto:doug@seismo.berkeley.edu" target="_blank">doug@seismo.berkeley.edu</a> Berkeley Seismological Laboratory<br>
Office: 510-642-0931 215 McCone Hall # 4760<br>
Fax: 510-643-5811 Berkeley, CA 94720-4760<br>
Remote: 530-752-5615 (Wed,Fri)</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
webservices mailing list<br>
<a href="mailto:webservices@iris.washington.edu" target="_blank">webservices@iris.washington.<u></u>edu</a><br>
<a href="http://www.iris.washington.edu/mailman/listinfo/webservices" target="_blank">http://www.iris.washington.<u></u>edu/mailman/listinfo/<u></u>webservices</a><br>
</div></div></blockquote></div><br></div>