[Federator] Geographic constraints not working as expected

[ogalanis]

The response to the station service includes stations that should have been excluded by the geographic constraints. E.g. the following query:

http://eida-federator.ethz.ch/fdsnws/station/1/query?starttime=2022-06-01T00%3A00%3A00&endtime=2022-06-10T00%3A00%3A00&minlatitude=38&maxlatitude=39&minlongitude=21&maxlongitude=22&format=text&level=channel&nodata=404

... also returns stations such as:
KO|KAMT||HHZ|39.3692|33.7124|1120.0|...
BW|PART||HHZ|47.497238|11.11313|760.0|...
2D|EF02|00|HHZ|50.36329|7.25004|247.0|...
...
RA|MALA|00|HNE|14.595300|-60.995660|21.0|...

If it helps with the debugging, the last station has the exact same station code with a station in the specified area (but with a different network code), but in most cases it seems to be random.

This happens both in the browser and ObsPy.

I noticed this yesterday (2023-09-20) and today.

[megies]

This happens both in the browser and ObsPy

That's expected, obspy doesn't do any filtering itself besides putting the filter constraints in the requested URL or POST payload

[javiquinte]

Hi. The same query (even simplified) sent to the Routing Service works perfectly.

http://orfeus-eu.org/eidaws/routing/1/query?minlatitude=38&maxlatitude=39&minlongitude=21&maxlongitude=22&format=post

The four stations mentioned in the first post appear, but with different network codes. And the lat/lon properties are OK and respect the query filters.
With Obspy is also perfect, so no problem there.

Same query sent to the Station-WS of the corresponding nodes look OK also.

[ogalanis]

Yes, this has to be a Federator issue, not a routing or an individual node issue.

[kaestli]

I acknowledge this as a federator bug (error in the internal routing, most probably due to insufficient tracking of the network in case a station code used for stations in multiple networks, with different coordinates). Investigations ongoing.

[kaestli]

This is a serious issue in the the federator's routing behaviour: it assumes uniqueness of station names.

As a consequence, queries for stations with its stationcodes available in multiple networks may return data of the station of the wrong network, if the selection is based on station properties only (lat, lon, start- and end time). This affects mostly temporary stations with non-speaking names (A01, A02 ...)
The software issue is tracked here: EIDA/eidaws#34 ; fixing it will take some time.

[kaestli]

just to tell you that we are finally working on this...