[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]