<div dir="ltr">Hi,<div><br></div><div>I realize I am coming pretty late to the party here, but I'll chime in anyway. At SCEDC (the archive for the Southern California Seismic Network), we represent our empty location codes with two blank spaces as well. I suspect the same is done at the Northern California Earthquake Data Center.</div>
<div><br></div><div>There are great arguments here for each of the options presented, but I think unless we decide to make location id optional we should not use an empty string to denote an unset location id in StationXML. I think there is enough variety in how an empty string is treated in different programming languages and databases to be problematic. From some databases' perspectives, you really might as well make it null at that point.</div>
<div><br></div><div>So I would say, if location id is required, use a two character substitution; my personal preference is two spaces as that seems to be the convention (although it ain't pretty) - and we should consider in a future version of stationXML making the location id optional.</div>
<div><br></div><div><br></div><div>Ellen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 31, 2014 at 5:59 AM, Philip Crotwell <span dir="ltr"><<a href="mailto:crotwell@seis.sc.edu" target="_blank">crotwell@seis.sc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yet another data point, going all the way back to vol 1 issue 1 of the<br>
DMC newsletter introducing location ids:<br>
<br>
"The Location Identifier is a two character code that, when used in<br>
conjunction with the other data specifiers, uniquely identifies a data<br>
stream."<br>
and<br>
"Historically, within a SEED volume, the Location Identifier was left<br>
“blank” (consisted of two spaces)."<br>
and<br>
"GSN Use of Location Identifiers<br>
Valid characters for location identifiers are [space, 0-9, A-Z][space,<br>
0-9, A-Z]. (So space-space is a legitimate Location Identifier.) "<br>
<br>
<a href="http://www.iris.edu/ds/newsletter/vol1/no1/specification-of-seismograms-the-location-identifier/" target="_blank">http://www.iris.edu/ds/newsletter/vol1/no1/specification-of-seismograms-the-location-identifier/</a><br>
<br>
>From this it seems that location id was intended to be exactly 2<br>
characters, not zero or two. My feeling is that we have a long<br>
tradition of the location id being "space-space" and not null or<br>
empty. Personally I really dislike space-space, but the only thing I<br>
dislike more than space-space is empty.<br>
<span class="HOEnZb"><font color="#888888"><br>
Philip<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Thu, Jul 31, 2014 at 7:18 AM, Philip Crotwell <<a href="mailto:crotwell@seis.sc.edu">crotwell@seis.sc.edu</a>> wrote:<br>
> Hi<br>
><br>
> Just another data point, Earthworm, which is widely used by regional<br>
> networks globally, has long had the "dash dash is the same as space<br>
> space" convention. So dash dash is not something pulled out of thin<br>
> air, it is how at least I do things already.<br>
><br>
> And this shows that it is fairly common (if not technically correct)<br>
> for users to regard space-space as the location id instead of<br>
> regarding it as null with 2 spaces for padding. My guess is that very<br>
> few users are aware of this, and even as someone who has been writing<br>
> seismic software for a couple of decades I still think of the location<br>
> id as space-space, not null.<br>
><br>
> <a href="http://www.isti2.com/ew/PROGRAMMER/location_codes/EW_Loc_policy.txt" target="_blank">http://www.isti2.com/ew/PROGRAMMER/location_codes/EW_Loc_policy.txt</a><br>
><br>
> Philip<br>
><br>
><br>
> On Thu, Jul 31, 2014 at 6:18 AM, Chad Trabant <<a href="mailto:chad@iris.washington.edu">chad@iris.washington.edu</a>> wrote:<br>
>><br>
>> Thanks Philip, I think you have outlined the issues well.<br>
>><br>
>> Regarding issue #1, I strongly feel that we need to choose one<br>
>> representation, the sooner we stop creating incompatible metadata the<br>
>> better.<br>
>><br>
>> Regarding issue #2:<br>
>><br>
>> b) two spaces=" "<br>
>><br>
>><br>
>> This is what IRIS currently does, not strictly SEED but avoids empty<br>
>> identifiers.<br>
>><br>
>> c) two dashes="--".<br>
>><br>
>><br>
>> This would require work and continued mapping, the mapping is clear between<br>
>> SEED-based holdings and StationXML. SEED headers and data records could<br>
>> also be considered, but is a bigger can of worms.<br>
>><br>
>> a) empty=""<br>
>><br>
>><br>
>> This is possibly the most straight forward mapping of SEED information, but<br>
>> leaves us with an empty string identifier.<br>
>><br>
>> Below are a few of the issues we note regarding empty identifiers<br>
>><br>
>> 1) They are too similar to "unknown" (which results in potential ambiguity<br>
>> where channels are only differentiated by location ID):<br>
>><br>
>> a) In many languages an empty string evaluates to false; if, for example,<br>
>> when program is testing for and then extracting a value from an XML document<br>
>> parsed into a structure/object it could appear as if the value was not<br>
>> present. Of course the coding in probably every language can be done to<br>
>> avoid such a false negative, but it is a pitfall that we would be asking all<br>
>> future users and coders to know about.<br>
>><br>
>> b) In XPath (the query language for XSLT), which is used to search or<br>
>> translate XML, the matching of a string attribute usually uses the string()<br>
>> function. Specifying the string attribute to match when the attribute has a<br>
>> value is straightforward, when trying to match the empty string the query is<br>
>> for NOT string. In the boolean functions of XPath "a string is true if and<br>
>> only if its length is non-zero"<br>
>> (<a href="http://www.w3.org/TR/xpath/#function-boolean" target="_blank">http://www.w3.org/TR/xpath/#function-boolean</a>). So in XPath, hardly a<br>
>> fringe technology, an empty string is not just another kind of string but an<br>
>> anomoly.<br>
>><br>
>> c) In JavaScript the getAttribute() method returns the same value whether<br>
>> the attribute was an empty string or unspecified. The method is no longer<br>
>> recommended but illustrates that such thinking is not limited to niche<br>
>> projects.<br>
>><br>
>> 2) Organizing data in structures such as a nested hash is pretty common:<br>
>> %{net}{sta}{loc}{chan} = "some lvalue" (sorry for the Perl). The empty<br>
>> identifier as a key works in some languages but it is obtuse and unclear.<br>
>> I'm sure there are many other data structures that would use location by<br>
>> itself as a key.<br>
>><br>
>> 3) Empty identifiers are difficult to specify on the command line, URLs,<br>
>> etc. and non-obvious many other places such as GUI fields. We have largely<br>
>> addressed this issue for FDSN web services (at the DMC for other mechanisms<br>
>> as well) by making "--" a synonym for the empty location ID. In other words<br>
>> we are already mapping "--" into the empty location ID for requests and<br>
>> users are learning this association. A further adoption of the synonym into<br>
>> the metadata would solve many of these problems.<br>
>><br>
>> 4) While it is certainly not the FDSN's task to define data formats outside<br>
>> of its purview, the adoption or matching of the core channel naming fields<br>
>> in other formats is certainly in the FDSN's best interest. This has been<br>
>> happening for a long time already (ISF/IASPEI, GSE, etc.). The potentially<br>
>> empty (optional?) location ID could make such adoption harder as it is an<br>
>> wrinkle, especially for space delimited formats. I believe these broader<br>
>> implications deserve some consideration.<br>
>><br>
>> I'm sure most developers could come up with solutions to the technical<br>
>> problems, but an empty identifier leaves the unfortunate wrinkles for all<br>
>> future users and coders.<br>
>><br>
>> Here is an example of someone that was confused by current metadata, I'll<br>
>> bet if there was a value in the locationCode it would have been easier:<br>
>> <a href="https://stackoverflow.com/questions/19348855/checking-for-empty-attributes-while-parsing-an-xml-file" target="_blank">https://stackoverflow.com/questions/19348855/checking-for-empty-attributes-while-parsing-an-xml-file</a><br>
>><br>
>> There is a chance we will end up with the empty location identifier, but the<br>
>> considerations should go beyond an assumption that an empty string is the<br>
>> only choice.<br>
>><br>
>> Since an empty location field in SEED essentially means unset, perhaps we<br>
>> should consider making the locationCode attribute optional and leaving it<br>
>> out of the XML when it is empty in SEED. In this line of thinking, the<br>
>> empty string is just a hack to include a required attribute when in fact<br>
>> there is nothing to include. For me the "unset" aspect is unsettlingly<br>
>> similar to "unknown", but it's an idea preferred by at least one engineer at<br>
>> the DMC.<br>
>><br>
>> Chad<br>
>><br>
>><br>
>> On Jul 28, 2014, at 6:37 AM, Philip Crotwell <<a href="mailto:crotwell@seis.sc.edu">crotwell@seis.sc.edu</a>> wrote:<br>
>><br>
>> Hi<br>
>><br>
>> Being on the cheap side of the Atlantic, I'll save us $0.00068 and<br>
>> make a stab at the underlying issue. :)<br>
>><br>
>> Here, with lots of stuff cut out, is how a channel is "identified" in<br>
>> stationXML via the fdsn station web service at the IRIS DMC,<br>
>> <a href="http://service.iris.edu/fdsnws/station/1/query?net=GE&sta=UGM&cha=BHZ&level=channel&format=xml&nodata=404" target="_blank">http://service.iris.edu/fdsnws/station/1/query?net=GE&sta=UGM&cha=BHZ&level=channel&format=xml&nodata=404</a><br>
>><br>
>> <Network code="GE" ><br>
>> <Station code="UGM"><br>
>> <Channel locationCode=" " code="BHZ"><br>
>><br>
>> Another implementation of the same web service (not sure of url) gives<br>
>> back this:<br>
>><br>
>> <Network code="GE" ><br>
>> <Station code="UGM"><br>
>> <Channel locationCode="" code="BHZ"><br>
>><br>
>> with locationCode="" vs =" " being the difference under consideration.<br>
>><br>
>> There are two basic issues being discussed (and yes, more beer would help!<br>
>> :)<br>
>><br>
>> 1) Should all valid stationXML documents be required to use the exact<br>
>> same string of characters to represent the location id for this<br>
>> channel. This is would allow a comparison operation to be "simple" in<br>
>> that it can compare the attribute values without additional<br>
>> processing.<br>
>><br>
>> 2) If we agree to 1), then what should those exact characters be? The<br>
>> current top choices are<br>
>> a) empty=""<br>
>> b) two spaces=" "<br>
>> c) two dashes="--".<br>
>><br>
>> 1) seems less controversial than 2) in that greater compatibility is<br>
>> generally seen as positive.<br>
>><br>
>> This is primarily a question about the form of the stationXML<br>
>> documents, but obviously there are connections to the way requests are<br>
>> formed, the relationship to miniseed/seed, the way things are coded in<br>
>> software and how much detailed understanding we expect of end users.<br>
>><br>
>> Philip<br>
>><br>
>><br>
>><br>
>> On Mon, Jul 28, 2014 at 3:59 AM, Anthony Lomax <<a href="mailto:alomax@free.fr">alomax@free.fr</a>> wrote:<br>
>><br>
>> Hello all,<br>
>><br>
>> Can someone give a concise statement of the original problem being<br>
>> discussed, it only or primarily a concern about XML?<br>
>><br>
>> It seems to me that with modern languages a string that is empty or has 1-N<br>
>> spaces is the same thing - there are often implicit or explicit trim()<br>
>> function hiding in a processing pipeline. A null string is not the same.<br>
>> So an empty or blank string is the same, valid location code, and null is<br>
>> undefined or uninitialized location code.<br>
>><br>
>> With regards to the "--" pseudo for the location code, is this not needed<br>
>> because sometimes it is not possible or difficult to represent an empty<br>
>> string or even a string? For example on the command line or in a restful WS<br>
>> URI? (Or a URI on the command line!) So it may be that the use of "--" for<br>
>> intermediate processing and requests could be tolerated and somehow<br>
>> official, while empty or only-blanks strings official and for persistent<br>
>> data.<br>
>><br>
>> Just my 0.02€ = $0.0268<br>
>><br>
>> Best regards to all,<br>
>><br>
>> Anthony<br>
>><br>
>><br>
>><br>
>> On 27/07/2014 04:52, Chad Trabant wrote:<br>
>><br>
>> Hi Marcelo,<br>
>><br>
>> Thanks for your thoughts as well. Something that you and Joachim are not<br>
>> addressing are the concerns about an empty ID that have been brought up by<br>
>> more than one person. The answer that empty strings are technically<br>
>> possible and it all works in Python/SeisComP is less than satisfying. The<br>
>> observations from Python, ObsPy and SeisComP are a few of many that need to<br>
>> be taken into account.<br>
>><br>
>> I agree that there is a long tail consideration for the "--" location ID<br>
>> solution. Understand that some folks find an empty ID to be problematic<br>
>> regardless of whether it is XML, SEED, text, whatever, then you might see<br>
>> where this proposal comes from. Yes, we would need to treat empty location<br>
>> IDs and "--" as synonyms for a very long time. Empty strings in XML mean<br>
>> you will need to map empty IDs to empty strings, NULL and whatever an XML<br>
>> parser might or might not produce for a long time as well (think beyond<br>
>> Python and SeisComP). Either is possible, only one of them is a unique<br>
>> mapping.<br>
>><br>
>> If the main considerations are for the least amount of disruption the the<br>
>> answer is obvious to me: the FDSN can sanction that the two-space string is<br>
>> the XML synonym for the empty SEED location ID and we adjust the schema to<br>
>> make sure a string of whitespaces is preserved. Then SeisComP can change<br>
>> its relatively new StationXML implementation and ALL existing clients will<br>
>> be compatible with all metadata and, mostly importantly, we would have<br>
>> consistent metadata.<br>
>><br>
>> If the empty string ID representation is adopted it would would, in effect,<br>
>> mean that the DMC would need to change its metadata service and (more<br>
>> importantly) all users of the DMC's metadata service would need to<br>
>> transition to a new metadata channel naming scheme. This is certainly not<br>
>> out of the question, but it is not something we would do without careful<br>
>> consideration. I do not find the two-space strings all that great, but they<br>
>> are here and something the DMC and users of the DMC have dealt with. Issues<br>
>> have been identified with empty location IDs by us and our users. If DMC is<br>
>> going to change, and push the change on all users of the DMC's StationXML,<br>
>> it would be much more compelling to have a solution that addresses the low<br>
>> level issues.<br>
>><br>
>> regards,<br>
>> Chad<br>
>><br>
>><br>
>> ----- Original Message -----<br>
>> From: "Marcelo Bianchi" <<a href="mailto:m.tchelo@gmail.com">m.tchelo@gmail.com</a>><br>
>> To: "IRIS Web Services List" <<a href="mailto:webservices@iris.washington.edu">webservices@iris.washington.edu</a>><br>
>> Sent: Friday, July 25, 2014 7:38:17 PM<br>
>> Subject: Re: [webservices] A question of location ID, how to represent empty<br>
>> IDs in XML?<br>
>><br>
>> Hi Philip and All,<br>
>><br>
>> I totaly agree with Joachim, was planning to answer but he was much<br>
>> faster. What you guys are proposing is not a solution. the station XML<br>
>> supports nicely the empty string and it is not null. There is a type<br>
>> difference here in Python and in any other language and can be nicely<br>
>> handled internally.<br>
>><br>
>> Also the location id is not just a string it is a key entry to link<br>
>> miniseed to metadata and making an exception at this level just<br>
>> because a user interface cannot proper render it without ambiguity<br>
>> does not sounds like a proper way proposal. I am not favorable in<br>
>> creating an exception that will have to be carried over along the<br>
>> decades to come. Alternatives solutions for this issue should be<br>
>> searched on the end user interface.<br>
>><br>
>> with my best regards,<br>
>><br>
>> Marcelo Bianchi<br>
>> --<br>
>><br>
>><br>
>> 2014-07-25 10:35 GMT-03:00 Philip Crotwell <<a href="mailto:crotwell@seis.sc.edu">crotwell@seis.sc.edu</a>>:<br>
>><br>
>> It sounds like you are saying "change is hard, so we shouldn't do it".<br>
>> I would argue that change is hard and so if we don't do it now it will<br>
>> never happen. StationXML is new enough that there is already a<br>
>> disruption, we should seize the chance. If we do not do something now<br>
>> about null loc ids, it will be a decade or two before we get another<br>
>> chance.<br>
>><br>
>> It is time to drive the stake through the heart of null location ids.<br>
>> Kill the evil while we have a chance.<br>
>><br>
>> Philip<br>
>><br>
>><br>
>> On Fri, Jul 25, 2014 at 9:26 AM, Joachim Saul <<a href="mailto:saul@gfz-potsdam.de">saul@gfz-potsdam.de</a>> wrote:<br>
>><br>
>> Hello Rob,<br>
>><br>
>> Rob Newman wrote on <a href="tel:24.07.2014%2018" value="+12407201418">24.07.2014 18</a>:51:<br>
>><br>
>> For what it's worth, I would also vote for the "--" standard. To quote<br>
>> from the Zen of Python<br>
>> <<a href="http://python.net/%7Egoodger/projects/pycon/2007/idiomatic/handout.html" target="_blank">http://python.net/%7Egoodger/projects/pycon/2007/idiomatic/handout.html</a>><br>
>> (my language of choice):<br>
>><br>
>><br>
>> "Beautiful is better than ugly.<br>
>> Explicit is better than implicit.<br>
>> Simple is better than complex.<br>
>> Complex is better than complicated.<br>
>> Flat is better than nested.<br>
>> Sparse is better than dense.<br>
>> Readability counts.<br>
>> Special cases aren't special enough to break the rules.<br>
>> Although practicality beats purity.<br>
>> Errors should never pass silently.<br>
>> Unless explicitly silenced."<br>
>><br>
>> I'd add "Compatible is better than incompatible." :)<br>
>><br>
>><br>
>> Number 2 is especially relevant here:<br>
>> "Explicit is better than implicit."<br>
>><br>
>> My favorite would be:<br>
>><br>
>> "Special cases aren't special enough to break the rules."<br>
>><br>
>> Quoted whitespace and nulls are painful. Code what you mean, and mean what<br>
>> you code. It's easier for everyone.<br>
>><br>
>> But what if we simply *mean* "empty string"?<br>
>><br>
>> The issue is not about beauty, pain or ease. It's about standard<br>
>> conformance. We already have a channel naming standard. If a new data format<br>
>> cannot accommodate existing channel naming, then the new format is flawed.<br>
>> But that's not even the case here...<br>
>><br>
>> An XML document that contains<br>
>><br>
>> <Channel locationCode="" ...<br>
>><br>
>> is not malformed. There's an attribute that *explicitly* contains an empty<br>
>> string and a parser has to produce it as such. Not as null, nil or none, but<br>
>> as an empty string. Otherwise the parser is broken and needs to be fixed,<br>
>> not the data!<br>
>><br>
>> Again: It's not about beauty. We all agree that current channel naming is<br>
>> not particularly beautiful and has limitations. But our business is not to<br>
>> try to solve that issue now and here.<br>
>><br>
>> Cheers<br>
>> Joachim<br>
>><br>
>> _______________________________________________<br>
>> webservices mailing list<br>
>> <a href="mailto:webservices@iris.washington.edu">webservices@iris.washington.edu</a><br>
>> <a href="http://www.iris.washington.edu/mailman/listinfo/webservices" target="_blank">http://www.iris.washington.edu/mailman/listinfo/webservices</a><br>
>><br>
>> _______________________________________________<br>
>> webservices mailing list<br>
>> <a href="mailto:webservices@iris.washington.edu">webservices@iris.washington.edu</a><br>
>> <a href="http://www.iris.washington.edu/mailman/listinfo/webservices" target="_blank">http://www.iris.washington.edu/mailman/listinfo/webservices</a><br>
>><br>
>> _______________________________________________<br>
>> webservices mailing list<br>
>> <a href="mailto:webservices@iris.washington.edu">webservices@iris.washington.edu</a><br>
>> <a href="http://www.iris.washington.edu/mailman/listinfo/webservices" target="_blank">http://www.iris.washington.edu/mailman/listinfo/webservices</a><br>
>> _______________________________________________<br>
>> webservices mailing list<br>
>> <a href="mailto:webservices@iris.washington.edu">webservices@iris.washington.edu</a><br>
>> <a href="http://www.iris.washington.edu/mailman/listinfo/webservices" target="_blank">http://www.iris.washington.edu/mailman/listinfo/webservices</a><br>
>><br>
>><br>
>> --<br>
>> Sent from my iClayTablet<br>
>><br>
>> ________________________________<br>
>><br>
>> Anthony Lomax<br>
>> 161 Allée du Micocoulier, 06370 Mouans-Sartoux, France<br>
>> tel: <a href="tel:%2B33%20%280%294%2093%2075%2025%2002" value="+33493752502">+33 (0)4 93 75 25 02</a> e-mail: <a href="mailto:anthony@alomax.net">anthony@alomax.net</a> web:<br>
>> <a href="http://www.alomax.net" target="_blank">http://www.alomax.net</a><br>
>><br>
>> Twitter: @ALomaxNet<br>
>> Science & Special Topics: <a href="http://www.alomax.net/science" target="_blank">http://www.alomax.net/science</a><br>
>> Software: <a href="http://www.alomax.net/software" target="_blank">http://www.alomax.net/software</a> - updates:<br>
>> <a href="https://twitter.com/ALomaxNet" target="_blank">https://twitter.com/ALomaxNet</a><br>
>> ________________________________<br>
>><br>
>> _______________________________________________<br>
>> webservices mailing list<br>
>> <a href="mailto:webservices@iris.washington.edu">webservices@iris.washington.edu</a><br>
>> <a href="http://www.iris.washington.edu/mailman/listinfo/webservices" target="_blank">http://www.iris.washington.edu/mailman/listinfo/webservices</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> webservices mailing list<br>
>> <a href="mailto:webservices@iris.washington.edu">webservices@iris.washington.edu</a><br>
>> <a href="http://www.iris.washington.edu/mailman/listinfo/webservices" target="_blank">http://www.iris.washington.edu/mailman/listinfo/webservices</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> webservices mailing list<br>
>> <a href="mailto:webservices@iris.washington.edu">webservices@iris.washington.edu</a><br>
>> <a href="http://www.iris.washington.edu/mailman/listinfo/webservices" target="_blank">http://www.iris.washington.edu/mailman/listinfo/webservices</a><br>
>><br>
<br>
_______________________________________________<br>
webservices mailing list<br>
<a href="mailto:webservices@iris.washington.edu">webservices@iris.washington.edu</a><br>
<a href="http://www.iris.washington.edu/mailman/listinfo/webservices" target="_blank">http://www.iris.washington.edu/mailman/listinfo/webservices</a><br>
</div></div></blockquote></div><br></div>