[WLANtalk] Deutschlandweite Karte

Do Dez 11 02:29:17 CET 2014

On 10/12/14 16:47, Monic Meisel wrote:
> Bitte achtet absolut darauf in den Kartenanwendungen weder Mac 
> Adressen noch persönlichen Daten der Nutzer (Nodes und Clients) im Web 
> zu veröffentlichen!

Da geht die Diskussion aber doch schon los, bei Privatleuten zumindest 
ist die Adresse durchaus ein persönliches Datum, und wenn ich 
51.902149864757, 8.3775418996811 bei 
http://www.geocoderpro.com/en/resources/online-reverse-geocoding/ 
reinwerfe (es gibt auch andere Services), kommt Bogenstraße 2, 33330 
Gütersloh, Germany raus (unser Tagungsort, eine Kneipe). Heißt: 
Koordinaten sind nur eine andere Schreibweise für die Adresse, und die 
ist meines Erachtens immer ein persönliches Datum. Ohne die Koordinaten 
allerdings ist Netzplanung schwer (gut, man könnte messen und/oder nur 
intern eine Karte pflegen).

Worauf ich hinauswill: solange der Knotenbetreiber eine einigermaßen 
informierte Entscheidung treffen kann, ob/welche Daten er 
veröffentlichen will, ist dies aus meiner Sicht OK, auch wenn es ein 
persönliches Datum ist.

On 09/12/14 20:47, Marc-Andre Alpers wrote:
>
> Denn immerhin werden Knoten auch von nicht so Technik begeisterten 
> Bürgern wie wir hier betrieben, die sich für jeden Zweck ne neue 
> Mailadresse anlegen. Sondern bewusst oder eher unbewusst ihre 
> vorname.name@<provider>.de Adresse dort eintragen wo sie genauso ihre 
> Amazon Bestellungen und ihre private Kommunikation drüber laufen 
> lassen. Also belasst es bitte bei technischen Daten die für so eine 
> Map wirklich relevant sind. Das wären für mich Position, Knotenname 
> und die zuständige Community.

Das ist imho ein valider Punkt, der dann auch die direkte Nutzung der 
nodes.json (ffmap) u. ä. verbietet (und bedingt, jene zu schützen, 
sofern sie im Webspace liegt). Für eine globale Karte sind Orte (Namen 
nicht einmal zwingend) und der Link auf die zuständige Community 
notwendig. Alles andere ist sicher schick, aber geht weit über das Ziel 
»deutschlandweite Karte« hinaus. Was die lokale Community dann anbietet, 
ist deren Bier; ob »nur« 'ne Karte oder weitergehende Funktionen wie 
Statistiken und Monitoring, das wird vor Ort entschieden.

That said: z. B. node_type erscheint mir für die Funktion der Karte mehr 
als flüssig; in der großen Karte sollen doch die Knoten stehen, der Typ 
(Koten) ist mithin implizit? Und wenn die lokale Filterung nur aktive 
Knoten durchläßt, ist ein Status ebenfalls entbehrlich. Die Anzahl der 
Clients z. B. wird im Zweifel auch eher die lokale Karte aktueller haben 
als die deutschlandweite. Dies ist das ein sich sekündlich ändernder 
Wert, der schon lokal bestenfalls (5-)minütlich aktualisiert wird -- 
welchen Sinn hat es, diesen auf einer Deutschlandkarte zu haben? 
Updated_at im Kopf hingegen macht Sinn, so kann man verstorbene 
Communities (oder Prozesse) rausfiltern; je Knoten hingegen ist das, s. 
o., m. M. n. überflüssig.

On 09/12/14 19:21, tino.dietel at projekt2k.de wrote:
>
>> Es wäre eigentlich gut, wenn es für so eine nodes json api nur ein 
>> einziges
>> Format gibt, welches die gemeinsam genutzten Daten enthält.
>
> Genau darum soll es hier gehen. Das ist es, worüber wir hier sprechen.
>
> Mein gist ist/war eine Anregung für solch ein gemeinsames Format - 
> nicht für ein de-map-only Format.

