Open seismology lets an earthquake catalog change its mind

USGS geophysicist Robert Sickler and an AFAD employee install a nodal array in Gaziantep, Turkiye, in March 2024. The receding line of instruments makes the central problem visible: an earthquake solution is assembled from distributed observations, not read from one box. Photograph by Rufus Catchings, USGS.[11]

An earthquake catalog looks like a table of settled facts: time, latitude, longitude, depth, magnitude. The row hides its verbs. Instruments sampled motion; software identified possible phase arrivals; a locator fit those arrivals to a model of the Earth; an event-association process grouped successive solutions; an analyst or ranking rule chose one origin and magnitude to present first.

Open seismology is valuable because those verbs do not have to disappear inside one vendor's database. The International Federation of Digital Seismograph Networks defines shared web interfaces. ObsPy gives researchers Python objects for the returned waveforms, station inventories, and event catalogs. SeisComP operates a modular acquisition and monitoring system. QuakeML provides an exchange representation for event descriptions.[1][3][5][8] These projects overlap, but they are not interchangeable—and the seams between them are where a catalog remains correctable.

That distinction matters beyond software elegance. A peer-reviewed assessment of commonly used seismological products argues that catalogs and moment-tensor solutions are interpreted products rather than raw data, and that undocumented, unversioned changes can undermine reproducibility.[10] The open ecosystem cannot guarantee a good interpretation. It can preserve enough identity, metadata, and intermediate structure to let another team inspect how the interpretation was made.

The cover photograph shows USGS and AFAD staff laying out a nodal array in Gaziantep after the destructive 2023 Turkiye earthquakes.[11] The row of white instruments is a useful image for the software story: location comes from relationships among observations. No single node contains the finished event.

FDSN keeps three answers separate

The FDSN web-service baseline exposes three interfaces whose similar URLs conceal different kinds of evidence.[1]

fdsnws-dataselect returns time-series records in miniSEED.
fdsnws-station returns network, station, channel, and instrument-response metadata in StationXML.
fdsnws-event returns event parameters in QuakeML.

This separation prevents an easy category error. A waveform request answers, “What samples are available for these network, station, location, and channel codes during this interval?” A station request answers, “What instrument and response chain did those codes denote during that epoch?” An event request answers, “What solution did this data center publish for an interpreted event?” The third response may have been produced from the first two, but it is not another view of the raw recording.

FDSN compatibility also does not imply a central global database. Providers implement the shared interfaces over their own holdings, policies, and processing systems. ObsPy's Client can address many providers through one API, while its routing clients discover waveform and station data across supported federations.[3] Event identifiers and catalog contents remain provider-specific. A script that changes its data center has changed an evidentiary input, even when the Python call stays the same.

The result is a modest but powerful interoperability promise: clients can ask familiar questions and receive known formats. It is not a promise that every center has the same stations, latency, response detail, picks, or preferred origin.

The station epoch makes the samples interpretable

MiniSEED is compact because it is primarily a waveform-record format. The samples carry stream identity and timing, but full knowledge of the sensor and data logger lives with the station inventory. StationXML represents a hierarchy from network to station to channel to response, including time-bounded equipment epochs.[2] That time boundary is crucial. Reusing today's response for samples recorded under an earlier sensor configuration can produce a clean-looking but physically wrong trace.

ObsPy makes the pairing explicit. get_waveforms() produces a Stream of Trace objects; get_stations(..., level="response") produces an Inventory; and get_events() produces a Catalog.[3] To convert instrument counts into displacement, velocity, or acceleration, remove_response() needs the matching response information. It also requires analytical choices such as a frequency-domain pre-filter or water level to control amplification during deconvolution.[4]

Those choices are part of the result, not housekeeping. Response removal changes the data array in place. A reproducible workflow therefore keeps the downloaded miniSEED unchanged, saves the StationXML covering the same channel and time, performs correction on a copy, and records the ObsPy version plus filter parameters. Gaps and overlaps should be inspected before they are merged or interpolated. A beautifully plotted trace is weak evidence if its raw samples, response epoch, and processing history cannot be recovered.

This is where the OSS ecosystem earns its keep without pretending to be one application. FDSN standardizes access. StationXML gives the instrument history a portable structure. ObsPy makes the pair convenient to inspect and transform. None of the three decides whether a pulse is an earthquake.

SeisComP belongs in the operations room

For a research notebook, fetching a bounded interval after an event may be enough. A monitoring center has a different problem: continuous acquisition, archiving, automatic phase processing, database state, operator review, and the ability to replay old waveforms through a changed configuration. SeisComP 7.3.1 organizes those jobs as separate automatic and interactive modules rather than one executable.[5]

Its placement in the ecosystem is easy to draw backwards. A representative operational flow is station streams into SeisComP, then archive and catalog products out through FDSN services to clients such as ObsPy. SeisComP's fdsnws server can expose time series as miniSEED, station and response metadata as StationXML, and origin and magnitude estimates as QuakeML.[6] ObsPy is often downstream of that service boundary; it is not a required stage in SeisComP's live processing path.

