Ich quote jetzt einfach nur noch die suggerierten Antworten, die bereits existieren.
Da es sich um Vereinsdaten handelt > der Vorstand
1 Like
das heißt, Ihr dürft nun eine Sicherheitslücke ausnutzen?
Das sind keine Vereinsdaten, das sind Communitydaten. Und hier verbreitet eine Community falsche Daten an einen externen Dienst.
So, da ihr keinerlei Verständnis für den restlichen Verein aufbringen könnt, habe ich es nun so geändert, dass Wuppertal nicht mehr announced wird.
Vielen Dank für Euer Entgegenkommen.
Wenn du so eine „META-Community“ drin haben willst dann beschwer DU dich bei den API-Team.
Zur Zeit liefert die Community Essen falsche Daten aus, das muss berichtigt werden.
Wie würdet ihr reagieren wenn wir jetzt nicht Wuppertal sonder Aachen wären und behaupten uns würden alle Router aus dem Freifunk Rheinland gehören und jeder Eintrag auf unsere Homepage verweist?
Wenn ihr da eingegriffen und global announced hättet, damit Rheinufer und Albufer wieder auftauchen, und dafür alles Wuppertal gewesen wäre, dann hätte ich da bis zur Klärung Verständnis für gehabt.
Aber müsst ihr nicht, ist gelöst, jetzt lasst es bitte gut sein…
noch ein mal zum Verständnis:
alles andere muss die jeweilige Domäne selbst klären (Aufteilung in Communitys). Bis da eine funktionierende Lösung gefunden wurde, stört die Anderen nicht.
Das glaubst du doch selber nicht das ihr da mitgespielt hättet.
Die API von Essen gibt immer noch falsche Daten aus, damit es es noch nicht gelöst.
Die Community Essen sabotiert gerade mit voller Absicht die Community Wuppertal.
Falsch, denn Wuppertal ist in den globalen Daten nicht mehr enthalten.
Wenn ich sage es ist gelöst, dann ist es auch gelöst…von einem Workaround in den Nächsten, aber naja…
Fehler Nummer eins: Falsche Eintragung in der Community Essen.
Fehler Nummer zwei: diesen Fehler nicht beheben wollen
Fehler Nummer drei: Wuppertal aus der Vereinskarte entfernen (http://map.freifunk-rheinland.net/)
Langsam häufen mir sich hier die Fehler …
wehe mir - Die Geister die ich rief …
ich muss vielleicht nochmal aufklären was die Karte im verhältnis zur API-Files und Freifunk.net angeht.
Die Apifiles listen unter anderem Karten, die die Knoten der Communities zeigen. Die API soll eine Möglichkeit sein CommunityDaten nach oben an freifunk.net zu kommunizieren. Ursprünglich genutzt zum Beispiel für die Communitykarte auf freifunk.net, die Communitynews etc.
Was ich mit meiner freifunk-karte.de mache ist ein wenig ein Missbrauch der Daten.
Ich arbeite alles durch und suche nach Knotenlisten, die ich in meine Karte reinmogeln kann.
Wenn die Karte auch viel Freude ausgelöst hat, so wurde sie doch nicht vom EV oder freifunk.net voran getrieben.
Es ist auch nicht so, dass jemand per apifile „Daten an die Karte meldet“.
Ich habe da eher einen Mashup, der verschiedene Quellen verarbeitet.
Da das alles natürlich etwas suboptimal ist. (siehe Probleme oben, sowie z.B. potentielle Änderungen bei ffmap oder netmon, die die Freifunkkarte killen könnten) entstand die Idee ein json-format zu finde, mit dem Nodelisten ausgetauscht bzw veröffentlicht werden können. name: „nodelist“
Infos dazu z.b. hier: Infos zur nodelist - siehe Punkt (b)
gist hier
php - Klassen zur Erzeugung hier
Wenn eine Community solch eine nodelist publiziert (auch wieder über api-file) sollte sie imho dann wirklich sicher stellen, dass darüber nur die eigenen Knoten kommen.
Ich muss allerdings zugeben, dass das noch nicht ganz zu Ende gedacht ist, da der Netmon beispielsweise schlicht nicht weiß welcher knoten zu welcher Untergruppe gehört. Dafür müsste erstmal die technische Basis geschaffen werden. Bei ffmap-gruppen ist das sicher nicht anders.
Problem wäre ja, dass nicht alle Gruppen sofort vollständig auf nodelist umstellen können/werden. ich hätte dann also wieder Dopplungen und müsste dafür sorgen, dass nodelist immer gewinnt oder sonstwas.
4 Likes
Mir fällt auf, dass auf www.freifunk-karte.de alle Nodes der Domäne Rheinufer fehlen. Siehe auch https://forum.freifunk.net/uploads/default/752/68dd74036ec5776f.png
Hallo @hinkelstein , Ist diese domäne/Gruppe in der FF-Api verzeichnet? directory.api.freifunk.net/directory.json at master · freifunk/directory.api.freifunk.net · GitHub wenn ja, welche Gruppe seit ihr?
Tino
Das ist die Domäne Rheinufer, deren Announcement über die globale Map ich zurückziehen musste, weil Wupper drauf bestanden hat.
Lässt sich über das Directory nicht mehr finden, da wie oben bereits beschrieben die Meta-Communities gelöscht wurden.
Es müsste über Communities im Rheinufer nun die Domänen Map announced werden, um das Rheinufer wieder online zu bringen, es sei denn Du hast die Möglichkeit eine nodes.json hart zu hinterlegen.
Dann entweder die globale nodes.json: http://map.freifunk-rheinland.net/nodes.json
oder die der Domäne Rheinufer: http://ffmap.freifunk-rheinland.net/nodes.json
oder beide…
Hm, mir fällt gerade auf, dass die Karte die verbundenen Clients unterschlägt. Ist das noch nicht drin?
Wenn ich mir directory.api.freifunk.net/directory.json at master · freifunk/directory.api.freifunk.net · GitHub so anschaue, ist wohl das Problem, dass keine einzige Gruppe der Domäne Rheinufer im Freifunk Rheinland e.V. vollständig oder überhaupt eingetragen ist.
Aachen steht drin, aber ohne Link zur Karte. Ich ändere das mal, dann schauen wir weiter.
Habe Düsseldorf soeben requested:
…spätestens wenn gemerged wird ist Rheinufer enthalten…
1 Like
ich nehme an http://map.freifunk-ruhrgebiet.de/nodes.json enthält keine korrekten/aktuellen Client-Zahlen.
Da steht bei fast allen node 0 drann, obwohl http://map.freifunk-ruhrgebiet.de/list.html ein anderes Bild zeigt.
…die list.html hat als einzige Quelle die http://map.freifunk-ruhrgebiet.de/nodes.json
Was man in der Liste sieht ist auch in der nodes.json drin, sonst wäre es nicht da.
Fragen wir mal anders rum, zu welchen Versionen der ffmap bist Du denn kompatibel?
Das Feld Clientcount, wenn Du das als einzige Quelle nutzt, ist erst in der jüngsten Version des ffmap-backend enthalten/gefüllt!
Die list.html benutzt fallweise d.clientcount und d.clients.length, um zu beiden Versionen kompatibel zu sein…