[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] CAP Visualization (was RE: CAP Developers'Forum...)
Hi Jeff, There are a couple of ways I see that this can be handled. For the immediate time being one can resort to out of band methods for ensuring that the CAP feeds one arranges to receive by such out of band agreements include <eventCode> as tedious as that might be. You can also handle that by the stipulations you make in your security policy using SAML and XACML. At the same time, by bringing it up in the TC as a feature request for CAP 1.x-2.0 we can ask that it be made a required field for a specific CAP provider profile within a registration context which we can establish for that purpose. One of the specific reasons for establishing an XML basis for a CAP message type is to take advantage of the ability to make a subset or superset of the basic spec. By providing a specific registration procedure for different kinds of systems such as broadcast and web service delivery, providers, intermediaries and receivers of CAP messages can more easily connect up with each other for this purpose. For web services we can do this through WSDL in ebXML or UDDI Registries and in practice through encrypted, signed SOAP messages. We can do this now by building it into the message brokers we use and just insisting that our partners support it, or find themselves unable to use our offerings. That's not very feasible this early in the process of promoting adoption, but it is one way to do it. Another thing just occurred to me. As part of an effort to establish trusted networks, it would be wise to avail ourselves of an aspect of the API services DMIS provides, and ask for some special functionality to filter messages by how <eventCode> is handled, or not. We are going to have a lot of issues like this, so we might as well start tackling them now. Ciao, Rex At 7:12 PM -0500 5/19/04, Jeff Kyser wrote: >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. >> > > >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]