Additional time constraints and fdsnws-station (HTTP POST)

[damb]

Apparently, the fdsnws-station specific time constraint query filter parameters startbefore, startafter, endbefore and endafter are not consumed and processed by all fdsnws-station implementations at EIDA DCs in the same way.

The specs mention the parameters with:

The ​startbefore, startafter, endbefore​ and ​endafter​ parameters, used only for the ​fdsnws-station service,
specify the selection of information strictly starting or ending before or after a specified time value;
they do not match any information occurring exactly at the time specified. 
These selection parameters are specifically for metadata and are useful for matching information
that would otherwise be difficult with the other time parameters.

When executing a HTTP POST request including one of the filter parameters mentioned above, SC3 fdsnws-station implementations return HTTP status code 400:

Error 400: Bad Request

time parameter in line 4 not allowed in POST request
Usage details are available from /fdsnws/station/1/

Request:
/fdsnws/station/1/query

Request Submitted:
2019-11-12T10:00:00.370331

Service Version:
1.2.0

In contrast, the fdsnws-station implementation of RESIF does allow these additional time constraint filter query parameters.

Though, allowing both the query filter parameters startbefore, startafter, endbefore, endafter and starttime and endtime parameters is somehow redundant and cumbersome.

At the time being, eida-federator is simply forwarding the parameters to fdsnws-station endpoint resources.

Question: What implementation should eida-federator follow in order to provide the best user experience?

Thanks for reporting, @jfclinton.

[kaestli]

In general, the federator can only support request parameters which are supported by all federated services, otherwise the response is unpredictible for the user (the same query parameter set would cause different service behaviour if applied to a different geographic area).

• A conservative solution whould be to support mandatory parameters only. However, from the point of view of user experience, this would be a pity.
• As for GET requests, this information may be harvested from the application.wadl. Would be intuitive if parameters supported on POST and on GET are the same (although the fdsnws specifications are not specific on this). I have suggested this to the sc3 community.
• for the time being, (and as endpoint request strategies are configurable these days), I suggest to use GET requests only for federator requests to fdsnws/station endpoints.

[jfclinton]

my original question: Question:

• I can see all stations if I make a simple query: http://federator-testing.ethz.ch/fdsnws/station/1/query?network=Z3&level=station&format=text

• if I restrict to a givenon-date, I only get RESIF stations. http://federator-testing.ethz.ch/fdsnws/station/1/query?network=Z3&level=station&format=text&startafter=2010-01-01

Is this a known limitation?

Note this query works fine directly at the host nodes that also use the SC3 version, eg ETH: http://eida.ethz.ch/fdsnws/station/1/query?network=Z3&level=station&format=text&startafter=2010-01-01