hrotman-pic
commented
1 week ago After discussion in the PH5 group, a code solution is not ideal given anticipated complexities and the current state of PH5 development. Documentation is the appropriate way to prevent this case.
A potential way for a user to create a nodal PH5 that cannot be valid is the following:
Line 5, station 2002, at coordinates x,y,z, recording from deploy time A to pickup time B Line 5, station 2002, at coordinates a,b,c, recording from deploy time A+3 days to pickup time B+2 days
The deploy time to pickup time may have less overlap or more overlap than this example. The coordinates x,y,z and a,b,c may be 2 km or 200 km apart. The data from both are in DAS table 5X2002. PH5's ability to look up and extract the 'correct' timeseries in this case is questionable, even if the array table is edited to assign different station IDs. Even if ph5toms, ph5toevt, ph5torec would work correctly on this type of dataset, the manner in which a stationXML is built from PH5 metadata means the stationXML for this type of dataset would never be valid unless the station IDs were reassigned (see #402 ) because all channels of a station must be at the same coordinates. The functionality of ph5toms, etc. with this type of dataset is doubtful and likely difficult to test.
Note: A community user who had a PH5 with this case reported ph5_validate errors even when the station ID and/or SEED station name were changed in the array table.
Updated nodal PH5 documentation should have a note about this case. I am also wondering if there is a way to prevent it in the codebase as well and if implementing that is a reasonable solution.