This architecture permits two kinds of independence. Operations can keep a controlled internal database and message flow while publishing read-only standard interfaces. Researchers can retrieve the same outward-facing evidence with open clients without receiving database credentials or duplicating the monitoring center's runtime. The systems cooperate through formats and services instead of sharing one mutable store.

The boundary is not frictionless. A public FDSN response can be filtered, incomplete, or narrower than the internal object graph. SeisComP's own implementation notes, for example, that some standard query parameters are not implemented and that its event filters apply to the preferred origin or magnitude.[6] “Standards-compatible” should be tested as a matrix of actual provider capabilities, not accepted as a binary badge.

An event is a dossier of competing origins

The most revealing object in this map is not the waveform. It is the event.

A pick marks a proposed phase arrival on a stream. A locator combines picks into an origin estimate: an origin time and hypocenter under a particular travel-time model and configuration. As more phases arrive or an analyst revises picks, the same physical earthquake can acquire several origins. SeisComP's scevent associates incoming origins with events, can accept origins from other agencies, and selects preferred origins, magnitudes, and focal mechanisms according to configurable priorities.[7]

That design makes “preferred” a state, not a deletion command. Earlier origins can remain attached to the event while a newer automatic solution, a reviewed manual solution, or an agency-priority rule changes which one is displayed first. The association itself is also a hypothesis: scevent can compare origin time, location, and matching arrivals, then merge, split, or reassign event relationships when the evidence warrants it.[7]

This is more honest than treating the first alert as the permanent row. It also exposes operational policy. Parameters such as eventAssociation.minimumDefiningPhases and eventAssociation.priorities turn hidden judgment into inspectable configuration. The defaults are not universal scientific truths; a sparse regional network, a dense temporary array, and a global warning center have different failure costs.

The independent literature reinforces this boundary. Researchers studying widely used seismological products found that methodology, provenance, independence, and time-stamped preservation affect whether catalog-derived results can be compared or reproduced.[10] Open object models help, but only if operators retain the competing solutions and users capture the version they actually analyzed.

QuakeML moves the dossier—and exposes a conversion cliff

QuakeML 1.2 remains the stable version used by FDSN event services. Its basic event description represents structured seismological parameters rather than embedding the waveform samples themselves; broader QuakeML 2.0 packages remain under development.[8] In this ecosystem, QuakeML is the envelope that lets a catalog result leave one system as relationships and identifiers instead of a screenshot or a flattened row.

The envelope does not make every round trip lossless. SeisComP stores and exchanges its internal objects through its own data model and SCML representation. Its sccnv utility can export SCML event parameters to QuakeML 1.2, but direct QuakeML input is handled through versioned transformation tools. The documentation warns that non-standard objects, non-unique public IDs, missing parent references, and absent creation metadata limit conversion back into SCML.[9]

That asymmetry is a useful warning for every open ecosystem. A standard can preserve rich concepts without guaranteeing that two implementations assign the same meaning to every extension or identifier. The safe test is not “Can both tools open XML?” It is “After export and import, do the pick-to-arrival links, origin identities, agency and creation information, evaluation status, and preferred solution still mean what they meant before?”

Rehearse a revision, not just a download

A small evaluation can prove this ecosystem without building a monitoring center. Choose one well-documented public event and one station with available waveform and response metadata. Save the exact FDSN request URLs and raw responses for dataselect, station, and event. In ObsPy, load the waveform and inventory, inspect gaps, correct a copy into a named physical unit, and retain every processing parameter. Then compare the provider's event result with the underlying versioned artifacts rather than treating its latitude and magnitude as ground truth.

For an operations team considering SeisComP, the meaningful pilot is a playback. Feed a retained interval and matching inventory through a non-production configuration. Observe how picks produce origins, how successive origins attach to an event, how the preferred origin changes, and what the outward FDSN event response includes. Export the event to QuakeML, test the intended downstream consumer, and compare identifiers and relationships—not only the headline magnitude.

The adoption boundary should stay explicit. ObsPy is a strong fit for scripted retrieval, analysis, teaching, and reproducible batch work. SeisComP adds the machinery needed for continuous monitoring, but also adds inventory administration, archives, messaging, database operations, alert-quality review, and on-call responsibility.[5] A small research team should not install an operations center merely to read a catalog; a network operator should not mistake a notebook that worked once for a monitored, replayable service.

The deepest interoperability win is therefore not one seamless pipeline. It is the ability to preserve disagreement. Raw samples can remain raw. Instrument history can be corrected without rewriting the recording. New origins can supersede old ones without erasing them. A preferred catalog row can change while the evidence trail stays available. Open seismology makes an earthquake catalog more trustworthy by letting it revise its answer in public.

cronfeed.work