[Berlin-wireless] Vorschlag neue globale MAP

[Dennis Bartsch]

Hallo Florian,

ich erlaube mir mal, mich selbst aus meiner Mail an dich zu zitieren:

> [...]
> Ich bin mit einem Freund gerade dabei einen Kartendatenserver und die Datensammelscripte zu implementieren. Wir
> haben etwa 1,5 Wochen gebraucht, um eine halbwegs endgültige Datenbank
> zu bekommen, weil wir immer wieder gegen neue Wände in der Darstellbarkeit gestoßen sind.
> Dieser Datenserver bildet die Knoten (mit ihren Attributen wie Hostname, Geo-Koordinaten usw), wifi-devices (mit ihren
>
 antennen), wifi-interfaces (mit ihren Adressen), wired interfaces, 
Funk-links (Empfangspegel), Routingprotokoll-Links (Routingprotokoll
>
 und IP-Version-unabhängig, sogar Layer2), Routingprotokolle und ihre 
Metrikvarianten (zB ff_etx und ff_eth oder die Protokollversionsnummer 
bei batman) ab. 
> [...]
> Perspektivisch soll 
eine Duplizierung der Kartendatenserver implementiert werden, so dass jede 
größere Community ihren eigenen Server fährt und diese sich 
untereinander abgleichen und Fall-Back bilden.
>
> Die Nodes updaten sich über eine JSON-Schnittstelle, die sich ohne Inkompatibilitäten erweitern lässt. 
>[...]
>
> Wir sind so weit, dass Nodes sich updaten können. Gerade
> liegt die Implementation des OLSR Global-Update, um die komplette Topologie,
>
 die ein Node kennt, in den Server zu bekommen, in den letzten Zügen. 
Auch an der Front gibt es schon einen Plan: anhand der Topologie kennt 
man die sich selbst updatenden Nodes in der Nachbarschaft der nur durch 
das globale Update bekannten Nodes. Lässt man die "smarten" Nodes die 
MAC-Adressen von den "dummen" Nodes einsammeln, kann man die 
Empfangspegel mit den Layer3 Routingprotokoll-Links in Verbindung 
bringen. 
> [...]
>
> Die Schnittstelle für das Frontend, um die Daten
 abzurufen, haben wir noch nicht beschrieben. Das ist noch todo. 
Angedacht ist ein Interface, dass sich nicht nur für Karten-Frontends 
eignet, sondern auch für Statistik-Server oder den geneigten 
Informatik-Student, der sich neue KPIs für Meshes ausdenkt für seine 
Papers ... also eine Schnittstelle, auf welcher der anfragende Host zum 
einen eine Liste der Abfragevariationen abrufen kann (die vorhandnen 
Objekte und ihre Attribute) und zum anderen möglichst genau bestimmen 
kann, welche Daten er empfangen möchte (nur 2,4GHz ad-hoc Links zB).
>
 So möchte ich erreichen, dass der Datenversender bestimmen kann, was 
auf der Karte angezeigt wird. Benutzt jemand im Ausland plötzlich WiMax 
auf 900MHz oder implementiert jemand ein Community-Mesh mit einem bisher
 unbekannten Meshing-Protokoll, will ich das dem Karten-Server und dem 
Frontend _nicht_ händisch beibiegen müssen, sondern nur Support in den 
Update-Agenten einbauen. Auch lässt sich damit in beliebiger 
Granularität eine Abstufung der Details erreichen. Betrachte ich eine 
ganze Stadt, interessieren mich erst mal nur "Punkte-und-Linien", weiter
 reingezoomt schon Link-Qualitäten bis ich an den Punkt angekommen sind,
 wo mir die Karte die stilisierten Antennendiagramme zeigt und genau 
sagen kann, über welche Interfaces/Antennen mit welchen Link-Kosten und 
Empfangspegel ein Link zu Stande kommt, oder eben nicht (weil er 
einseitig ist?).


Das Thema halte ich für viel wichtiger, als die Frage, auf welchen Kartenkacheln die Daten visualisiert werden.

Gruß
Dennis