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://issues.oasis-open.org/browse/EMERGENCY-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48554#comment-48554 ] 

Steve Hakusa commented on EMERGENCY-9:
--------------------------------------

From https://www.oasis-open.org/apps/org/workgroup/emergency-cap/download.php/53971/Aug25-2014-meeting-notes.doc

Jacob provided an overview of the issue as it was a comment he had submitted some time ago.  The original intent was to suggest a method to include supplemental geo info without significantly altering the existing CAP elements.  He is now suggesting this issue can be closed because it will be addressed by event location.  However this issue's examples did offer some typing of the geo info and that could be added to the use cases for event location.  Steve Hakusa asked about the proper use of resources as he noted some conflicting uses as evidenced by this issue.  Steve also noted that this suggested method for adding geo information is somewhat related to issue 8.  Gary Ham raised a concern about whether geo information can be added using resources.  Jacob clarified his comments by noting that geo information, like a KML file, can already be referenced in a CAP message.  Jacob suggested that resources can stay as they are and this issue sets a precedent for the scope of how references should and should not be used.  Steve raised a concern that this precedent will apply to all future suggestions to modify references and Jacob clarified that while geo info shouldn't go into references, other proposals that use references should still be considered when they arise.

The motion to resolve issue 9 as “no action needed”, add the typing examples to event location, and close it in JIRA, was put forward.  Gary moved and it was seconded by Elysa.  Doug, David, Rex, Gary, Elysa, Norm, and Jacob agreed with the motion, Steve abstained, and it passed.

> Extended resources to include supplemental geographic information
> -----------------------------------------------------------------
>
>                 Key: EMERGENCY-9
>                 URL: https://issues.oasis-open.org/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]