Problem reading in data for regional example

[davidfee5]

I get an error when trying to read in data in example_regional.ipynb:

/opt/miniconda3/envs/rtm/lib/python3.10/site-packages/obspy/core/utcdatetime.py in init(self, *args, *kwargs) 404 # patterns and pass it directly to Python's datetime.datetime 405 if not ''.join(parts).isdigit(): --> 406 dt = datetime.datetime(args, **kwargs) 407 self._from_datetime(dt) 408 return TypeError: 'str' object cannot be interpreted as an integer

[liamtoney]

Very weird. Is that the full traceback? Maybe we are feeding a badly formatted date internally in the code. Assuming this is a change introduced in ObsPy...?

[davidfee5]

Seems like an issue with the call to waveform_collection https://github.com/uafgeotools/waveform_collection/blob/2c53746c56970e482e0bcbc6a8be7527c0a82218/waveform_collection/server.py#L342. Not exactly sure what changed or why this isn't working

[davidfee5]

Huh, it works when I specify actual networks in the gather_waveforms_bulk call, but not when using the asterisk wildcard for the network. Perhaps this is an issue with actual IRIS metadata?

[liamtoney]

~I wonder if it's a positional vs. kwargs thing. Looks like ObsPy is trying to parse a string as a datetime and failing...~

Actually, it seems to be a metadata issue as you suggest. But not for all data, just some networks. I'll try to figure out which is the culprit...

[liamtoney]

Okay, found it. It's actually a single sensor which has CalibrationDate metadata that are not properly handled by ObsPy:

read_inventory('http://service.iris.edu/fdsnws/station/1/query?net=GS&sta=ASA1&loc=33&cha=LDF&level=channel&format=xml')

[aringler-usgs]

I believe we (ASL) produces the metadata for this station. @jholland-usgs are you seeing an issue with this on our side or is this valid metadata?

[ghost]

Appears to be a bug somewhere between where IRIS pulls from SIS and where it is published on the FDSN server. I'll email someone at IRIS.

The metadata from IRIS's FDSN has an extra CalibrationDate tag. http://service.iris.edu/fdsnws/station/1/query?net=GS&sta=ASA1&loc=33&cha=LDF&level=channel&format=xml

<Sensor>
<Type>JEFFREY JOHNSON</Type>
<Description>Pressure</Description>
<Manufacturer>JEFFREY JOHNSON</Manufacturer>
<Model>INFRAVOLC V2</Model>
<SerialNumber>3037</SerialNumber>
<CalibrationDate>
<CalibrationDate>2021-01-07T00:00:00.0000</CalibrationDate>
</CalibrationDate>
</Sensor>

Metadata as published on SIS ( https://files.anss-sis.scsn.org/production/FDSNStationXML1.1/GS/GS_ASA1.xml ) looks fine.

<Sensor>
<Type>JEFFREY JOHNSON</Type>
<Description>Pressure</Description>
<Manufacturer>JEFFREY JOHNSON</Manufacturer>
<Model>INFRAVOLC V2</Model>
<SerialNumber>3037</SerialNumber>
<CalibrationDate>2021-01-07T00:00:00+00:00</CalibrationDate>
</Sensor>

[liamtoney]

Thanks. I'll let the ObsPy folks know that their code is not the problem.

[ghost]

@davidfee5 The FDSN service appears to be formatted correctly now. So you may want to give it another try. Let me know if you run into any more issues with USGS produced metadata or data.

[liamtoney]

Okay, found it. It's actually a single sensor which has CalibrationDate metadata that are not properly handled by ObsPy:

read_inventory('http://service.iris.edu/fdsnws/station/1/query?net=GS&sta=ASA1&loc=33&cha=LDF&level=channel&format=xml')

This call works now. Thanks @jholland-usgs and @aringler-usgs!