Query about confidence ellipsoids

[calum-chamberlain]

Kia ora team,

A student highlighted an inconsistency in the uncertainties provided for a couple of events:

from obspy.clients.fdsn import Client

client = Client("GEONET")
event = client.get_events(eventid="2023p767004")[0]
print(f"Max horizontal uncertainty: {event.preferred_origin().origin_uncertainty.max_horizontal_uncertainty}")
print(event.preferred_origin().origin_uncertainty.confidence_ellipsoid)

Returns:

Max horizontal uncertainty: 5006.111771
ConfidenceEllipsoid
	        semi_major_axis_length: 5832650.484
	        semi_minor_axis_length: 0.0
	 semi_intermediate_axis_length: 3399539.047
	             major_axis_plunge: -0.0
	            major_axis_azimuth: 155.7513104
	           major_axis_rotation: 0.0

The units for these values should be SI (m), but the confidence ellipsoid seems inconsistent with the stated horizontal uncertainties. I wondered if something had gone wrong parsing from SC3ML to QuakeML or somewhere else in the chain?

[pasansherath]

@calum-chamberlain Thanks very much for the query - helped us identify a bug in converting SCXML to QUAKEML in SeisComp. We will notify about this to Gempa.

In SCXML files, the uncertainty ellipsoid units are in meters, but when they are converted to QUAKEML using the stylesheet in SeisComp, they are multiplied by 1000, and hence the very large numbers you see.

We suspect this has been happening for events located with LOCSAT from ~2018-10-10 for using both NLL (https://service.geonet.org.nz/fdsnws/event/1/query?eventid=2018p760856) and LOCSAT (https://service.geonet.org.nz/fdsnws/event/1/query?eventid=2018p763141).

Whilst we figure this out with GEMPA, there are two options for you:

1. With QUAKEMLs, divide the axes lengths of the ellipsoid by 1000 and the unit will be in meters.
2. Download SCXMLs from the bucket (e.g., http://seiscompml07.s3-website-ap-southeast-2.amazonaws.com/2023p767004.xml). This would be my preferred option :-)

Hope this helps! Please let us know if you have any more information regarding this issue.

Cheers

[salichon]

Sent a ticket to Gempa to discuss and address this question

• https://forum.seiscomp.de/t/locator-confidence-ellipsoid-parameters-quakexml-and-seiscompxml-unit/4032

FYI @calum-chamberlain @pasansherath

[salichon]

a XSLT fix is proposed (conversionsheet) as in
https://forum.seiscomp.de/uploads/short-url/vKuK8XEiraqGbQz2tkhznzmXv2C.tar

• Download and test
• Valid the fix - feed back Gempa
• Follow up with a fix in $SEISCOMP_ROOT/share/xml/ in seiscomp releases
• Follow up for propagating the fix in our services.
  (Create ticket ... )

NB a change in the stylesheet ellipsoid units occurred in 08.2017 it looks like we revert it back. now
FYI @pasansherath

To be tested still 2024 Aug.

[emilyws1]

@pasansherath @salichon @calum-chamberlain

Further to this issue raised above, there is also another instance whereby the latitude and longitude uncertainties are inconsistent with the units given for the horizontal uncertainties.

I believe the origin uncertainties are too small (given in km) rather than in metres. This is different to the issue raised by Calum above where the uncertainties have been incorrectly multipled by 1000, rather some examples exist of them being divided by 1000. The issue seems to be widespread, though I haven't looked into the time period it affects.

An event example is: 2018p132507

from obspy.clients.fdsn import Client

client = Client("GEONET")
event = client.get_events(eventid="2018p132507")[0]
print(f"Max horizontal uncertainty: {event.preferred_origin().origin_uncertainty.max_horizontal_uncertainty}")
print(event.preferred_origin().origin_uncertainty.confidence_ellipsoid)
print(f"Latitude uncertainty: {event.origins[-1].latitude_errors.uncertainty}")
print(f"Longitude uncertainty: {event.origins[-1].longitude_errors.uncertainty}")

returns:

Max horizontal uncertainty: 7.434938502
ConfidenceEllipsoid
	        semi_major_axis_length: 11.48772057
	        semi_minor_axis_length: 4.294251743
	 semi_intermediate_axis_length: 7.526263248
	             major_axis_plunge: 142.2719735
	            major_axis_azimuth: -20.77884346
	           major_axis_rotation: 91.00429164
Latitude uncertainty: 2.724444892
Longitude uncertainty: 4.673446065

Here you can see that the horizontal uncertainties indicate (if given in the standard units of metres) an uncertainty of a few metres. This is suspiciously small, and is inconsistent with the latitude and longitude errors, which are listed as 2.7 and 4.7 km on the quakesearch webpage.

[pasansherath]

@emilyws1

Thanks very much for raising the issue. We have identified the issue here to be with the default style sheet not performing the expected unit conversions when going from seiscompxml to quakeml.

seiscompxml uses kilometer for origin depth uncertainty, origin uncertainty and confidence ellipsoid, quakeml uses meters for these.

We have raised this issue with Gempa and we will apply a fix once we receive a correct style sheet to use.

Please let us know if you have identified other issues in the quakemls.

Ref:

• https://github.com/GeoNet/tickets/issues/16524

[salichon]

Updated into Gempa community forum
Fix to come

[salichon]

@pasan @calum-chamberlain @emilyws1
update 2024 October:

• One XML schema fix is coming in the next release of seiscomp V6.5
  ( i.e. Fix unit conversion for confidenceEllipsoid in QuakeML exporter.)
  https://github.com/SeisComP/seiscomp/blob/master/CHANGELOG.md#650
• GeoNet shall move into that version in a reasonable timing hence any new events
  will get updated in Quakexml with right units
• Seiscompxml Back computing/conversions to newer/corrected quakexml versions (hence with fixes)
  was discussed and so far agreed - Now Process to detail and operate (over ~700k event files -ish)

For test conversion see : SeisComP/common@bec4834