Proposed support of optional parameters for station and dataselect queries

[kaestli]

a) STATION support the following parameters, as they are supported by all end nodes:

• startbefore
• startafter
• endbefore
• endafter
• latitude
• longitude
• minradius
• maxradius
• includerestricted
• format

support the parameter, but do not add it to end node requests:

• nodata

do not support the following parameters:

• includeavailability
• updatedafter
• matchtimeseries

b) DATASELECT: support the parameter, bud do not add to end node requests:

• format
• nodata

do not support the following parameters:

• quality (not all end nodes support all parameter options)
• minimumlength
• longestonly

(full overview: https://docs.google.com/spreadsheets/d/1hZ8ipG83xDxBbOVzO_oiG3OItoRCPIO1pvutOkbAfyI/edit?usp=sharing)

[damb]

@kaestli,

for fdsnws-station endpoint requests the format query parameter needs to be forwarded to the DCs. If not doing so format will always fall back do the default i.e. xml.

For fdsnws-dataselect the default is format=miniseed. Hence, it may be skipped.

[kaestli]

Yes, sure, obviousely. I have corrected this in the overview above.

[kaestli]

Note: all EIDA nodes currently use the same ORFEUS software to provide wfcatalog, in the same version (1.0.018). Thus, supported optional parameters and metrices seem to be the same, corresponding to, e.g., http://www.orfeus-eu.org/eidaws/wfcatalog/1/application.wadl However, note that this WADL does actually not describe all available request parameters: it skips the parameters with comparison suffixes (see specification document http://www.orfeus-eu.org/documents/WFCatalog_Specification-v0.22.pdf, page 8)

[damb]

For fdsnws-dataselect the default is format=miniseed. Hence, it may be skipped.

Is there a good reason why the format parameter shouldn't be explicit?

[damb]

Note, that the nodata query parameter wasn't included, anyway (referring to v0.9.6).

[kaestli]

on format (in dataselect): The response format is miniseed anyway. However, support of the parameter by an endnode is optional, and (dependent on the correct treatment of non-implemented optional parameters) a data center not supporting it may return http 400 if it is included. (currently, the only data center of EIDA not supporting the format parameter is RESIF, and RESIF disregards unsupported optional parameters silently. Thus, at the time being, there is no practical difference). I just thought it might be more future proof not sending a parameter which in the best case has no influence, and in the worst case causes an error)

[damb]

Ok. Both solutions are fine for me. In general, I rather prefer an explicit approach (API defaults might change in future).

However, support of the parameter by an endnode is optional, and (dependent on the correct treatment of non-implemented optional parameters) a data center not supporting it may return http 400 if it is included.

When monitoring eida-federator logs this issue is detected, easily.