Ffmap-backend und meshviewer

[quote=„netminion, post:213, topic:4123“]
Da ich der Meinung bin, dass jede Community eine eigene Map haben sollte/möchte/will, sollten wir uns vielleicht auch gedanken machen, wie das umzusetzen ist.[/quote]

Ich sehe das in einem etwas größeren Kontext, vielleicht gibt es ja in Zukunft nicht mehr so viele "Sub-"Communitys, bzw nicht jede Community hat eine eigene Firmware.
So gehört zum Beispiel Moers zu Rheinufer, die Nodes liefern aber den Sitecode von Rheinufer aus.

Mit dem Filter kannst du soviel filtern, wie du möchtest, basiert auf dem Namen der Nodes.

Aktuell erstelle ich damit die Daten für Krefeld, Viersen, Jüchen und Mönchengladbach.

Damit kann der Betreiber der Infrastruktur, egal ob Sub-Domäne, Domäne oder gar der Verein, aus den Backend-Daten beliebig fein filtern, sei es für Communities, Städte oder gar Straßenzüge oder Ortsteile. Man muss sich nur auf ein Namensschema einigen, auf das gefiltert werden kann.

Das spätere einfügen anderer Filterkriterien gestützt auf weitere JSON-keys ist auch kein Problem.
In der nächsten Version möchte ich zusätzlich zu den Map-Daten (Meshviewer und ffmap) noch das Api-File für die Community aus einem Template generieren.

1 Like

schön wäre ja, basierend auf den Koordinaten, vielleicht mit Angabe eines Zentrums und Radius.

Da nicht jede Stadt rund ist, bräuchte man mehrere kreise und Radien, so dass man die Stadt ungefähr abdecken kann.

1 Like

Könnte aber auch kompliziert werden. Nicht jede Stadt ist rund :wink:

Das kannst du mit Elasticsearch machen, ohne Probleme! Siehe [hier][1]
Damit hat auch das manuelle Nodes zählen von @Sirhcnailuj bei den Butzentreffen ein Ende. :wink:
[1]: Fertige Lösung: Nodes einer Stadt ermitteln / Tool für Domain-Split

1 Like

Halte ich pers. für zu umständlich, außerdem wie behandelt man dann Knoten ohne Geodaten?
Ich denke das Filtern auf den Namen und das Vereinbaren von Benennungsrichtlinien ist aktuell der einfachste Weg.

Schön wäre vielleicht eine weitere Konfigurationsoption „Stadt“ oder „Community“ zu schaffen, die dann auch in den JSON-Daten auftaucht. Im Idealfall als Dropdown-Box gefüttert aus der site.conf, damit die möglichen Werte klar sind.

Das schließt sich ja nicht aus. Man könnte nach Namen filtern und optional auch nach Entfernung. Natürlich kann man mit den Koordinaten nur Knoten filtern, die welche haben, daher wäre die Hauptfunktion so eines Filters, Knoten, die zu weit entfernt vom Zentrum des Stadtradius sind, von der Karte auszuschließen.

Der einfachste Fall wäre also, man definiert einen Mittelpunkt und einen max. Radius? Denke das ließe sich recht einfach einbauen…

Die Paderborner Map hat schon eine „Beim nächsten Klick Koordinaten anzeigen“-Funktion. Meintest du die? Falls nicht, könntet ihr die Funktion ja vielleicht übernehmen :slight_smile:

Der Link zum Git findet sich unter „Über“.

Das dürfte es sein. Es gibt da einen Pullrequest, aber ich bin mit dem Code noch nicht zufrieden. Ich finde das Feature ist auch nicht sonderlich dringend, da Gluon sowieso bald mal lernen soll selbst eine Karte anzuzeigen.

Ich habe das Repository tcatm/meshviewer nun gelöscht. Mir wird schon wieder, ähnlich wie bei ffmap-d3, schon wieder darum herumgebastelt ohne dass Code ordentlich zurückfließt und Leute fangen auch schon wieder an wilde Mergescripte zu schreiben anstatt den Code sauber in ffmap-backend einzubauen.

Das nächste Meshviewerrelease gibt es dann als vorkompilierten Javascript Tarball, in den man nur noch die config.json einfügen muss.

Schade. Trotzdem Danke für deine unermüdliche Arbeit.

