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


Thanks, Gary,

I am copying the list with my reply, so it should get through. BTW, 
this is the kind of discussion we have been needing for some time, so 
thanks to all. But special thanks to Gary for eliminating my need to 
write to DMIS separately. I have asked for some special attention to 
both the UDDI and ebXML Registry Tech Notes to WSRP which I will 
forward or synopsize in the relatively near future. I will also be 
looking into how to go about establishing some best practices 
resources or guides for XACML, SAML and WSS.

Ciao,
Rex

At 11:27 AM -0400 5/20/04, Ham, Gary A wrote:
>Rex,
>
>This will probably bounce on the TC list so you may forward if
>necessary.  All this security is wrapped up in the definition of "trust"
>as applied to individual networks.  In a multiple network situation it
>should be expected that different networks will have differing "trust"
>needs for application and individual that might use the network.  DMIS
>trust is based on the concept of establishing validated Collaborative
>Operations Groups (COGs) as defined virtual organizations of users who
>agree to dynamically create and share information amongst themselves in
>real time. Validation is a manual process and done individually using a
>variety of non-public techniques. Once validated, each COG administers
>its own individual membership.  Designated primary operators for each
>COG may also, at the press of a button, post the created information to
>one or more other COGs on the network based own their own selection
>criteria. 
>
>In production mode CAP senders through DMIS are COG members using some
>basic COG metadata to wrap their CAP message. If you look at the
>interface that prototyping systems have been using, you will see a
>special interoperability COG that does not directly connect to all
>production COGS.  A COG member EM organization that uses one of these
>prototypes could however change the COG id used in the interface to
>their own and post directly into DMIS. Note that COGS can be formed for
>groups of users that do not use DMIS tools, but that they must be
>sponsored and maintained by legitimate EM related organizations.  So one
>network could post to a second network through the DMIS backbone, but
>would still need to have compliance with the basic DMIS trust system.
>Actually that is just what was done in the Congressional demo when
>alerts created in a non-DMIS product were posted to DMIS, picked up by
>as third party, and reposted to ComCARE's E-Safety prototype.  The
>middleman was a member of both trust networks.
>
>So, the question is how we come to agreement on trust issues.  I doubt
>that we will because different networks have different needs.  Hopefully
>we can agree to use particular standards as they are developed and made
>usable, but even with standards different needs for balance between
>openness and security will make inter network negotiation a required
>task.
>
>
>Respectfully,
>
>
>Gary A. Ham
>Senior Research Scientist
>Battelle Memorial Institute
>540-288-5611 (office)
>703-869-6241 (cell)
>"You would be surprised what you can accomplish when you do not care who
>gets the credit." - Harry S. Truman
>
>-----Original Message-----
>From: Rex Brooks [mailto:rexb@starbourne.com]
>Sent: Wednesday, May 19, 2004 8:50 PM
>To: Speede, Kwasi; 'Jeff Kyser'
>Cc: emergency@lists.oasis-open.org
>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_wo
>rkgroup.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
>
>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_wor
>kgroup.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]