<div dir="ltr"><div><div><div><div><div><br></div>"Under no circumstances should information about an event from one
catalog be mixed with that from another catalog (e.g., magnitude or
depth from GCMT mixed with location or origin time from another
catalog). "<br><br></div>Unfortunately, this is how quakeml works now. Magnitudes and Origins are both top level entities in an Event. Magnitudes do know the origin they "came from" but Origins have no notion of magnitudes and there is no requirement that the "primary" magnitude be connected to the "primary" origin. And in fact the current rules of priority at the DMC will give the GCMT as the primary magnitude, but the ISC origin as primary origin. The GCMT is lowest priority for origin. So, the only way you would have an origin and magnitude from the same catalog as "primary" would be if the CGMT had an origin that nobody else did! (obviously assuming the GCMT exists, smaller events might have them the same.)<br>
<br></div>I am not sure myself what the right way to do things is. There are likely good seismological reasons for using GCMT as the "more gooder" magnitude estimate, and reasons for not using its location (GCMT is a "centriod" location) but it also feels weird to me to have the origin and magnitude returned not have any connection. In the old DHI system, magnitudes were contained in the origin from which they were generated, which had the advantage that the magnitude origin connection was very strong. The disadvantage is that the magnitude-origin connection was very strong.<br>
<br></div><div>I guess I am starting to come around to the new way of doing things, and so I think I would argue that disconnecting magnitude from origin as the current event web service does it is the right way to go, but it does still feel a bit odd and leads to this mixing that you want to avoid.<br>
<br></div><div>One possible work around would be to include the origin that the primary magnitude came from if it is different from the primary origin. But then you get some confusing as to why there are two origins when I only asked for the primary.<br>
</div><div><br></div>The devil is very much in the details here.<br><br></div>Philip<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 18, 2013 at 12:38 PM, David Simpson <span dir="ltr"><<a href="mailto:simpson@iris.edu" target="_blank">simpson@iris.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Web Service aficionados<div><br><div><span style="white-space:pre-wrap"> </span>The question of how IRIS deals with catalogs and especially the issue of authoritative sources and preferred hypocenters has been of concern for some time. </div>
<div><br></div><div><span style="white-space:pre-wrap"> </span>The USGS is in the process of developing a comprehensive catalog (COMCAT) ( <a href="http://earthquake.usgs.gov/earthquakes/eqarchives/epic/" target="_blank">http://earthquake.usgs.gov/earthquakes/eqarchives/epic/</a> ) that will eventually provide the dynamic updates (and rules of engagement) that some of you have indicated would be useful. This group should track that development and provide input to NEIC on how this develops and how it is linked to any parallel developments within the FDSN. </div>
<div><span style="white-space:pre-wrap"> </span>In the meantime, I do not think that IRIS should be the business of defining "preferred solutions" from multiple catalogs. </div><div><br></div><div><span style="white-space:pre-wrap"> </span>I would prefer that for use in selecting events for waveform collection (the primary IRIS DMC application) we should limit ourselves to a carefully defined set of no more than three catalogs (NEIC, ISC and GCMT) with a careful and well-understood definition of how they are used. When using the ISC catalog, only the ISC processed and preferred solution should be used (these are clearly indicated in the ISC catalog). Under no circumstances should information about an event from one catalog be mixed with that from another catalog (e.g., magnitude or depth from GCMT mixed with location or origin time from another catalog). </div>
<div><span style="white-space:pre-wrap"> </span>This should avoid some of the confusion that is demonstrated under this current thread of discussion.</div><div><br></div><div><span style="white-space:pre-wrap"> </span>It is fine for IRIS to archive and provide access to multiple catalogs, but complex algorithms for selecting, mixing and defining preferred solutions should be left to the user or done by others (i.e. ISC or NEIC). </div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div><span style="white-space:pre-wrap"> </span>David Simpson</div></font></span><div><div class="h5"><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span><br>
<div><div>On Mar 14, 2013, at 2:20 PM, Chad Trabant <<a href="mailto:chad@iris.washington.edu" target="_blank">chad@iris.washington.edu</a>> wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word">
<div><br></div><div>Hi,</div><div><br></div><div>This is also a bug and will be addressed in our soon-to-be released FDSN event service. It was not as simple as searching the cached primary origins only, but a little deeper.</div>
<div><br></div><div>Thanks for reporting.</div><div><br></div><div>Chad</div><div><br></div><br><div><div>On Mar 13, 2013, at 8:18 AM, Philip Crotwell <<a href="mailto:crotwell@seis.sc.edu" target="_blank">crotwell@seis.sc.edu</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div><br></div>Hi<br><br></div>This query (generated by the url builder) returns no events, even though there was a mag 7.6 earthquake in Turkey in that time range. Even odder, there is an origin in the NEIC PDE-M catalog for this event, originId=4908041, but it is not returned. <br>
<br><a href="http://www.iris.edu/ws/event/query?starttime=1999-08-17T00:00:00&endtime=1999-08-17T23:59:00&minmag=7&contributor=NEIC+PDE-M&orderby=time&output=xml" target="_blank">http://www.iris.edu/ws/event/query?starttime=1999-08-17T00:00:00&endtime=1999-08-17T23:59:00&minmag=7&contributor=NEIC+PDE-M&orderby=time&output=xml</a><br>
<br></div>I am assuming that what happens is that I did not select "includeallorigins", and so this query only looked at "primary" origins. But it seems to me that if I say "use NEIC PDE-M", then the query should use that contributor even if it is no longer considered "primary".<br>
<br></div>I suppose "includeallorigins" is a workaround, but it seems counter intuitive to not be able to retrieve from a specific catalog/contributor.<br><br></div>thanks,<br></div>Philip<br><div>
<br><br></div></div>
_______________________________________________<br>webservices mailing list<br><a href="mailto:webservices@iris.washington.edu" target="_blank">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>
</blockquote></div><br></div>_______________________________________________<br>webservices mailing list<br><a href="mailto:webservices@iris.washington.edu" target="_blank">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>
</blockquote></div><br></div></div></div></div></div><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></blockquote></div><br></div>