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: CAP Visualization (was RE: CAP Developers' Forum...)

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

What I've done for now (as a test scenario) is to take the NWS emwin
data and visualize it by breaking it into entities based on state,
county, and some other drilldowns. I have a basic 3d hyperbolic view
that can be manipulated by the user, and new entities can be added and
visually flagged as they arrive dynamically. It's a good alternative to
flagging counties on a map for each weather event (even though we're
doing that too..) and cuts down on drilldown time for a user. Anyway
that's just my 2c.
> (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.)

With the sheer glut of data possible, it makes good sense to give the
user vis options. Unfortunately I have found that some vis approaches
have been patented.
> 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.

Our initial client version used a faked webservice hack to get a
standard version of MapPoint to act as a webservice but we've opted for
native code in the application -- which also cuts down on bloat
(MapPoint has a tendency to grow to your max ram size with each
successive query and only then throttle itself). Anyway the client
application has recently been moved to a native vector/raster plotter
with support for MIF and SHP files, so that is good to hear.

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

Thanks I will keep that in mind.


Information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the postmaster@nds.com and destroy the original message.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]