sc3ml to Inventory

[megies]

Hi,

I've started writing a routine that can directly import Seiscomp3 sc3ml (in addition to stationXML) to an Inventory class. Before spending more time, I would like to discuss if there currently exists an easy way to import sc3ml format to Obspy? And would the option to import sc3ml to Inventory be a valuable addition to ObsPy?

Like to hear your thoughts on this!

[megies]

I have a stylesheet to convert seiscomp3 xml to QuakeML: https://github.com/barsch/seishub.plugins.seismology/blob/master/seishub/plugins/seismology/xslt/seiscomp2quakeml.xslt

That would be an option, with lxml it's only a few lines of code to transform to QuakeML string we can read:

from lxml import etree
doc = etree.parse("gof2014ckob.last.xml")
doc_xslt = etree.parse("seiscomp2quakeml.xslt")
xslt = etree.XSLT(doc_xslt)
result = xslt(doc)
xml = etree.tostring(result, encoding="UTF-8", method="xml", xml_declaration=True, pretty_print=False)
cat = read_events(xml, "QUAKEML")

I just tried it and the result had a couple of schema breaches.. strange. But it should be pretty easy to correct/figure out.

Would certainly not hurt ot have a seiscomp xml reader in obspy.. probably a corrected version of the xslt would be the simplest option..

[Jollyfant]

Hi Megies, what you linked seems not to deal with station metadata and response information (e.g. stages, paz, FIR coefficients). I intend on parsing sc3ml station metadata (similar to stationXML) to an Inventory.

Here's an example from the GFZ fdsnws webservice of the data I want to put in an Inventory:
http://geofon.gfz-potsdam.de/fdsnws/station/1/query?sta=KBU&level=response&format=sc3ml

[megies]

Oh, sorry, didn't read properly and was thinking event metadata immediately.. In any case, I'd ask the seiscomp guys if they have a conversion routine in python (or C) before doing anything else.

[Jollyfant]

Seiscomp has internal functionality to load stationXML and print sc3ml, however this is not a standalone routine and requires SC to be installed. I will work on a separate branch to try and include a way to load sc3ml to ObsPy Inventories.

Edit: branch can be found here https://github.com/Jollyfant/obspy/tree/io.sc3ml

[Jollyfant]

The branch has been updated with a working prototype* including unit tests. Currently, only reading from sc3ml to Inventory is implemented, might work on writing in the future.

Usage is obspy.core.inventory.read_inventory("./path/to/file", format="SC3ML")

The unit tests load a full response stationXML and sc3ml for a network (EB) and writes the input back to XML using obspy.core.inventory.write. The output from this write method is compared between the two and should match to a certain extent. Some things are inherently different between the formats.

In most cases there will be slight difference in the output. For example, the station town tag may be missing for stationXML, while it is included for sc3ml. On the other hand, sensor type may be missing for sc3ml while included in stationXML. This should be easy to see using a diff command in the shell.

https://github.com/Jollyfant/obspy/tree/io.sc3ml/obspy/io/sc3ml

*At least I think it is working 👍

[megies]

remove..

[megies]

Made this into a PR from the branch you mentioned..

[Jollyfant]

Ok, I'm going to do some more assert checks and remove that little print statement.

[QuLogic]

For example, the station town tag may be missing for stationXML, while it is included for sc3ml.

That's part of the Site element, I think.

[Jollyfant]

@QuLogic, that is right. It's just that sc3ml seems to be a little more verbose when it comes to site meta-data:
sc3ml
stationXML

[krischer]

Sorry for this taking so long. I polished it a bit and sent a PR with small changes to your branch. Once you merge it we can finally merge this PR! Thanks a lot for this!

[megies]

Without having actually tried it, this looks good indeed. I have a few minor remarks:

• To be consistent with the rest of the code base, could you please replace """ comments (e.g. https://github.com/obspy/obspy/pull/1182/files#diff-6fe65029cbce7af6392c081b3b988b1fR384) in the code by lines starting with #?
• Right now this is placed as obspy/io/sc3ml/core.py. What about making this obspy/io/seiscomp/sc3ml.py? Right now it wouldn't make much difference.. but if anybody addes more seiscomp related I/O stuff in the future we have a common folder for it and don't need another one in parallel. Opinions?

[Jollyfant]

Updated the comments so that should be passing soon. I guess we can merge it in to a separate io seiscomp module down the line if more stuff is rolled out but for now this seems to be OK if you ask me.

[krischer]

If you plan on renaming this module later down the road, please rename it now. It is always a huge hassle to rename things if people are already using it.

[Jollyfant]

Ok, let's do it then 👍

[megies]

Ok, let's do it then 👍

Thanks, and sorry about the hassle, but we really need to get things right with the first shot, otherwise we end up with more deprecation/reroute pain later.. ;-) And I think this hierarchy makes sense even if it turns out that nothing gets added later in addition..

[Jollyfant]

Uh, something went wrong with the Travis build. Looks like a timeout or something? Is it possible for someone to retry the build without pushing a new commit or pull request.

[megies]

Is it possible for someone to retry the build without pushing a new commit or pull request.

Yes that's possible for us, and I guess somebody already restarted the build in the meantime..

[krischer]

Great! Thanks for this :-)

[megies]

Great! Thanks for this :-)

👍 nicely done!