Reads objects (event, origin, etc) from a SC3ML file and sends the objects to the messaging system.
Send all objects from a SC3ML file. The default behavior is to add:
scdispatch -i test.xml
Send an update:
scdispatch -i test.xml -O update
Remove the objects:
scdispatch -i test.xml -O remove
Subsets of SC3ML Objects
It can be useful to import a subset of QuakeML objects, e.g. Origins from other agencies and then allow scevent to associate them to existing events (and possibly prefer them based on the rules in scevent) or create new events for the origins. If the event objects from a SC3ML file are not required to be sent to the messaging then either they should be removed (e.g. using XSLT) and all the remaining objects in the file added:
scdispatch -i test.xml
or the event objects can be left out of the routing table, e.g.
scdispatch -i test.xml \
--routingtable Pick:PICK, \
Arrival:ARRIVAL,Amplitude:AMPLITUDE, \
Origin:LOCATION,StationMagnitude:MAGNITUDE, \
StationMagnitudeContribution:MAGNITUDE, \
Magnitude:MAGNITUDE
Note
The routing table approach is slower, scdispatch still has to try to send to the invalid group for each object. It seems that it should be possible to route to Event:NULL or some other non used group but this seems to always result in another Event (the one in the source SC3ML) being sent and loaded. Is this a bug?
Testing
For testing it is useful to watch the results of dispatch with scolv or scxmldump. It is also useful to clean the database and logs to remove objects from persistent storage to allow repeated reloading of a file.
Note
The following will clear all events from the database and any other other object persistence. Modify the mysql command to suit your db setup.
mysql -u root --password='my$q1' -e "DROP DATABASE IF EXISTS seiscomp3; \
CREATE DATABASE seiscomp3 CHARACTER SET utf8 COLLATE utf8_bin; \
GRANT ALL ON seiscomp3.* TO 'sysop'@'localhost' IDENTIFIED BY 'sysop'; \
USE seiscomp3;source seiscomp3/trunk/share/db/mysql.sql;"
seiscomp start
scdispatch inherits global options.
show help message.
show version information
Use alternative configuration file. When this option is used the loading of all stages is disabled. Only the given configuration file is parsed and used. To use another name for the configuration create a symbolic link of the application or copy it, eg scautopick -> scautopick2.
Load given plugins.
Run as daemon. This means the application will fork itself and doesn't need to be started with &.
Enable/disable self-shutdown because a master module shutdown. This only works when messaging is enabled and the master module sends a shutdown message (enabled with --start-stop-msg for the master module).
Sets the name of the master-module used for auto-shutdown. This is the application name of the module actually started. If symlinks are used then it is the name of the symlinked application.
Sets the name of the master-username of the messaging used for auto-shutdown. If "shutdown-master-module" is given as well this parameter is ignored.
Verbosity level [0..4]. 0:quiet, 1:error, 2:warning, 3:info, 4:debug
Increase verbosity level (may be repeated, eg. -vv)
Quiet mode: no logging output
Limits the logging to a certain component. This option can be given more than once.
Use syslog logging back end. The output usually goes to /var/lib/messages.
Path to lock file.
Send log output to stdout.
Debug mode: --verbosity=4 --console
Use alternative log file.
Overrides configuration parameter connection.username.
Overrides configuration parameter connection.server.
Overrides configuration parameter connection.timeout.
Overrides configuration parameter connection.primaryGroup.
A group to subscribe to. This option can be given more than once.
Overrides configuration parameter connection.encoding.
Sets sending of a start- and a stop message.
List all supported database drivers.
The database connection string, format: service://user:pwd@host/database. "service" is the name of the database driver which can be queried with "--db-driver-list".
The configmodule to use.
Load the inventory database from a given XML file.
Do not use the database at all
File to dispatch to messaging.
Notifier operation to use if not given: add, update or remove. If the XML contains notifier objects then this operation is used. If just plain objects are given, the operation needs to be specified. The default is "add".
Specify routing table as comma separated list of object:group pairs, e.g. "Origin:LOCATION,Arrival:ARRIVAL".
Print names of routable objects.
Test mode. Does not send any object.