Fix query stream epoch with time constraints

[damb]

Bugfix:

• Correctly handle cases where the routed epoch is a subset of the channel epoch.

[damb]

@kaestli,

one general question with respect to the interpretation of StationXML1.0 BaseNodeTypes' startDate and endDate attributes for child BaseNodeType elements. Even though, the xsd is not explicit on this topic, I assume that the corresponding definitions of child element attributes override the parent's definition.

E.g.

$ curl -s "http://eida-service.koeri.boun.edu.tr/fdsnws/station/1/query?net=6G&sta=ATIM&level=channel" > 6G.ATIM.stationxml

While the <Network></Network> element defines both startDate and endDate attributes, the corresponding <Station></Station> and <Channel></Channel> elements define the startDate attribute, only. The following questions arise:

• Should <Station></Station> and <Channel></Channel> elements consider the endDate attribute of their parent <Network></Network> element?
• Does a missing definition of the endDate attribute mean that endDate=None? Would endDate="" be a valid definition to override the parent element's definition?

[damb]

Note, that within the routing configuration file (e.g. http://eida.ethz.ch/eidaws/routing/1/localconfig) a definition such as end="" seems to be quite common.

[kaestli]

Without being part of an explicit standard, I guess it is implicitly understood that child element time constraints superseed parent time constraints. This is required to describe stations where specific streams are added after the setup of the station, or discontinued before the station is entirely dismantled, and for networks where individual stations are added later, or discontinued earlier than network start and end time. If the child element has a longer lifetime than the parent, this seems to hint at an error in the metadata (imho there is no obvious other interpretation of an open station in a closed network - if you interpreted this for a point in time, it would result in a station without network, which is conceptually not covered in StationXML). Also, there is no obvious way to tentatively "correct" this from a client's perspective, as either of the dates may be wrong. I propose to

• ship station data as it is (even if children survive their parents)
• allow waveform requests for periods with inconsistent metadata
• tell the network operator if we see such issues.

On endDate="" vs. [no endDate given]: A priori, one could assume two interpretations: enddate unknown, and "will never end". However, as the latter does not make sense, i would interpret the two situations identically as "enddate unknown, supposedly in the future"

[kaestli]

For the koeri case, as no waveform data is available for station ATIM after the end of network 6G, they have probably just forgotten to add an enddate to the station / its streams.

[damb]

Though, the entire net=6G is affected.

See: http://eida-service.koeri.boun.edu.tr/fdsnws/station/1/query?net=6G&level=channel