Hmmm… finde ich schräg wenn ich so ehrlich sein darf.
Das Du in Deine Version nur sauberen Code übernehmen magst ist ja okay, aber ist es nicht gerade der Open-Source Gedanke, dass jeder damit machen darf? Dann gibt es halt Dirty-Hack Versionen neben Deiner. Ist das wirklich schlimm? Was gut ist kannst Du ja übernehmen… Ich finde den Gedanken gezielt die Mitgestaltung zu verhindern überhaupt nicht witzig. Ich sehe den Freifunk als Community Plattform. Angenommen Du schmeißt mal, hast gesundheitliche Probleme oder sonstwas. Soll die Community wirklich auf eine Plattform setzen die darauf angelegt ist, dass nur ein Entwickler daran arbeiten kann?
Ich begrüße Deine Ansprüche an Code, den Du akzeptierst sehr. Das Du andere ausgrenzt ist Mist und wirft Fragen auf. Ich persönlich würde es bevorzugen auf offene Technik zu setzen, die ggf. auch wer weiterentwickeln kann. Im konkrete Kontext hoffe ich, dass jemand einen Link zu seiner Kopie des Repos postet und dann ist gut. Ich finde Deine neue Philosophie inkompatibel mit dem Freifunk Gedanken. Sorry. Deine Arbeit ist wirklich super. Diese Aktion ist es hingegen nicht. Das ist Ego vor Community. Das ist imho ein Holzweg.

Edit: Hier ein Fork: GitHub - ffac/meshviewer: http://draic.info/meshviewer/

4 Likes

Der Source liegt nun unter http://draic.info/meshviewer/ und Patches kann man an meshviewer@draic.info richten. Vielleicht funktioniert das besser.

1 Like

Hey,
hier haste nen Patch! Jo, danke, ich guck mal, ob der taugt.

Hier wär noch ein Bug, fix das mal.

Was ist das überhaupt?

Was hast du zuletzt geändert?

Boah, nervt das. Lass mal etwas entwickeln, irgendetwas mit Versionsverwaltung und Arbeit abnehmen.

Deine Reaktion auf schlechten Code ist merkwürdig. Hast du die Leute, die wilde Mergescripte schreiben, mal angehauen und erklärt wie es besser wäre?

Super, das original ist wieder da:

Danke! :blush:

Kann man irgendwie noch die Verknüpfungen zu den Forks bei github wieder herstellen?
Nachtrag: nein:

A new repository that was never part of the original fork network cannot be added to the fork network.
The owner of the repository that was deleted will need to contact us separately about this though.

Man sieht die ganzen Forks zumindest nun in freifunk-darmstadt/meshviewer der nun der neue upstream ist.

Hier eine Liste aller forks: https://github.com/rubo77/meshviewer-1/blob/master/NETWORK.md

3 Likes

@tcatm ich würde mir wünschen, wenn man das „nodedb“-Verzeichnis auch via Commandline-Option übergeben kann.

Der Hintergrund ist, dass manche Domains unterschiedliche Instanzen für Städte/Communities nutzen, also eigene Interfaces für Batman und fastd - somit auch für Alfred. Deshalb muss das Backend mit unterschiedlichen Sockets/Interfaces und Verzeichnissen aufgerufen werden.

Da aber leider das „nodedb“-Verzeichnis nicht übergeben werden kann, muss unnötiger Weise das Backend mehrmals vorhanden sein.

for INSTANZ in niers mo kk mg
do
    /opt/ffmap-backend-$INSTANZ/backend.py \
       -d /var/lib/ffmap-backend/$INSTANZ/ \
       -a /opt/ffmap-backend-$INSTANZ/aliases.json \
       -m bat0-$INSTANZ:/var/run/alfred/$INSTANZ.sock \
       -p7 --with-rrd
done

Wie du in diesem Beispielaufruf siehst, könnte man das ganze auf eine lokale Kopie des Backends reduzieren, wenn auch das „nodedb“-Verzeichnis ausgelagert werden könnte. Zwar gibt es in den unterschiedlichen Instanzen keine Überschenidungen bei den MAC-Adressen, aber die „nodes.rrd“ wird von jeder Instanz erzeugt.

Danke und Gruß
Dominique Görsch

1 Like

Eigentlich erfülle ich keine Wünsche, aber das war jetzt einfacher einzubauen als darum zu bitten, dass sich jemand anders bemüht. Ich hab mal eine Bitcoin-Addresse eingerichtet: 1Eo4R9rumM5FCwC4WcCpKBYiwBbzyFVd2X

3 Likes

Danke für die Änderung. Kann es sein, dass es aktuell ein Problem mit der Erzeugung der Grafiken gibt?
Wenn ich das Backend mit --with-rrd aufrufe, erhalte ich immer:

Traceback (most recent call last):
  File "/opt/ffmap-backend/backend.py", line 186, in <module>
    main(options)
  File "/opt/ffmap-backend/backend.py", line 156, in main
    rrd.update_database(nodedb['nodes'])
  File "/opt/ffmap-backend/lib/rrddb.py", line 32, in update_database
    lambda d: d[1]['flags']['online'], nodes.items()))
AttributeError: 'list' object has no attribute 'items'

Ohne --with-rrd läuft es normal durch. Leider ist mein Python zu beschränkt, um es selber zu debuggen…