mass_downloader (technically) still looks for fdsnws availability service even when disabled

[Robert Pickle]

Avoid duplicates

• I searched existing issues

Bug Summary

There seems to be a small logical hiccup in how mass_downloader determines is_availability_reliable for a client.

The issue is that the matchtimeseries argument is usually present in the station FDSN service regardless of the availability being on. In practice this doesn't matter so long as it isn't set to True, but the download_helper.py currently checks for the existence of this parameter rather than checking if the availability service is active.

Here is the original code in download_helper.py circa line 1096

        # Check the capabilities of the service and see what is the most
        # appropriate way of acquiring availability information. Some services
        # right now require manual overriding of what they claim to be
        # capable of.
        if "matchtimeseries" in self.client.services["station"]:
            arguments["matchtimeseries"] = True
            if "format" in self.client.services["station"]:
                arguments["format"] = "text"
            self.is_availability_reliable = True

I suggest changing this to:

        if 'availability' in client.services:  *********** change this line
            arguments["matchtimeseries"] = True
            if "format" in self.client.services["station"]:
                arguments["format"] = "text"
            self.is_availability_reliable = True

... as I can't think of any circumstance where matchtimeseries will be working but availability is not.

Code to Reproduce

n/a

Error Traceback

n/a

ObsPy Version?

master..ish

Operating System?

No response

Python Version?

No response

Installation Method?

None

[Tobias Megies]

... as I can't think of any circumstance where matchtimeseries will be working but availability is not.

From your description, this doesn't seem to be a problem of obspy but rather the server side implementation. FDSN station-WS is not tied to availability-WS as far as the end user / frontend API is concerned. This parameter predates even the existence of the availability-WS if I'm not totally off. It should be the server's responsibility to either make sure matchtimeseries is implemented in a useful manner or (since it is an optional parameter) simply left out of the API (and thus the application WADL describing the server capabilities).
If the server proclaims that matchtimeseries is supported, but internally is not capable of fulfilling that claim and even filtering out results that are totally valid and data is available for, that seems to be a server issue.

Is there an example for when setting matchtimeseries=True is excluding valid results? What FDSN server?

[Robert Pickle]

You're right, it is fundamentally a server issue... it took me a minute to figure out how to get rid of it, requires a bit of hacking since it won't just disappear out of station when you disable availability. It looks like most FDSN servers other figured this out a long time ago as I can't find any still running it.

I figured it was a relic implementation as well since it seems redundant and less-featured. However it seems like Seiscomp is going to keep shipping with it in for the time being. I suppose my thinking in raising the issue here was that it's not a sensible check for mass_downloader relative to just seeing if availability is on, but probably not a good enough reason to change anything just yet.

[Tobias Megies]

OK, I think I'll close this for now. If you have an example request where this is an actual problem, please feel free to share it here though.