[Federator] No virtual networks?

[javiquinte]

I cannot get information from virtual networks from the federator. Am I doing something wrong? I tried with "_GEALL"

% curl -v "http://eida-federator.ethz.ch/fdsnws/station/1/query?net=_GEALL&format=text"
*   Trying 129.132.148.115:80...
* Connected to eida-federator.ethz.ch (129.132.148.115) port 80
> GET /fdsnws/station/1/query?net=_GEALL&format=text HTTP/1.1
> Host: eida-federator.ethz.ch
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 204 No Content
< Server: nginx/1.18.0 (Ubuntu)
< Date: Fri, 15 Mar 2024 10:31:05 GMT
< Content-Type: text/plain; charset=utf-8
< Connection: keep-alive
<
* Connection #0 to host eida-federator.ethz.ch left intact

but also with "_SCANARRAY" and the error was the same.

% curl -v "http://eida-federator.ethz.ch/fdsnws/station/1/query?net=_SCANARRAY&format=text"
*   Trying 129.132.148.115:80...
* Connected to eida-federator.ethz.ch (129.132.148.115) port 80
> GET /fdsnws/station/1/query?net=_SCANARRAY&format=text HTTP/1.1
> Host: eida-federator.ethz.ch
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 204 No Content
< Server: nginx/1.18.0 (Ubuntu)
< Date: Fri, 15 Mar 2024 10:31:16 GMT
< Content-Type: text/plain; charset=utf-8
< Connection: keep-alive
<
* Connection #0 to host eida-federator.ethz.ch left intact

[kaestli]

Thanks @javiquinte for pointing me to this. The requests are correct. The code is working, you can verify this e.g. with the networks _ALPARRAY, _NFOIRPINIA, _NFOFRANC, _PELOPS.

The issue is that the federator is missing the definitions of the virtual networks defined at GFZ, although they are declared at https://geofon.gfz-potsdam.de/eidaws/routing/1/localconfig

I will investigate...

(note : when looking at your localconfig, I see that most virtual networks contain NET.STA.. combinations available twice or more times with different start dates (and open end date), and the virtual network _EMSO is defined twice . While I have no confirmation that this relates to the federator issue, i guess it is unintended, as may make the interpretation of the definition difficult)

[kaestli]

The actual issue is: The start attributes of the <stream> elements of the GFZ-hosted <vnetwork/> are not ISO-8601 formatted timestamps (specifically: blank instead of Time designator T). In consequence, the federator fails parsing them.

[javiquinte]

Thanks @kaestli ! I've fixed the code to output proper ISO datetimes. I'll close the issue as it is clear now.

Final question: would the federator also support open starttimes? Or is it mandatory to fix one?

[kaestli]

A very good point, @javiquinte ! I wondered myself when I saw the open start dated of the previous _EMSO virtual network definition with open start time. I could not find an error related to this, but double checking on the code showed that this is probably only because the parser actually never got so far :-( While for the routes, the routing documentation refers to arclink routing xml . I have not found an xsd for that format (maybe @andres-h knows if there is one), however the seiscomp arclink implementation does require a non-null start date for a route.

However, this is no predetermination for the vnetwork object. One could well argue that as a virtual route refers to a physical route (which most probably) should have a starttime, and the physical route allows harvesting stationxml and availability information, for both of which a starttime is mandatory, the vnetwork itself does not need that time constraint. I'd suggest to clarify this in chapter 1.3.5 of the routing documentation.

Currently, the federator uses the same data object for physical and virtual stream epochs, and does NOT support open start dates. However, if considered useful, this could easily be approximated by "the beginning of time". In the further handling of route caches, the federator anyway intersects routes with stationxml stream epochs, to make sure that

• data is only returned as far as declared for EIDA,
• requests to end nodes are aligned with actually existing epochs, making station requests more streamlined and improving cacheability of responses.

[javiquinte]

Thanks @kaestli ! It was just a question because on the first definition we created the VN without start time. Now, to be 100% sure we have included it. I'll wait for the federator to refresh its content to start using this VN.

[kaestli]

Hi @javiquinte, virtual network definitions are harvested, GFZ http://[eida-federator.ethz.ch/fdsnws/station/1/query?network=_GFZALL](http://eida-federator.ethz.ch/fdsnws/station/1/query?network=_GFZALL) works now.