QuakeML `filterID` property prefixed with resource identifier

[damb]

Hi devs,

I noted that properties such as e.g. the pick's filterID are prefixed with the resource identifier when the output is exported to QuakeML. The properties are not prefixed when exporting to Trunk (i.e. SeisComP ML). Is this behaviour desired? If yes, why?

Note that once filter identifiers are prefixed, they cannot be used straight away with SeisComP's filter factory facility. That is, the prefix needs to be removed again before creating a filter , since otherwise the filter identifier is invalid in the context of the SeisComP filter grammar.

[damb]

CC @mmesim

[gempa-jabe]

The behaviour is intended because QuakeML requires the prefix for external resource identifiers such as publicID. I don't like it and I don't support it but it is a requirement of QuakeML and therefore we prefix the external resource identifiers with smi://. When importing to SeisComP one would need to remove the prefix again.

[damb]

Well, AFAIK, SeisComP does not implement QuakeML importing facilities.

When importing to SeisComP one would need to remove the prefix again.

AFAIU, this is not handled by the Trunk deserializer, yet. The current implementation is simply based on IO::XMLArchive. Ideally, this is handled within DataModel::Pick::serialize(), correct?

Backround: I originally sumpled over the issue, since the obspy client get_events() method downloads the data from endpoints by default with format=xml (i.e. QuakeML). Data is converted while dumping the catalog. However, the resource identifier seems not to be removed from the filterID when dumping to SC3ML. On the other hand, when serializing event parameters to Trunk with SeisComP the filterID is not prefixed. Hence, there is the mismatch.

[gempa-jabe]

SeisComP does not add this prefix. Only the QuakeML exporter does that. Which tool is converting the data to SC3ML in your toolchain when you say that SeisComP does not implement QuakeML import facilities? We provide an xslt to do the conversion but I am not sure right now if that removes the prefix.

[gempa-jabe]

Ideally, this is handled within DataModel::Pick::serialize(), correct?

No, we do not make any assumptions about the content of filterID or anything else. When the XML contains something prefixed with smi:// then we take it as such. The deserializer does not modify anything. That is not its job.

[damb]

SeisComP does not add this prefix. Only the QuakeML exporter does that.

Well, the QuakeML exporter is part of SeisComP.

Which tool is converting the data to SC3ML in your toolchain when you say that SeisComP does not implement QuakeML import facilities?

obspy. My assumption is based on the fact that there is nothing like a Seiscomp::QML::Importer. Maybe, I missed something here (see below).

We provide an xslt to do the conversion but I am not sure right now if that removes the prefix.

Oh, this wasn't clear to me. Thanks for pointing this out.

[damb]

Does this mean that the filterID property in SC3ML must not contain the resource identifier? In this case it would be an obspy issue.

[gempa-jabe]

Actually we don't have strict requirements on filterID. For convenience we store the filter string there as it is self-explanatory and it can be used to construct a filter in SC3. You can populate this attribute with whatever string you like, prefixed with anything or not. If the QML exporter adds the prefix then the SC3ML should remove it to support the round trip.

[damb]

Ok, the roundtrip seems to be supported when performing the conversion with https://github.com/SeisComP/common/blob/8ef3176/libs/xml/0.11/quakeml_1.2__sc3ml_0.11.xsl. Hence, we can close this issue.

Sorry for the noise, @gempa-jabe.

[jsaul]

This is not an unimportant topic and has been a source of confusion in the past. Therefore it is good to have this issue here for future reference, so thanks a lot to both of you! @damb @gempa-jabe