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, [email protected] 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
_______________________________________________
WLANtalk mailing list
[email protected]
Abonnement abbestellen? ->
http://lists.freifunk.net/mailman/listinfo/wlantalk-freifunk.net
Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung unter
http://freifunk.net/mailinglisten