Hmm. Sorry; dann habe ich das initiale

> nach Diskussion hier 
> https://github.com/freifunk/api.freifunk.net/issues/33nun der 
> Vorschlag ein Datenformat zu definieren, in dem jede community ihre 
> Nodeliste raus lassen kann.

irgendwie mißverstanden. Warum sollte etwas verallgemeinert werden, was 
offensichtlich hervorragend funktioniert? Die jeweiligen Tools schreiben 
ihren jeweiligen Dateien mit den für sie relevanten Daten -- wieso muß 
man das gleichschalten?

Wieso sollte z. B. eine Umgebung, die kein Benutzerkonzept hat, Daten 
über Benutzer in eine Datei schreiben müssen?

Ein Format für den Export für eine landesweite Karte hingegen, das macht 
ja durchaus Sinn. Und die könnte dann, vorzugsweise, neben 
http://freifunk.net/wie-mache-ich-mit/community-finden/ stehen und somit 
zentral abrufbar sein (Arbeitstitel »Freifunk-Knoten in Deutschland«). 
Dieser Export muß aber eben nicht jedes Fitzelchen an verfügbarer 
Information weitergeben -- auf globaler Ebene interessieren weder 
Clientzahlen pro Knoten noch Firmwareversion noch benutzte Hardware.Oder?

On 09/12/14 13:00, Tino Dietel wrote:
>
>> - Status Daten nich formal definieren, sondern freie Daten dann in 
>> Tabelle rendern. 
>
> Ich will schon explizit wissen, ob der online oder offline ist. Genau 
> das Macht für eine Karte Sinn, denn ich will als Nutzer ja uU wissen, 
> wo der nächste verwendbare Zugangspunkt ist.

Ob der online ist oder nicht, kann durch entsprechende Filterung 
weitergereicht werden. Und nach aktuellen Diskussionen auf der Berliner 
ML bin ich der Meinung, daß für Details besser lokale Datenquellen 
verwendet werden sollten und die zentrale Karte nur einen Überblick 
geben. (Hint: auch wenn es ja schon vorgesehen ist, die Höhe anzugeben, 
die Karte ist eher zweidimensional und mithin kann es durchaus sein, daß 
ich 5m von der Position eines Knoten entfernt mich eben doch nicht mit 
ihm verbinden kann, weil das ein Knoten für Richtfunkstrecken irgendwo 
in 30m Höhe ist.)

On 09/12/14 10:05, Tino Dietel wrote:
> https://github.com/interop-dev/json-for-networks/blob/master/examples/device-configuration.json 
> scheint mir aber etwas zu viel zu sein. So etwas sollte dann über eine 
> Detail-Url für die Geräte abrufbar sein, nicht aber in einer Liste mit 
> potentiell 1000 Geräten kommen. 

1100 Knoten sind ja Hamburg und Paderborn zusammen, um und bei. 
Rheinland + Ruhrgebiet sind weitere rd. 1100; ich denke Du solltest eher 
von 5k ausgehen und für 15k planen.(Und das sage ich, weil ich mit 
vielen Elementen auf einem Overlay meinen Browser (fast) gekillt habe. 
Alle Meßdaten in http://blog.guetersloh.freifunk.net/?page_id=539 
eintragen, das waren so rd. 2000 Objekte damals, erwies sich als 
durchaus problematisch.)

On 08/12/14 23:25, Tino Dietel wrote:
>
>> Beim Format frage ich mich allerdings grade, was gegen ffmap_backends 
>> nodes.json spricht, bis auf lastcontact und user ist da doch alles drin? 
>
> das was ffmap liefert ist tatsächlich sehr ziemlich nahe drann. Müsste 
> halt bei den anderen systemen analog dazu implementiert werden - - und 
> dann können die Wunschfelder ja noch dazu :-)

