Proposal: allow for subselection of routes to either open or closed data by URL parameter

[kaestli]

for better user support, it may be useful to add a new query parameter :

&access=open|closed|any , with default = any

… with the functionality to subselect either routes to open or to closed data (de facto for dataselect only, as there are currently no closed routes to either wfparam or station, and event is not routed)

Note that a prerequisite for this proposal is that datacenters correctly configure the address under which a network or station epoch is available: with either ...query?bla=bla or ...queryauth?bla=bla

As the service address is part of the FDSNWS specification, closed data then can be recognized by a "queryauth" service address. (cfr. also post of 2018-09-28 on eida_maint@gfz-potsdam.de

[javiquinte]

As the service address is part of the FDSNWS specification, closed data then can be recognized by a "queryauth" service address.

Probably because of this reason I wouldn't touch the specification or add more parameters. If URLs are properly informed (e.g. queryauth; I liked your suggestion in a mail to eida_maint) the client could recognise it as restricted, and even if it's not, the error code returned by the "query" method tells the user that needs to switch to the "queryauth" method.

The Routing Service was designed to answer the simple question "Where is the data?" not to describe it in any other way. But of course this could evolve and change.

[kaestli]

Note that currently, http://orfeus-eu.org/eidaws/routing/1/query?network=* does not harvest a single route containing queryauth , which would imply that EIDA currently does not offer any restricted data. AFAIK, this is not the case. We may need to consider whether we need to adapt the standard to our current practice of not indicating whether data is under /query or /queryauth (then best by not indicating a service endpoint, but just a base address), or whether we shall adapt our routing practice to the service standard.