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: 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.


At 6:45 PM -0400 5/19/04, Speede, Kwasi wrote:
>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,
>-----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'
>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?
>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 

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]