OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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


Subject: [OASIS Issue Tracker] (EMERGENCY-9) Extended resources to include supplemental geographic information


    [ https://tools.oasis-open.org/issues/browse/EMERGENCY-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37578#comment-37578 ] 

Art Botterell commented on EMERGENCY-9:
---------------------------------------

The real problem here, I think, is that we've failed to distinguish clearly between describing the event/threat and the alert/protective-action recommendation.  Are we describing where we observe/forecast actual events or where we want the alert presented.  Both jurisdictional boundaries and uncertainties conspire to make those less identical than they'd be in a perfect world.

I take full blame for that oversight in the original design.  Experience has taught me better since then.  This is a fundamental problem I think is worth discussing in some depth before we start tossing solutions against the wall.

I see no problem with adding <resource> and <parameter> elements to the Area block, but that by itself doesn't resolve this fundamental ambiguity.  The same problem arises in the question of asserting motion vectors... phenomena move continuously through space and time, but administrative choices like warning areas and texts move only at intervals, if at all.  We need to be able to distinguish clearly which we're describing with any given assertion.


> Extended resources to include supplemental geographic information
> -----------------------------------------------------------------
>
>                 Key: EMERGENCY-9
>                 URL: https://tools.oasis-open.org/issues/browse/EMERGENCY-9
>             Project: OASIS Emergency Management TC
>          Issue Type: Improvement
>          Components: CAP 
>            Reporter: Tony Mancuso
>              Labels: CAP
>
> Jacob Westfall; While CAP was never meant to be a GIS substitute, most alert messages have a need to better describe the geo information related to an incident.  To date the use of the area block to fulfill this role has been dubious.  As the spec says, area segments are used to describe the geographic area for which the info segment applies.  They are not used to describe elements of the incident like the incident site, evacuation route, etc and invalid workarounds like using circles with radius 0 to slip in a point value are cumbersome. I recommend extending the role of resources to include supplemental geographic information.  Resources are already filling this role for other types of information and this will keep the area segment from being misused.  Outlined below is an approach that could be considered, we have been using it through a namespace extension for over a year now with great results. In order to "geo enable" the resources block, the following simple geometry elements are added, point, line, polygon, and circle.  All using WGS84 with lat, lon and spaces between point values in lines and polygons, and between the point and radius in circles.  Also another element is added to resource blocks to allow for classification and automation, resourceType.  This new element allows for data layers, also known as profiles, to define a common list of classifications for resources and the info they contain.  The following MVA example illustrates the use of geo resources in an incident message:
> <resource>
>   <resourceDesc> Motor Vehicle Accident Site </resourceDesc>
>   <resourceType>
>     <valueListUrn> http://www.example.com/resources </valueListUrn>
>     <value> incidentLocation </value>
>   </resourceType>
>   <point> 1,1 </point>
> </resource>
> <resource>
>   <resourceDesc> Detour Route </resourceDesc>
>   <resourceType>
>     <valueListUrn> http://www.example.com/resources </valueListUrn>
>     <value> trafficRoute </value>
>   </resourceType>
>   <line> 1,1 1,2 1,3 1,4 </line>
> </resource>
> Geo resources can also take advantage of other resource elements like uri, perhaps when referencing an incident site the uri links to an image or video feed of the incident, or for any important locations like an evacuation route or shelter site the reference also includes a WAV in spoken word for sight impaired users. The resources block becomes very useful when it can fulfill this role of providing useful supplemental geo-information, while the area block remains as intended. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


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