@adorfer Der Name ist OK, ich hab auch mit Nils geschrieben. Warum Hopglass „Hopglass“ heißt hat auch eventuell nicht so ersichtliche Gründe. Es gibt auch Sachen und Kommunikation die nicht im Forum nicht breit getreten wird.
@MPW ich hatte auch ein paar Sachen an Hopglass commited. Codestyle hat mir absolut nicht gefallen und @PetaByteBoy wollte es wegen Kompatibilität nicht ändern (verstehe ich völlig). Dann hab ich den Fork aus beiden und einige Sachen der Issuelisten erstellt. Da manche Features Geschmackssache sind, hab ich auch paar Sachen rausgeworfen. Wir orientieren uns an an keinem der beiden.
Wir haben aktuell > 210 Commits und einige Sachen sind in Arbeit. Wir haben neben Features auch alle Libarys aktualisiert, also grunt v1 bzw. inzwischen gulp, Leaflet v1 usw. (siehe liste im Repo).
nice, verzichtet ihr wirklich auf den Netwerk Graphen? das is hart, vor allem wenn nicht alle Knoten geocoordinaten haben, oder „experten“ 10 Knoten die gleiche Geokoordinate geben
PS: Ist das OK, wenn ich für neue Features einen neuen Post mache (groessere Änderungen/visuelle Unterschiede/Bedienung)? Feedback ist willkommen oder Ideen.
So jetzt ist vom Performance „Project“ auch der letzte (aktuelle) Punkt gefallen.
Virtual-dom wurde ersetzt. https://github.com/ffrgb/meshviewer/projects/1
(Werde das Project sicher noch mit ein oder anderen Task fuellen. Muss mal wieder schauen wo aktuell die groessten Bottlenecks sind.)
Neben schnellerem Aufbau merkt man die Verbesserung auch bei Filter Operationen.
So jetzt verfügt der forcegraph wieder über Animation und das heran zoomen von aufrufen direkt via URL klappt wesentlich besser.
GW filter und GW Ausgabe bei der Node wurde auf Wunsch hinzugefügt. GWs werden nicht wie in anderen Implementierungen über eine Liste gepflegt, sondern alle mit dem gw flag ist eine Liste und diese löst die Namen auf.
Ansonsten noch paar andere Sachen wie Libary Updates oder kleinere Modifikationen (inkl fix vom Meshlink count, tilte-tag Umbau usw.).
Sry, ja es gab ein technisches Problem am Cluster. SSD Cache kaputt, Daten werden migriert usw. und da wir das gestellt bekommen und nichts zahlen, waren wir eine niedrige Priorität. Jetzt ist der Server umgezogen und wenn der DNS durch ist sollte es gehen. Google DNS Flush ist passiert.
EDIT:
Das Backup hat leider nicht den aktuellen Stand. muss das nochmal deployen.
EDIT2:
So wieder deployed - strg + F5 - JS hat dann ein cache breaker.
Neuer Kartenserver läuft (Update von Zoomlevel und attribution nötig)
Umbau nodes.json ist in zusammen spiel mit yanic an der Reihe. Aktuell wird ein massiver Overhead mit ausgeliefert (ca. 50%), aber auch ein paar neue Informationen. Aktuell noch am planen und testen.
Kleinere Bugfixes und Updates
Viele Gruesse
xaver
PS:
Kann leider nicht meinen ersten Post updaten (kaputter Link) usw.
Sag mal kann dieser MV auch mit nodes.json Version 1 umgehen und hat er multi nodes.json support um mehrere jsons auf der gleichen Karte anzeigen zu können?
Nein, es gibt ein Konverter Script - das war mal drin, Das kostet Leistung und kannte keine Community mit v1. Hätte eher ein Proxy Script gebaut. Wir planen ja auch v2 den Rücken zu kehren. Beispielsweise möchte ich einige Sachen viel dynamischer bauen Wenn möglich via Config Felder definieren die ausgeben werde (wenn alles klappt). Als Backend Yanic (und jeder andere der irgendwie so raus bekommt - Vorteil von dynamischen config wenns geht).
Wollte gerade drauf schauen, aber es sind keine CORS gesetzt und kann daher die JSON nicht laden.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://mesh.freifunknord.de/data/nodes.json. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
Da hatte ich und gut den meisten Hirnschmalz hatte sheogorath reingesteckt damals eine Meshviewer (v4) version gebaut welche nodes.json v1 und v2 verarbeiten konnte.
das wäre schon mal eine Umwandlung von v2 in v1. Aber in diesem Fall brauchen wir eine Wandlung von v1 nach v2, damit der hopglass eine v2 von uns bekommen kann.
Es gibt aber doch bestimmt irgendwo schon ein bash- oder jq-Script, das einfach eine nodes.json v1 in v2 umwandeln kann mit ein paar jq befehlen, oder?
Hier ist auch noch mal ein codeschnipsel, der helfen könnte eine invers funktion zu erstellen:
Damit kann man im hopglass-server eine nodes.json im v1 format erstellen, siehe hopglass README option in „possible-webserver-queries“:
/mv1/nodes.json Meshviewer nodes.json v1
Allerdings ist das alles noch keine Lösung für uns.
Entweder brauchen wir in Nord und Hamburg einen Workaround, der aus unserer nodes.json v1 eine neuere v2 erstellt, damit hopglass damit läuft
oder wir müssen unser generate_aliases.py Script neu erstellen, das in die nodesV1 die geokoordinaten reinrechnet damit es dies auch in einer nodes.jsonV2 reinrechnen kann, so dass wir gleich das neuere Format benutzen können. Dazu hab ich das hier von @kantorkel gefunden: was hat es mit dem generate_aliases_v2.py auf sich? Ist das für eine nodes.json im v2 format gedacht? Oder ist das nur eine neue version des scripts und das v2 hat nichts mit nodes.json v2 zu tun?
Wir hatten v2 schon mit ffmap backend und wie beschreiben planen wir das ganze zu ändern. Backend kann theoretisch alles sein, aber erste wird Yanic sein. Unser Meshviewer unterstützt „offiziell“ kein HopGlass Backend.
der groessere Auswirkungen auf den Meshviewer hat und noch nicht final ist. Es geht um Router (URL).
- Links updated