Wie gesagt (s. o.), on second thought ... halte ich die Nutzung 
umfangreicher Datensammlungen nicht mehr für opportun. _Eine_ 
Deutschlandkarte mit den Positionen aller Knoten, ja, das finde ich nach 
wie vor erstrebenswert. Das ist dann die ersten Anlaufstelle um z. B. 
vor dem Urlaub an der Nordsee in Cuxhaven oder vorm Besuch bei dem 
Schwiegereltern in Franken mal zu gucken, ob's da denn ggf. »was von 
Freifunk« gibt. Für Detailinformationen würde ich dann aber auf die 
Infoseite der Community bzw. des fraglichen Knotens gehen wollen (bei 
Communities ohne eigene Karte kann das ja auf ihre Webseite verlinken). 
Denn Netmons Statistiken sind interessant, aber auch ffmaps Knotengraph. 
Der Rechner für den Browser, der mit einem Knotengraph von mehreren 
tausend Knoten noch umgehen kann, muß aber erst noch gebaut werden ;) 
Und auch den Bedarf für einen deutschlandweiten Netmon sehe ich nicht -- 
das können die Communities vor Ort besser betreiben und auch entscheiden.

>
>> Falls nicht, fände ich die Option, vom De-Map-Knoten per Click auf 
>> die jeweilige Community-Map bzw. direkt den Knoten dort zu kommen. 
>> Oder ist kann/soll dafür routerpageprefix genutzt werden? 
>
> ja, das soll einen Link zu einer Detailseite über/zum Router bringen. 
> etwa wie im netmon. Was auch immer da jetzt drauf steht. Das könnte ja 
> letztlich auch ein Link zu einer anderen Karte, mit Focus auf diesen 
> Knoten sein. routerprefix + routerid könnten den Link ergeben etwa so: 
> https://netmon.freifunk-emskirchen.de/router.php?router_id=6

Oder bei ffmap-Quellen $MAPURL/geomap.html?lat=$lat&lon=$lon. Das kann 
beim Erstellen der Datei ja entsprechend ausgefüllt werden.

>
>> FTR: http://guetersloh.freifunk.net/map/nodes.json ;) 
>
> ich habe nicht unbedingt vor alle Communities per hand nach zu 
> pflegen. imho sollte sich das auch der API (also freifunk-api ergeben) 
> bei eurem file (http://quoth.uu.org/ffgt-api.json) kommt schlicht nix 
> zurück. damit komme ich garnicht dazu irgendetwas zu verarbeiten und 
> gegebenenfalls eure map zu finden.

Ah, guter Punkt. Die Datei ging offensichtlich hops, als wir mit 
laufenden Abstürzen vor rd. einem Monat zu tun hatten (quoth==gw01; ein 
Verhalten, welches unser gw04 seit zwei Tagen auch wieder zeigt, 
hrmpft). Beim Umzug der Statistiksachen auf dedizierte VMs ist das auf 
der Strecke geblieben, hab's grade mal gefixt und gleich auf 0.4.4 
gebracht. Danke für den Hinweis ;)

On 08/12/14 23:13, Andreas Bräu wrote:
>> Beim Format frage ich mich allerdings grade, was gegen ffmap_backends 
>> nodes.json spricht, bis auf lastcontact und user ist da doch alles drin? 
>
> Das Format von nodes.json ist unzureichend spezifiziert und zu sehr an 
> die Gluon-Welt angelehnt. Ich habe versucht, aus unseren OLSR-Daten eine

Ja, beim Versuch, daraus was rauszuparsen, bin ich auch irgendwann 
unentspannt geworden (und frage halt Alfred nun noch mal selbst ab). 
Danke für die Erläuterung; aus meiner Sicht ist diese Informationsfülle 
eh' nicht mehr notwendig.

On 09/12/14 10:03, Jan Lühr wrote:
>
> s/wir/Du/. Du bist nicht das Technical Commitee Der Freifunk Community

Du aber auch nicht, können wir uns darauf einigen?

