[CUWiN-Dev] Visualization Question:

[Sascha Meinrath]

i wonder if the next-generation vis map should include some info about the 
"reliability" of each node's placement (e.g., how convincing it's 
placement on the map is)?  i could imagine each map showing some 
color-coding for each node that would let us know if there's a major 
discrepancy between where we would have expected the node to be (e.g., 
based on signal strength readings) and where it actually appears (e.g., 
based on lat & long).

of course, that's version 2.0 of route-vis...

--sascha

On Fri, 25 Feb 2005, Stephane Alnet wrote:

>>>> I had a quick question that came up at the FCC regarding the mapping of
>>>> the network.  Let's say that Geek A adds latitude and longitude, then 
>>>> Geek
>>>> B (one year later) moves the node to a new location but neglects the
>>>> geolocation information, meaning that the node is now announcing
>>>> inaccurate information.  How does our mapping deal with this?
>>> 
>>> The node will be displayed at the wrong location.
>> 
>> We use a "springs" layout algorithm.  If many nodes have been "tacked"
>> to the map using their GPS coordinates, then the springs attached to a
>> misplaced node may be under much greater strain than the springs attached
>> to other nodes.  If we choose the color of each node to reflect the sum
>> of the potential energy in its attached springs, maybe misplaced nodes
>> will stand out.
>
> When a node is displaced, the neighboring nodes are going to appear as being 
> co-located (say, downtown Champaign), but all located some distance away from 
> the registered position of the displaced node (say, downtown Urbana). (In 
> that case the node was moved from downtown Urbana to downtown Champaign.) It 
> should be somewhat obvious from looking at the drawing that the node is not 
> tolopogically located where it is said to be geographically located. (The 
> drawing would show a bunch of lines going from different nodes in downtown 
> Champaign to that single node in "downtown Urbana".)
>
> One simplistic approach to automatically detect these nodes could be to look 
> for inter-node distances that are outside of reach (from a wireless 
> standpoint) under "normal" conditions (based on the hardware deployed). 
> Specific links (using point-to-point amplifiers, etc.) could be tagged to 
> make sure they don't get trimmed as abnormal (because they are by design).
>
> One could also take the reverse path of thought and use both neighboring 
> information (provided by the routing tables) and power levels (or ETX 
> metrics) seen by the different nodes to create a topological map of the 
> network and tag any major changes over time (using, say, daily or weekly 
> averages) to detect displaced node. Collecting this kind of metrics would be 
> interesting from a network health monitoring in any case. (A la 
> "mrtg/smokeping".)
>
> Moreover, and this is maybe a better idea, one could combine this 
> (topological) map information with a few, well-known reference nodes (for 
> which the geographical location can be established with certitude and 
> verified at regular intervals), and create (using a spring model) a 
> topological/geographical map. (I guess what I'm saying is that we don't need 
> to know the geographical location of _all_ the nodes to establish the 
> location of an unknown node; the "fuzzy triangulation" done by using the 
> topological metrics (signal levels, ETX values, ...) and the spring model 
> should be sufficient to produce an intelligible map. Moreover that new map 
> would have the advantage of displaying "moving" nodes at their approximate 
> location, thus eliminating the "geolocation update" problem completely. 
> Something like this: http://www.shimaore.net/CUWireless/map/ )
>
> S.
>
> PS: Dave, this is based on the Java applet I've being mentioning for some 
> time. It uses different colors to indicate the stress on a link, as you 
> mentioned, or can display the stress as a value. In the demo I used "100+dB 
> level" as the target value (one would need some metric that is proportional 
> with distance and has some physical meaning, this one doesn't meet either 
> criteria).
>
> _______________________________________________
> CU-Wireless-Dev mailing list
> CU-Wireless-Dev at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev
>

-- 
Sascha Meinrath
President                 *   Project Coordinator   *   Policy Analyst
Acorn Worker Collective  ***  CU Wireless Network  ***  Free Press
www.acorncollective.com   *   www.cuwireless.net    *   www.freepress.net