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