search

EIDA / userfeedback

This repository is meant to collect feedback from EIDA users by means of its Issue Tracker
11 stars 5 forks source link

Overlapping channel epochs NO.ARC2.00.BH? #61

Closed damb closed 4 years ago

damb commented 4 years ago

Station ARC2 which is part of the NO network has some overlapping channel epochs defined w.r.t. its BH? channels. The corresponding fdsnws-station URL is:

http://eida.geo.uib.no/fdsnws/station/1/query?net=NO&sta=ARC2&cha=BH?&level=channel

Except of it is a different station/channels the issue is similar to #60.

flixha commented 4 years ago

I had also reported a set of metadata issues for NO-stations to our EIDA node maintainer at UiB, and he received an update for these metadata about 2 weeks ago that are all online since. So the issue regarding ARC2 and BRBA should be resolved now, while there is a smaller set of issues remaining. But these are a lot less than before and I have reported them all to the maintainer @jan-michalek.

javiquinte commented 4 years ago

Hi @damb Could you confirm that this has been solved? Thanks!

damb commented 4 years ago

The definition is adjusted. Though, I still have an additional question. The channel epochs defined with

<Channel code="BHE" startDate="2014-09-17T12:00:00" endDate="2016-09-27T13:20:00" restrictedStatus="open" locationCode="00"></Channel>
<Channel code="BHN" startDate="2014-09-17T12:00:00" endDate="2016-09-27T13:20:00" restrictedStatus="open" locationCode="00"></Channel>
<Channel code="BHZ" startDate="2014-09-17T12:00:00" endDate="2016-09-27T13:20:00" restrictedStatus="open" locationCode="00"></Channel>
<Channel code="BHE" startDate="2016-09-27T13:20:00" restrictedStatus="open" locationCode="00"></Channel>
<Channel code="BHN" startDate="2016-09-27T13:20:00" restrictedStatus="open" locationCode="00"></Channel>
<Channel code="BHZ" startDate="2016-09-27T13:20:00" restrictedStatus="open" locationCode="00"></Channel>

come along with an endDate of "2016-09-27T13:20:00" which matches exactly the startDate of the subsequent channel epochs. Call it pedantic, however, it is not clear which channel epoch definition is valid at "2016-09-27T13:20:00". Are metadata definitions as above common practice?

javiquinte commented 4 years ago

Hi @damb It is not pedantic at all. I fully support this observation. There is an overlap of one sample, which should not be so dramatic, but, just as an example, it is forbidden in the Routing Service.

damb commented 4 years ago

Well, then there might be more channel epochs affected within EIDA.

As an example: http://orfeus-eu.org/fdsnws/station/1/query?net=NL&sta=L2081&level=channel

jan-michalek commented 4 years ago

@javiquinte: This is actually still confusing me. Time resolution in start/end date does not allow go to sample resolution but there might be data existing in the "gap" period. There shouldn't be any data usually since there must be gap between the new changes come into play. So one should use 1 sec difference at least to have correct end/start times?

javiquinte commented 4 years ago

Hi @jan-michalek You have a good point there! I'll need to relax the Routing Service way to treat overlaps. Thanks(?) for pointing this out... :facepalm: Open/closing an epoch does not automatically imply that you will have a gap. And within this second you could probably have more than one miniSEED record. I'll post this in the ETC list for discussion.

damb commented 4 years ago

@javiquinte, from an fdsnws-station user's perspective defining overlapping channel epochs (as above) is not reasonable. In fact, there should be a gap defined. Though I understand @jan-michalek's point. Actually, it would be better to allow the definition of startDate and endDate at sample resolution. IMO the cleanest way defining channel epochs.

javiquinte commented 4 years ago

@damb , I fully agree with you... 100%. Only that the gap is not mandatory. I'll post this in the ETC list to have an internal discussion.