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.
source and type
combination.source, type, and code,
but different update times are different versions of the
same product.A brief status code. Typically UPDATE or DELETE.
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
product.
Contents are optional, but are usually present when the status is
not DELETE. Each content has a path, which corresponds to a
filename.
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.
PropertiesKey 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
eventsource and eventsourcecode OR eventtime,
latitude, and 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.
For example, eventsource and eventsourcecode
are used by the indexer to associate a product with an event. Other
examples include dyfi number of responses, losspager
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 jmfee@usgs.gov 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.
A product code must be unique forever, from the same
source and type. Product creators also reuse
the 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 : us2011abcd
and nc12345678.
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.