Route merging about routing HOT 2 CLOSED

Mail by Philipp Kästli on the matter:

Dear colleagues,

note that while the second request is more compact, the first (with individual requests for individual stations)

• will provide you with more information about what parts of the request can be fulfilled, and which parts (stations) fail for what reason
  (as fdsn station provides only one return code per request)
• will leverage transparently any service parallelization / load balancing available at the data center (and given many codes are in obspy, load balancing is probably the easiest and most scalable way of parallelization to be expected)

Thus while I can clearly see the elegance, I am not fully convinced by the practical advantages of the collapsed queries.

Kind regards,

Philipp

from routing.

The first point raised by Philipp is important and should be addressed. We experience the same issue requesting information from a single datacenter on a network basis. AFAIK the philosophy behind the routing service is to use as many wildcards as possible. So we say that GE.* is routed to GFZ, and that request is therefore not on a station to station basis. It is unclear to me why we should we make an exception for shared networks, it is entirely arbitrary.

I do not understand the second point that is made in this context.

In any case, the requests should be condensed by us on the federator level. It is much faster to do a single request for multiple stations, than multiple requests for a single station (this is purely practical). The information on what requests fail is IMHO not irrelevant. If one request fails, the entire federated request should fail with no exceptions.

The alternative would be adding an option compact=true to the list of supported parameters in the routing service.

from routing.