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...)
Amen! I think we definitely need to rope DMIS in on this, so I will
write to some of them tomorrow, if I can squeeze some time in. Thanks
for bringing this up, everyone.
Ciao,
Rex
At 6:45 PM -0400 5/19/04, 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.
--
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]