OASIS Emergency Management TC

Earthquake Report (A.3) Example: Questions -- typo, etc.

  • 1.  Earthquake Report (A.3) Example: Questions -- typo, etc.

    Posted 03-31-2004 20:45
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: Earthquake Report (A.3) Example: Questions -- typo, etc.


    At PubSub.com, we've been trying to take live USGS earthquake data and
    faithfully produce CAP messages based on our reading of the CAP
    specification, including the example of earthquake data which is given
    within it. Some questions have arisen in this project...
    
    For instance, the sample earthquake report given in A.3 of CAP
    includes the following line:
    
        <parameter>Magnitude=3.4 Ml</parameter>
    
    	We are a bit mystified about the "Ml" in the "value" portion
    of the name/value pair here. Clearly, the intention is to communicate
    that the magnitude of the reported earth quake was "3.4", but what is
    the "Ml"? In actual USGS data, we sometimes see "M" used in this
    context, but never "Ml"... Is this a typo? (Note: We're now pumping
    out large numbers of messages with the " Ml" in them and people keep
    asking me what the "l" is for. Please help me explain this. It is
    getting embarrassing to not have an answer...)
    
    	Additionally, I would like to mention that "values" such as
    "3.4 Ml" are unnecessarily hard to match against or prepare for
    insertion into a database since they are strings whereas most
    applications will want to treat them as numbers. In this case, it is
    necessary to strip the " Ml" from the value to prepare the value for
    processing in most applications. Unfortunately, the " Ml" doesn't seem
    to provide any information that is not redundant, since the "name"
    part of the parameter clearly marks the value as a "Magnitude". This
    increase in the complexity of processing, as well as the requirement
    to do micro-parsing on the fields, will inevitably increase the costs
    of implementing CAP as well as increasing the opportunity for interop
    problems.
    	Yes, this is another call for the use of attributes... The way
    that the USGS encodes these values in their own XML feeds[1] is the
    rather sensible:
    
    	<param name="magnitude" value="3.4" />
    
    	If one wanted to be sure that the unit of measure (i.e. the
    "Ml") was communicated, then you could do something like:
    
    	<param name="magnitude" value="3.4" unit="Ml"/>
    	Such an attribute based approach can, of course, be shown to
    handle anything that could have been done with the current "="
    delimited name/value pairs.
    
    		bob wyman
    
    [1] ftp://ghtftp.cr.usgs.gov/pub/cnss/merge_14.xml
    
    


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]