weird behaviour StationXML start and end dates

Users Mailing List Archive
1

Dear all,

I just came accross some strange behaviour of the creation_date and termination_date within inventory objects read from StationXML.

For some StationXML files (I cannot yet say which ones), the printed creation_date and termination_date are not identical to the returned ones. For example, there is one StationXML file which I created in the following way

inv = read_inventroy(‘dataless SEED’) # read a dataless SEED into inventory object
inv.write(stationxml, format=‘STATIONXML’) # write inventory object into StationXML file

For this particular file the creation_date printed on the screen and the creation_date returned with the .creation_date function are not identical:

inv.select(station=‘station’)[0][0]
will print me the station summary read from the StationXML including the correct installation date of the station.

However,
inv.select(station=‘station’)[0][0].creation_date
will return the date at which the original dataless SEED file was created and not the corretly printed installation date of the station. This is a reproducible error.

Most of the StationXML that were created using inv.write() after downloading via ObsPy webservices implementation do behave correctly, though. Yet not all of them. For some stations I run into troubles also with the termination_date. E.g. sometimes

inv.select(station=‘station’)[0][0]
prints the correct installation and removal date on screen but

inv.select(station=‘station’)[0][0].termination_date
will return only “None”

I cannot tell though if there is some kind of systematics behind it, since only few stations are affected and all of the metadata was downloaded via obspy webservices implementation and directly written into StationXML. For what I can tell all stations affected by the termination_date bug above have more than one entry within the StationXML, each of them representing a separate instrumentation epoch.

What I can reproduce safely is the wrong returned creation_date (although the printed one is correct) for StationXMLs that were created with ObsPy via reading from a dataless SEED.

Best,
Florian

_____________________________________ Dr. Florian Fuchs Department of Meteorology and Geophysics University of Vienna UZA II, 2D508 Althanstraße 14 1090 Vienna Austria Phone: +43 1 4277 53726 Mobile: +43 664 60277 53726 www: http://imgw.univie.ac.at _____________________________________

2

Hi Florian,

I think you are mixing up some of the times.

The string representation of Station objects within ObsPy contains the start_date and end_date fields (or StartDate and EndDate in the StationXML). These correspond to the “Start effective date”, “Start date”, … and so on fields in the SEED blockettes and denote the start and end of epochs. The end dates might be None if an epoch is still active. They also exist at each level, e.g. network, station, and channel.

Stations in StationXML files also have CreationDate and TerminationDate (creation_date and termination_date in ObsPy’s mapping) attributes which are independent of epochs and should denote the full life time of stations. These are not available in SEED files and so ObsPy should not set them when reading SEED files.

I just realized that ObsPy, when reading SEED files, sets the creation date to either the SEED volume time if available or the the current time. This is wrong and we’ll fix it.

When reading StationXML files, for example from web services, all the dates should be set correctly.

I hope this clears up the confusion.

Best,

Lion

3

Hi Lion,

thanks for the quick reply and the clarification. I indeed misinterpreted creation_date and termination_date … these were the only two times listed in the documentation:

https://docs.obspy.org/packages/autogen/obspy.core.inventory.station.Station.html#obspy.core.inventory.station.Station

Best,
Florian