fdsnws

Hi There list,

I am having a trouble in requesting one event (using parameter
eventid) using fdsnws client. On the documentation it says it should
support INT or STR event ids but in reality it always try to convert
it to INT while assembling the URL raising one Exception since my ids
are STR type (sc3 style).

Is there something I am missing ? I had a look on the code,
fdsn/headers.py and it sets the type as int, also looked at
wadl_parser and found nothing. Would this be a possible bug ?

regards,

Marcelo

Hi Marcelo,

indeed, this looks like a bug to me. I'll fix it, in the meantime you
can replace the `int` with `str` in fdsn/headers.py in the DEFAULT_TYPES
dictionary as you already suspected.

However, it looks to me as if the DEFAULT_TYPES entry is only used if
the WADL file of the server doesn't specify the type of the parameter,
so the server you are accessing (a seiscomp3 instance? :)) seems to
either not specify the type or specifies it as "int"? Maybe you should
check that WADL file..

best,
Tobias

Hi Marcelo,

http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf specifies the type of "eventid" to be string. You are right that conversion to integer is a bug.

Possibly this misunderstanding resulted from the IRIS-type numerical event ID's, see http://service.iris.edu/fdsnws/event/1/. There the description of the "eventid" parameter reads "Retrieve an event based on the unique ID numbers assigned by the IRIS DMC", but it is also written there that the type of "eventid" is text.

Cheers
Joachim

Marcelo B. Bianchi [17.07.2014 14:46]:

Hi Tobias,

indeed, this looks like a bug to me. I'll fix it, in the meantime you
can replace the `int` with `str` in fdsn/headers.py in the DEFAULT_TYPES
dictionary as you already suspected.

I did it as a hack.

However, it looks to me as if the DEFAULT_TYPES entry is only used if
the WADL file of the server doesn't specify the type of the parameter,
so the server you are accessing (a seiscomp3 instance? :)) seems to
either not specify the type or specifies it as "int"? Maybe you should
check that WADL file..

you are right, WADL on SC3 is not accurate in specifying but as Joachim pointed, "eventid" spec is string. Sc3 WADL is defined as

<param name="eventid" style="query" repeating="true"/>

I will change mine specifying explicitly string, but maybe the best for obspy would be to set this as string following the standards.

best regards,

Marcelo

Hi Joachim, Marcelo,

On 07/17/2014 03:43 PM, Joachim Saul wrote:> [...]

..., but it is also written there that the type of "eventid" is text.

Cheers
Joachim

you're correct, however, the IRIS' WADL file specifies:

<param name="eventid" style="query" type="xs:long">

So, we'd have a problem requesting an event by ID if it is not an int.
I think this might be intended by IRIS as they seem to set the eventid
by themselves but I'll forward this to IRIS, just in case.

I will change mine specifying explicitly string, but maybe the best
for obspy would be to set this as string following the standards.

Yes and yes. It's safer to have it in the WADL directly in any case (and
you don't need the hack if you change the WADL), but of course we should
have "str" and I already fixed it. Of course it only hits with the next
release.

best,
Tobias

That is great Tobias !

I really think it is important to forward this to IRIS.

I just modified our FDSN@USP so now it has the type and should not stop people trying to use it with current obspy release.

regards,

Marcelo

Hi,

I have changed the eventid (and originid) in our fdsnws-event WADL to xs:string types to be helpful. Technically this document is for a specific service interface and since the DMC will only have integer IDs for the foreseeable future it was and will be correct, but it hardly makes any difference so not a big deal to change.

regards,
Chad

Marcelo B. Bianchi [07/17/2014 03:51 PM]:

<param name="eventid" style="query" repeating="true"/>

I will change mine specifying explicitly string, but maybe the best for
obspy would be to set this as string following the standards.

To whom it may concern:

The WADL of the SC3 implementation of the fdsnws server has also been updated to reflect the correct type according to the specification.

Cheers
Joachim

Hi Joachim and Marcelo,

I am curious as to which standards and specification both of you are referring. The FDSN WS spec does not address the data type of the eventid parameter. The QuakeML spec (only one of the service output formats) has a publicID that ends up being a string and is usually related to the eventid values, perhaps this is the connection? Even if a service output format was directly tied to the input parameters of a service, any given implementation could have further restrictions based on the data set and use the WADL to communicate that to clients.

Thanks for any enlightenment.

cheers,
Chad

Hi CHad,

It is listed in the parameters table, page 5 of the spec version 1.1:

http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf

regards,

Marcelo

Marcelo B. Bianchi [18.07.2014 19:03]:

It is listed in the parameters table, page 5 of the spec version 1.1:

http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf

Also here: http://service.iris.edu/fdsnws/event/1/

Quote:

eventid | 1234 | Retrieve an event based on the unique ID numbers assigned by the IRIS DMC | | text |

Cheers
Joachim

Ah, of course, thanks.

Chad

Marcelo B. Bianchi [18.07.2014 19:03]:

It is listed in the parameters table, page 5 of the spec version 1.1:

http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf

Also here: http://service.iris.edu/fdsnws/event/1/

Quote:

> eventid | 1234 | Retrieve an event based on the unique ID numbers assigned by the IRIS DMC | | text |

That is not a spec or a standard, that documents (sometimes incorrectly) an implementation, a WADL does the same. If a data center will only have strings of numbers there is no reason they cannot document their interface to communicate that. We could have changed our web page documentation to “integer” and it would have been correct. We’ve changed our WADL to be more helpful to those that use our WADL as a general template, but now it is very slightly less helpful to our WADL users.

thanks,
Chad