MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency] CAP Visualization (was RE: CAP Developers' Forum...)
Hey Kwasi,
Since <event> is a required field (of an <info>) but is
free text, and <eventCode> is optional and
system-specific, we're not left with much if we want
to filter messages based on event, are we?
oh well.
-jeff
On Wednesday, May 19, 2004, at 05:45 PM, Speede, Kwasi wrote:
> Jeff,
>
> Yes, we "fell back" on processing against system-specific <eventCode>
> values
> in the broker. <Event> was not appropriate for our purposes because
> multiple
> instances cannot be defined for a single message scenario.
>
> I am curious about the different approaches that are evolving or being
> proposed for determining who are the authorized CAP message originators
> across various implementation communities and how developers are
> intending
> to authenticate their messages when processing CAP. This topic would
> be a
> great addition for the implementers guide!
>
> Thanks all,
>
> Kwasi
>
> -----Original Message-----
> From: Jeff Kyser [mailto:ktrails@comcast.net]
> Sent: Wednesday, May 19, 2004 5:02 PM
> To: Speede, Kwasi
> Cc: emergency@lists.oasis-open.org
> Subject: Re: [emergency] CAP Visualization (was RE: CAP Developers'
> Forum...)
>
> Kwasi,
>
> Sounds like a nice application - I'm curious as to which CAP fields
> you use to filter messages of interest. For example, did you get
> anywhere trying to filter on the <event>, or did you fall back on
> a set of system-specific <eventCode> values?
>
> TIA,
>
> -jeff
>
> On Wednesday, May 19, 2004, at 03:47 PM, Speede, Kwasi wrote:
>
>> Kon,
>>
>> We are implementing simple GIS capabilities here at Anteon. In
>> particular,
>> we use Oracle Spatial on the backend to produce map views for the area
>> impacted by the broadcast incident. Oracle Spatial will convert the
>> polygon
>> or circle Lat/Long data into a map. I am not sure how sophisticated
>> your
>> application scenario is, ours is relatively straightforward. We use
>> Oracle
>> to convert the Lat/Longs into clickable maps and State/County codes.
>> Our
>> application code then generates census data reports that present
>> demographics about the affected geographic region and estimate the
>> potential
>> impacts to people and structures.
>>
>> We've built a CAP broker in Oracle OC4J 10G. The broker parses the CAP
>> broadcasts to identify messages relevant to our customer (FEMA)
>> business
>> processes. We store the message in Oracle XML DB with a Receiver
>> Method
>> (JMS/Message Driven Bean) and populate our incident software with
>> relevant
>> data from the message content. The J2EE enterprise application
>> executes the
>> Oracle Mapviewer component to generate the map display from the Oracle
>> Spatial db. When the broker identifies an appropriate message,
>> notification
>> methods are executed that deliver email, mobile phone and PDA messages
>> to
>> subscribers. Subscribers can then access their various applications to
>> view
>> the incident event data.
>>
>> Kwasi
>>
>> -----Original Message-----
>> From: Jeff Kyser [mailto:ktrails@comcast.net]
>> Sent: Wednesday, May 19, 2004 4:32 PM
>> To: emergency@lists.oasis-open.org
>> Subject: Re: [emergency] CAP Visualization (was RE: CAP Developers'
>> Forum...)
>>
>> Warning Systems also displayed polygons representing
>> the plumes from chemical disasters - the messages were
>> generated by other CAP providers.
>>
>> We adapted some code we had used to display storm
>> cells in a previous application, and displayed the plumes
>> instead.
>>
>> We used the Pepperwhite mapping software in a VB
>> environment. Well, actually, the map application was VB,
>> and the CAP parser / plume broadcaster was Java.
>>
>> -jeff kyser
>>
>> On Wednesday, May 19, 2004, at 03:28 PM, Art Botterell wrote:
>>
>>> Kon -
>>>
>>> The idea of visualizing aggregate CAP traffic is an interesting one.
>>> The <references> and <incidents> fields provide a mechanism for
>>> associating multiple messages in a graph... provided that the
>>> originator provides them, or that some reliable mechanism can be
>>> devised for inferring such relationships after the fact. As is so
>>> often the case, the holdup appears to be at the input.
>>>
>>> (Of course, relationships could be built on the basis of sender,
>>> event
>>> category or whatever, but it seems like in most cases the result
>>> would
>>> be a simple set that might not be very interesting visually, except
>>> perhaps when displayed geographically.)
>>>
>>> As for mapping, I've done a couple of demos plotting CAP location
>>> data
>>> over a map... I used an open-source platform called OpenMap that
>>> reads
>>> various formats including ESRI shape files, but a commercial GIS
>>> would
>>> work as well if not better. The ComCARE team (in particular, a
>>> company called GeoDecisions out of Pennsylvania) has also done CAP
>>> plots in a web mapping service.
>>>
>>> The CAP <polygon> tag, in particular, is derived from GML, so
>>> GML-aware platforms should be able to use it pretty directly...
>>> although extracting the points and constructing a new shape is pretty
>>> easy. <geocode> values require the use of polygon lookup tables...
>>> easy in the case of well-known areas like ZIP codes or county (FIPS)
>>> boundaries... less so in the case of system-specific zones that may
>>> not be familiar to all recipients.
>>>
>>> - Art
>>>
>>>
>>> At 11:17 AM -0700 5/19/04, Kon Wilms wrote:
>>>> A few questions for other implementers:
>>>>
>>>> 1. Is anyone else working on data visualization of mass amounts of
>>>> CAP
>>>> alerts (such as treemaps, hyperbolic graphs, spatial trees, or
>>>> such)?
>>>>
>>>> 2. I would be interested to hear from the GIS folks as to what
>>>> formats
>>>> they are using for vector data importing/plotting. If no-one is
>>>> implementing GIS as part of an application, are there any guidelines
>>>> for
>>>> supporting GIS file formats in CAP reception/parsing (or do we need
>>>> some)?
>>>>
>>>> Cheers
>>>> Kon
>>>>
>>>
>>>
>>> To unsubscribe from this mailing list (and be removed from the roster
>>> of the OASIS TC), go to
>>> http://www.oasis-open.org/apps/org/workgroup/emergency/members/
>>> leave_workgroup.php.
>>>
>>
>>
>> To unsubscribe from this mailing list (and be removed from the roster
>> of the
>> OASIS TC), go to
>> http://www.oasis-open.org/apps/org/workgroup/emergency/members/
>> leave_workgro
>> up.php.
>>
>> To unsubscribe from this mailing list (and be removed from the roster
>> of the OASIS TC), go to
>> http://www.oasis-open.org/apps/org/workgroup/emergency/members/
>> leave_workgroup.php.
>>
>
> To unsubscribe from this mailing list (and be removed from the roster
> of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/emergency/members/
> leave_workgroup.php.
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]