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 ?
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..
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.
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
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.
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.
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.
> 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.