[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. Cheers Kon *********************************************************************************** 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]