On 10/12/14 00:59, Jan Lühr wrote:
>
> Dein Post ist ein gutes Beispiel dafür, dass Diese Mailingliste nicht 
> funktioniert. Ohne irgendwelche Argumente haust Du hier auf alle 
> Möglichen Dingen herum.

Dann diene ich halt als abschreckendes Beispiel; und ich entschuldige 
mich dafür, Dir Dein auf Schienen laufendens Förmchen wegnehmen zu 
wollen ...nicht.

Jetzt mal im Ernst: Du kommst mit einem Frontend zur Knotenregistrierung 
in eine Diskussion um eine einheitliche(re) Datenschnittstelle für eine 
deutschlandweite Knotenkarte. Auf Andreas' validen Hinweis, daß Du evtl. 
auf dem falschen Gleis bist (»es geht darum, bestehende Lösungen in den 
Communities zu unterstützen.«) kommt der blöde Spruch mit dem »Technical 
Commmitee«, und auf mein Gelästere über Ruby, Rails, Federation und 
andere Buzzwords (wozu ich gerne was ausführe, aber das führte in diesem 
Thread sowohl zu weit als auch nicht in die richtige Richtung) bist Du 
dann eingeschnappt. Frage ich mich also eher, wer hier nicht funktioniert.

Anyway.

Nach dem Hinweis auf Datensparsamkeit und Datenschutz halte ich 
nodes.json für nicht mehr adäquat als Datenbasis für die globale Karte 
und wir vor Ort zumindest werden uns angucken müssen, ob wir diese Datei 
noch weiter öffentlich zugänglich machen können (s. Marc-Andres' Hinweis 
zu eMail-Adressen).

Von einem einheitlichen Format für die lokal eingesetzte Software halte 
ich nichts, Gluon kennt kein Nutzerkonzept, Netmon/Register-basierte 
Netze haben das ggf. on-top, Link-Qualitäten drücken batman_adv und OLSR 
AFAIK unterschiedlich aus, ...

Bleibt die initiale Frage nach a) einem einheitlichen Format für Daten 
in einer globalen/überregionalen Karte und b) der nach einem FF-API-Feld 
für die URL zu dieser. b) dürfte sich schnell klären lassen, und bei a) 
bin ich geneigt, Jan insofern zuzustimmen, daß »machen« wahrscheinlich 
schneller funktioniert als dies auszudiskutieren.

Ich habe github noch nicht durchgespielt (immerhin, »drin« bin ich schon 
mal, ich sage also mal Level 0), daher mein Vorschlag zur Güte (für den 
Einsatzzweck »Deutschland-Karte«) plump anbei:

{
"version":"1.0.0",
"updated_at":"2014-12-11T01:00:01Z",
"community":{
"href":"URL-to_API-FILE.json",
"name":"Freifunk-Meinestadt"
     },
"nodes":[
         {
"id":"r_4712",
"href":"https:www.freifunk-meinestadt.de/routers.php?id=r_4712",
"position":{
"lat":51.902149864757,
                 "lon":8.377541899681151,
"alt":5
             }
         }
     ]
}

s/long/lon/g, 3/4/3 sieht komisch aus. Ansonsten sind halt nur die 
*relevanten* Infos für die überregionale Karte drin, die Exporter 
sollten(!) nur aktuell aktive Knoten exportieren (was nützen mir in der 
überregionalen Karte 275, ggf. seit Monaten tote, Knoten?). Alles 
Interessante über die Community steht imho im API-File (könnte/sollte 
stehen), auch den Namen könnte man da raus ziehen, aber andererseits ist 
das nun kein geheimes Datum und erspart einen Download und ein Parsing 
des API-Files.

Daraus kann dann ja noch immer ein erweitertes Format gemacht werden, um 
ggf. z. B. Netmon-NG direkt ein kompatibles Format (mit einfach mehr 
Feldern) schreiben zu lassen, oder kollidiert das mit irgenwelchen 
JSONismen?

Comments?
-kai