[webservices] fdsnws-event service - New Release
Chad Trabant
chad at iris.washington.edu
Fri Oct 4 14:04:33 PDT 2013
Hi Philip,
Yes, there are use cases. Your vote has been heard.
We are working on some changes to hopefully satisfy both of these cases, so it might be moot.
Chad
On Oct 4, 2013, at 12:51 PM, Philip Crotwell <crotwell at seis.sc.edu> wrote:
> Hi
>
> Did you all come up with a use case for requesting "all magnitudes, but only of a single type"? I just don't see how someone wanting all 'mb' magnitudes would be mad if they also got some "Mw" and "ML" magnitudes? Not like the extra magnitudes contribute that much overhead, and as you say they can be filtered out or ignored on the client side.
>
> I do see a use case for filtering based on a magType, but still wanting to see ALL magnitudes. Searching for "mb>X" is common, but with mb saturating for large earthquakes, many seismologists would prefer to use the mw if it exists for a given event, but falling back on the mb if not. To bo honest, the main reason for me may be that the parameter name "includeallmagnitudes" is confusing if it doesn't actually "include all magnitudes".
>
> I'll cast my vote for includeallmagnitudes to really "include all magnitudes," regardless of whether or not magType is specified.
>
> My $0.02
> Philip
>
>
>
>
> On Tue, Oct 1, 2013 at 11:04 AM, Chad Trabant <chad at iris.washington.edu> wrote:
>
> Hi Philip,
>
> That is correct. We struggled with this one quite a bit and there is really no right answer. The issue is that magtype can mean either what is searched on (as specified by the spec) but also specify what is returned. If we change the logic to what you propose there will be no way to request only all magnitudes of a given type for events. There are simply not enough parameters to separate these use cases unfortunately. Understand that it remains quite easy to get all magnitudes without specifying any magtype for the server and doing more advanced selection downstream if needed.
>
> It would be useful to hear from other users regarding what would be useful. The 'magtype' parameter, per the specification, specifies which magnitudes should be used for matching the criteria (min and max). Should the 'magtype' parameter also be interpreted as a selection of what to return?
>
> thanks
> Chad
>
> On Sep 17, 2013, at 2:43 PM, Philip Crotwell <crotwell at seis.sc.edu> wrote:
>
>>
>> Hi
>>
>> So, with these changes and if I am reading the docs correctly, if I specify magType, there is no way to get all magnitudes because includeallmagnitudes only includes all the magnitudes that also match the magtype? Meaning if I query "magtype=MB&includeallmagnitudes=true" then I might get 5 magnitudes, but they will all be of type MB?
>>
>> Am I misunderstanding the docs, because this doesn't seem to match what you proposed a few weeks ago. I think there is definite value in being able to get ALL magnitudes when searching on a particular type. Being able to get all magnitudes of a given type actually seems less useful to me. In most cases I am quit happy to get the "best" magnitude of a given type, but there are cases where I want to see the best Mb and the Mw and ML for the events I am interested in.
>>
>> Can you clarify?
>> Philip
>>
>>
>>
>> On Tue, Sep 17, 2013 at 4:26 PM, Yazan Suleiman <yazan at iris.washington.edu> wrote:
>> Hello WS users,
>>
>> The DMC has updated the fdsnws-event service to version 1.0.6. Changes include:
>>
>> * Fixed bug where updatedafter operated on the wrong timezone
>> * Updated behavior of magnitudes for combinations of includeallmagnitudes and magtype. (Details)
>>
>> This release should be backwards compatible with all request tools.
>>
>> regards,
>> IRIS DMC web services team
>>
>> _______________________________________________
>> webservices mailing list
>> webservices at iris.washington.edu
>> http://www.iris.washington.edu/mailman/listinfo/webservices
>>
>>
>> _______________________________________________
>> webservices mailing list
>> webservices at iris.washington.edu
>> http://www.iris.washington.edu/mailman/listinfo/webservices
>
>
> _______________________________________________
> webservices mailing list
> webservices at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/webservices
>
>
> _______________________________________________
> webservices mailing list
> webservices at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/webservices
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iris.washington.edu/pipermail/webservices/attachments/20131004/86e7bd18/attachment.htm>
More information about the webservices
mailing list