« Back to User Guide
This is a list of known products being sent via Product Distribution.
Most products provide information about one event. The existence of one of these products in an event will change the way the indexer indexes, and they are generated by administrative users who need to override the default association/processing logic.
A product is a specific version of any content produced in response to an earthquake, information about an earthquake, or another product.
A product usually consists of a directory of files, but may also include a stream of bytes, links to internet resources, and key/value pairs.
The source, type, and code uniquely identify a product and its associated content. Update times indicate different versions of the same product, and products with more recent update times supersede products with less recent update times.
code, but different
update times are different versions of the same product.
A brief status code. Typically
Any value that is not
DELETE is considered an update.
When a product producer deletes a product they send an update
with a status
DELETE, which is distributed like any other
Contents are optional, but are usually present when the status is
DELETE. Each content has a path, which corresponds to a
Each product may have one piece of content that is a stream of bytes. It has an empty path and isn't stored in a file. Typically this content is read from standard input, and also delivered to consumers via standard input.
A product may include links to other products and resources. Links have a relation, which specifies how the resource is related to the product. There may be multiple links for each type of relation.Properties
Key value pairs. Each property may only have one value. These can be used to determine whether further processing is required. "Standard" properties include:
All of these properties are optional, but a combination of either
longitude are recommended for
event-related products for association purposes.
Producers generate a signature which may be verified by both hubs and consumers. The signature consists of a hash of all product contents and attributes, which is encrypted using a private key and verified using a public key.
Production hubs require a signature, and a keypair must be registered before products are sent.
The information contained in this section is a recommendation, not a requirement however recommendations can be seen as a best practice when generating new products.
Properties should be defined for important attributes of your product. They allow recipients to quickly determine whether they should process a product, without extensive parsing.
are used by the indexer to associate a product with an event. Other
dyfi number of responses,
alert level, and
shakemap maximum MMI.
Products may have properties that are specific to that product type. For example, the origin product has a custom azimuthal-gap property. Like all product properties, these properties are set using name/value pairs, using either command line Java parameters on a product send, or within a node of an XML file sent with the product.
These properties aren't pre-configured using INI files like config.ini, however they often need programmatic support, such as identifying which XML file and node contains a custom property. For this reason, please contact email@example.com in advance before creating a new product type.
It is recommended you include with your product a “contents.xml” file. This file describes all of the contents you are sending with your product. It helps the web page to better display your product and ultimately determines what content users will be able to easily download from the web site.
The contents.xml file format is defined with a contents.xsd file. You must understand how to read XML schema (XSD) files in order to properly generate a contents.xml file.
When mapping products into PDL, it is important to consider how content is generated and updated when deciding what individual products should contain.
For event-related products, the group of content is everything related to that event.
For non-event-related products, the group depends more on how content is generated and updated. For example, station related content might be broken up by station. It's possible that this content would need to be further divided based on update intervals.
code must be unique forever, from the same
type. Product creators also reuse
code to update or delete the product.
For event-related products, an eventid makes a good code because
it also must be unique forever. Examples include :
For non-event-related products another ID scheme is required. Timestamps are often useful in this situation when the products are related to a time window.
An internal database key can be used.