Nodelist - metacommunity vs community

Hi,
aus gegebenen Anlass will ich nochmal zum Brainstorming zu der Nodelist einladen

Um alle abzuholen:
Das format soll die Knoten einer Community auflisten und zum Beispiel - aber nicht ausschließlich für die Freifunk-Karte auf www.freifunk-karte.de genutzt werden.

Nun ist es so, dass wir Metacommunities (MC) haben, lokale Untergruppierungen zusammen fassen.
Ich weiß nicht, ob FFFranken mit Nürnberg, Würzburg, Erlangen etc ein ideales Beispiel ist, aber ich nenne es hier mal.
Die benutzen einen gemeinsamen Netmon, die Netze aber sind teilweise getrennt.
Diese gruppen liefern nun ein apifile aus, dass angibt, dass sie zu FFFranken gehören.

Der netmon aber weiß nix davon.
Wenn nun aus dem netmon heraus eine nodelist generiert werden würde, dann wäre dort alles enthalten.

Zumindest für die Karte wäre es aber wünschenswert, dass nur die Knoten der Community enthalten sind.

In Reinland/Ruhrgebiet ist es so durcheinander mit den Gruppen und Karten, dass ich daraus kein beispiel konstruieren kann - mir fehlt da der Einblick.

Das problem das nun entsteht ist, dass einige Gruppen einer MC alle Knoten veröffentlichen könnten und dann wieder die Info der Zugehörigkeit fehlt.
Andere Gruppen machen das dann vielleicht anders, für automatisch arbeitende Systeme ist aber nicht erkennbar wo Knoten X nun hin gehört.

Wie können wir das lösen?

Denkbar wäre, dass in der Nodelist nach obigem Format zusätzlich noch angegeben(behauptet) wird, dass sie alle knoten einer Metacommunity enthält, oder eben nur die einer einzelnen.

Die detaillierte Angabe würde dann bei der Verarbeitung obsiegen und die einzige Fehlerquelle wäre nur noch eine fehlende oder falsche Angabe.

Meinungen?

Zusatzfrage:
Was definiert eine MC? Die gemeinsame Nutzung von Systemen wie der Karte, Gateways etc?
Weil z.B. für Ansbach, Emskirchen, Neuendettelsau haben wir jeweils eigene Website, Netmons und Firmware-Config. Gateway, VPNs teilen wir uns aber. Sind wir eine Metacommunity?

Tino

1 Like

Das hast Du aber schön formuliert. Freundlich geradezu…

Im Ernst: Ja, es gibt dort einen Trägerverein „Freifunk Rheinland“, der wiederum die Domains „Rheinufer“, „Ruhrgebiet“, „Wupper“, „Möhne“ und „Albufer“ betreibt (Alles Flüsse, hoffentlich habe ich niemanden vergessen)
Innerhalb dieser Domains (mit jeweils eigener Gluon-site.conf, d.h. eigenen Supernodes, eigenem Alfred, eigenem mapserver) gibt es wiederum Communities, die lediglichlich über ein wildes Gewusel von Regex-Bedingungen auseinandergezogen werden: Nodenamen auf KFZ-Kennzeichnen oder kompletten Ortsnamen, Bestimmte Lat/Lon-Polygone etc… Und es gibt noch als Spezialfall Communities die zusätzlich trotz identischer Supernodes und gemeinsam Alfred noch eine eigene site.conf benützen und daher in der nodes.json-Erststunnge eine Sonderrolle einnehmen (meines Wissens z.B. „Troisdorf“)

1 Like

Ich hätte folgende Anmerkungen zum Format:

  • people in person umbenennen. Letzteres ist offenbar gemeint.
  • Die Timestamps sehen mit den Leerzeichen merkwürdig aus. Soll das so? Welches Format ist das? ISO 8601?
  • alt, lat, lon ausschreiben
  • Was ist updated_at?
  • Was ist lastcontact? Wäre lastseen sinnvoller? Wir kontaktieren z.B. die Knoten nicht um zu überprüfen, ob sie online sind sondern machen das passiv über alfred.
  • Komplementär dazu ist ein firstseen Feld sehr praktisch. Das wäre der Zeitpunkt zu dem der Knoten zum allerersten mal gesehen wurde. Damit kann man eine Liste der neu hinzugekommenen Knoten aussortieren.
  • Was bedeutet linked? Wäre es sinnvoll das people bzw. persons einfach auf gleiche Ebene wie die nodes zu ziehen?

Welche Angaben sind eigentlich pflicht? Wir (Lübeck) könnten z.B. die links, href und node_type garnicht abbilden.

Ein Schema wäre auch hilfreich. Dann könnte ich dafür Support in ffmap einbauen.

1 Like

Das Format ist so mehr oder minder abgeschlossen definiert. Es wurde eine Weile diskutiert und verändert und dann vom Webteam akzeptiert.

der type im node verweist auf den type der links unten daher ist die Bezeichnung gleich und plural.

du hast recht, da ist irgendwann beim bearbeiten wohl was schief gelaufen. das soll ISO 8601 sein

ja, wäre durchaus berechtigt. ich hatte das so aus einem anderen Format übernommen und bisher hatte sich keiner beschwert.

Der Zeitpunkt an dem das json erzeugt wurde. Normalerweise der Zeitpunkt des Abrufes, kann aber auch cached werden daher …

bei netmon beispielsweise ist es umgekehrt. lastcontact lässt imho offen in welcher Richtung die Kommunikation statt fand.

ja, das macht Sinn, können wir mit aufnehmen.

Bei den meißten communities wird es mehr Nodes als personen geben. das wurde also normalisiert und gibt so Raum auch mehr Daten pro Person durchzureichen.

Support dafür in der ffmap wäre grandios, wirft allerdings wieder den Punkt auf, der eigentlich hier angesprochen wurde. - die metacommunities.
Es wäre halt schon gut, wenn einzelne Gruppen einer MetaCommunitie in die Lage versetzt werden auch nur genau ihre Nodes auszuliefern und nicht alle. Wie das erreicht werden kann weiß ich aber auch nicht.
Vielleicht kann man in der ffmap etwas umsetzen, wie die Gruppen ihre Nodes zuordnen können?

Tino

Radevormwald, Troisdorf und Wuppertal in der Domäne wupper haben alle eine eigene nodes.json die per API angekündigt wird. Die nodes.json aus der Domäne wupper wird nirgendwo angekündigt aber mit in der nodes.json auf map.freifunk-rheinland.net eingebaut.

Die ffmap generiert immer nur für eine Community eine Karte. Support für mehrere Communities gibt es da nicht und ist so auch nicht vorgesehen. Man könnte aber tatsächlich über ein paar Meta-Felder (z.B. „community“) nachdenken.