Hallo Leute, ich habe dem Hoodselector beigebracht, (auch nichtkonvexe) Polygone als Hoods zu erkennen. Hierzu habe ich die Strahl-Methode nach dem Punkt-in-Polygon-Test nach Jordan [1] in lua implementiert und als Funktion in den hoodselector eingebaut. Hierzu habe ich einen lokalen branch polygone-hoods vom packages-repo erstellt und würde den ganz gerne mit git push --set-upstream origin polygone-hoods pushen. Aber: GitLab: You are not allowed to push code to this project. ;( kann mich jemand als Developer hinzufügen? Auch die hoods.json habe ich entsprechend angepasst. Jede n-eckige Hood besteht jetzt aus einer Box, mit n+1 Punkten, wobei Punkt[1]=Punkt[n+1]. Unter [2] kann man sich das Ergebnis anschauen. Natürlich sind damit jetzt auch schräge Hoodgrenzen möglich, zB entlang Teutoburger Wald oder Autobahnen etc. Es muss nur jemand (tm) machen. Habe die neue Kombination aus hoodselector + hoods.json mal durch mein test-script [3] laufen lassen. er hat alle hoods erkannt und kam auch überall online :) Übrigens: Verschachtelte Hoods (also zB. Bad-Iburg innerhalb landkreis-osnabrück) stellten übrigens schon früher kein Problem dar, sofern sie in der hoods.json richtig sortiert waren. Wenn die "Unterhood" vor der "Oberhood" steht, kam der hoodselector immer schon damit klar. [1] https://de.wikipedia.org/wiki/Punkt-in-Polygon-Test_nach_Jordan [2] http://bl.ocks.org/d/ea7ee9d9ff49ff90047ebda82e306c77 [3] https://git.nordwest.freifunk.net/lrnzo/check-hoods LG lrnzo
ok, habe den branch polygone-hoods gepusht. Ich bin zwar etwas verwirrt von der diff-ausgabe im gitlab, aber so wie die datei im commit 8bbdf7c5ca96e20ab4e439f4d3c3228239d52477 aussieht, sollte das passen. hier mal eine visualisierung: http://bl.ocks.org/d/0f83790d48e337a745afd8a62312074f lg lorenz Am 21.08.2017 um 02:09 schrieb lrnzo via Dev:
Hallo Leute,
ich habe dem Hoodselector beigebracht, (auch nichtkonvexe) Polygone als Hoods zu erkennen. Hierzu habe ich die Strahl-Methode nach dem Punkt-in-Polygon-Test nach Jordan [1] in lua implementiert und als Funktion in den hoodselector eingebaut. Hierzu habe ich einen lokalen branch polygone-hoods vom packages-repo erstellt und würde den ganz gerne mit
git push --set-upstream origin polygone-hoods
pushen. Aber:
GitLab: You are not allowed to push code to this project.
;(
kann mich jemand als Developer hinzufügen?
Auch die hoods.json habe ich entsprechend angepasst. Jede n-eckige Hood besteht jetzt aus einer Box, mit n+1 Punkten, wobei Punkt[1]=Punkt[n+1]. Unter [2] kann man sich das Ergebnis anschauen. Natürlich sind damit jetzt auch schräge Hoodgrenzen möglich, zB entlang Teutoburger Wald oder Autobahnen etc. Es muss nur jemand (tm) machen.
Habe die neue Kombination aus hoodselector + hoods.json mal durch mein test-script [3] laufen lassen. er hat alle hoods erkannt und kam auch überall online :)
Übrigens: Verschachtelte Hoods (also zB. Bad-Iburg innerhalb landkreis-osnabrück) stellten übrigens schon früher kein Problem dar, sofern sie in der hoods.json richtig sortiert waren. Wenn die "Unterhood" vor der "Oberhood" steht, kam der hoodselector immer schon damit klar.
[1] https://de.wikipedia.org/wiki/Punkt-in-Polygon-Test_nach_Jordan [2] http://bl.ocks.org/d/ea7ee9d9ff49ff90047ebda82e306c77 [3] https://git.nordwest.freifunk.net/lrnzo/check-hoods
LG lrnzo
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
ich habe dem Hoodselector beigebracht, (auch nichtkonvexe) Polygone als Hoods zu erkennen. Hierzu habe ich die Strahl-Methode nach dem Punkt-in-Polygon-Test nach Jordan [1] in lua implementiert und als Funktion in den hoodselector eingebaut. Hierzu habe ich einen lokalen branch polygone-hoods vom packages-repo erstellt und würde den ganz gerne mit
git push --set-upstream origin polygone-hoods
pushen. Aber:
GitLab: You are not allowed to push code to this project.
;(
kann mich jemand als Developer hinzufügen?
Ich hab dich Gesten hinzugefügt. :)
Auch die hoods.json habe ich entsprechend angepasst. Jede n-eckige Hood besteht jetzt aus einer Box, mit n+1 Punkten, wobei Punkt[1]=Punkt[n+1]. Unter [2] kann man sich das Ergebnis anschauen. Natürlich sind damit jetzt auch schräge Hoodgrenzen möglich, zB entlang Teutoburger Wald oder Autobahnen etc. Es muss nur jemand (tm) machen.
Sehr cool, das schaue ich mich die tage gerne mal an.
Übrigens: Verschachtelte Hoods (also zB. Bad-Iburg innerhalb landkreis-osnabrück) stellten übrigens schon früher kein Problem dar, sofern sie in der hoods.json richtig sortiert waren. Wenn die "Unterhood" vor der "Oberhood" steht, kam der hoodselector immer schon damit klar.
Jop, aber überlappende hoods haben wir von Anfang unterbunden um die Anzahl potentieller Fehler quellen zu verringern. Theoretisch könnte man den hoodgen so anpassen das dieser solche Überlappungen erkennt und dann entsprechend die hoods sortiert. Generell sollten wir nochmal schauen wie VXLAN den hoodselector beeinflussen wird. Es könnte sein das die unterschiedlichen bssids und co auch nicht mehr nötig wären. Aber dazu müssen wir uns das auch noch mal genauer anschauen. vg Tarek
Hi Lorenz,
ich habe dem Hoodselector beigebracht, (auch nichtkonvexe) Polygone als Hoods zu erkennen. Hierzu habe ich die Strahl-Methode nach dem Punkt-in-Polygon-Test nach Jordan [1] in lua implementiert und als Funktion in den hoodselector eingebaut. Hierzu habe ich einen lokalen branch polygone-hoods vom packages-repo erstellt Auch die hoods.json habe ich entsprechend angepasst. Jede n-eckige Hood besteht jetzt aus einer Box, mit n+1 Punkten, wobei Punkt[1]=Punkt[n+1]. Unter [2] kann man sich das Ergebnis anschauen. Natürlich sind damit jetzt auch schräge Hoodgrenzen möglich, zB entlang Teutoburger Wald oder Autobahnen etc. Es muss nur jemand (tm) machen.
Habe die neue Kombination aus hoodselector + hoods.json mal durch mein test-script [3] laufen lassen. er hat alle hoods erkannt und kam auch überall online :)
Übrigens: Verschachtelte Hoods (also zB. Bad-Iburg innerhalb landkreis-osnabrück) stellten übrigens schon früher kein Problem dar, sofern sie in der hoods.json richtig sortiert waren. Wenn die "Unterhood" vor der "Oberhood" steht, kam der hoodselector immer schon damit klar.
Danke für deine Mühe. Before wir das aber Mergen können, muss nur noch eine Sache getan werden. Der Hoodgen kann dein Format an hoods nicht erzeugen, daher müsste dieser angepasst werden. Wenn wir Überlappungen zu lassen, sollte der hoodgen am besten automatisch die hoods in die richtige Reihenfolge sortieren. (Achtung das steigert die Entwiklungskomplexität im hoodgen enorm) Zudem könne man Optimierungen einbauen die, die Größe des hoodfiles reduziert. Man könnte z.B. den hoodgen erkennen lassen wenn eine hood von einer anderen eingeschlossen wurde. das die hoodgen automatisch die größere hood unter die kleinere legt und die unnötigen punkte löscht. Das sind aber wahrscheinlich Mathe-freuden ;) vg Tarek
Moin Also ich habe ja in den letzten Monaten das eine oder andere Hoodfile mit dem Hoodgen gebaut. Und muss sagen, dass diese durchaus sehr gut funktioniert und leicht zu händeln ist. Nach einer kleineren Anpassund meinerseits sind die Rechtecke auch nun kleiner als in der ursprünglichen Version. Diese kann man bei Bedarf sicherleich noch kleiner machen. Was ich sehr angenhem finde ist das man in der akutellen Version keine Überschneidungen konstruieren kann, zumindestens wenn man nur die GUI nutzt und nicht anfängt an den Koordinaten im Hoodfile zu drehen. Ich sehe den großen Vorteil von Polygonen halt noch nicht wirklich zumindestnes was den Hoodgen angeht, ich finde das kann man an der Stelle super so belassen. Wenn man nun hier wilde Polygone zieht wird es zu überhschneidungen/überlappungen oder auch zu abschnitten kommen die, dann nicht in einer der Hoods sich befinden. Auch wenn ich an die Programmiertechnische umsetzung denke ist das nicht mal eben erledigt, wenn man diesen Faktor abfangen möchte, wird es doch eher sehr komplex werden. Was ich durchaus sehe ist das bei einer komplzierten Hood sicherleich das Hoodfile größer wird wenn eine Hood aus vielen kleinen Kästen besteht. Ich denke den Support in den Hoodselector einzubauen, sodass dieser Polygons kann, halte ich für sinvoll, das im Hoodgen zu machen halte ich aus oben genannteten Gründen für Schwachsinn und echt schwierig in der Handhabung. Um dennoch das Hoodfile möglichst klein zu bekommen wäre da als erste Idee von mir nun die wie ich finde bessere Lösung einen Script zu schreibem, welches beim Build vorgang das Hoodfile analysiert und viele kleine Rechtecke zu einem Polygon zusammenfasst. Das hätte den Vorteil, das das Hoodfile auf den Router möglichst klein ist, aber dennoch vom Anwender im Hoodgen sehr einfach hanzuhaben ist. Gruß Johannes Von meinem iPhone gesendet
Am 20.09.2017 um 10:38 schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:
Hi Lorenz,
ich habe dem Hoodselector beigebracht, (auch nichtkonvexe) Polygone als Hoods zu erkennen. Hierzu habe ich die Strahl-Methode nach dem Punkt-in-Polygon-Test nach Jordan [1] in lua implementiert und als Funktion in den hoodselector eingebaut. Hierzu habe ich einen lokalen branch polygone-hoods vom packages-repo erstellt Auch die hoods.json habe ich entsprechend angepasst. Jede n-eckige Hood besteht jetzt aus einer Box, mit n+1 Punkten, wobei Punkt[1]=Punkt[n+1]. Unter [2] kann man sich das Ergebnis anschauen. Natürlich sind damit jetzt auch schräge Hoodgrenzen möglich, zB entlang Teutoburger Wald oder Autobahnen etc. Es muss nur jemand (tm) machen.
Habe die neue Kombination aus hoodselector + hoods.json mal durch mein test-script [3] laufen lassen. er hat alle hoods erkannt und kam auch überall online :)
Übrigens: Verschachtelte Hoods (also zB. Bad-Iburg innerhalb landkreis-osnabrück) stellten übrigens schon früher kein Problem dar, sofern sie in der hoods.json richtig sortiert waren. Wenn die "Unterhood" vor der "Oberhood" steht, kam der hoodselector immer schon damit klar.
Danke für deine Mühe. Before wir das aber Mergen können, muss nur noch eine Sache getan werden. Der Hoodgen kann dein Format an hoods nicht erzeugen, daher müsste dieser angepasst werden. Wenn wir Überlappungen zu lassen, sollte der hoodgen am besten automatisch die hoods in die richtige Reihenfolge sortieren. (Achtung das steigert die Entwiklungskomplexität im hoodgen enorm)
Zudem könne man Optimierungen einbauen die, die Größe des hoodfiles reduziert. Man könnte z.B. den hoodgen erkennen lassen wenn eine hood von einer anderen eingeschlossen wurde. das die hoodgen automatisch die größere hood unter die kleinere legt und die unnötigen punkte löscht. Das sind aber wahrscheinlich Mathe-freuden ;)
vg Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 20.09.2017 11:05, Johannes Rudolph via Dev wrote:
Moin
Also ich habe ja in den letzten Monaten das eine oder andere Hoodfile mit dem Hoodgen gebaut. Und muss sagen, dass diese durchaus sehr gut funktioniert und leicht zu händeln ist. Nach einer kleineren Anpassund meinerseits sind die Rechtecke auch nun kleiner als in der ursprünglichen Version. Diese kann man bei Bedarf sicherleich noch kleiner machen.
Was ich sehr angenhem finde ist das man in der akutellen Version keine Überschneidungen konstruieren kann, zumindestens wenn man nur die GUI nutzt und nicht anfängt an den Koordinaten im Hoodfile zu drehen.
Ich sehe den großen Vorteil von Polygonen halt noch nicht wirklich zumindestnes was den Hoodgen angeht, ich finde das kann man an der Stelle super so belassen. Wenn man nun hier wilde Polygone zieht wird es zu überhschneidungen/überlappungen oder auch zu abschnitten kommen die, dann nicht in einer der Hoods sich befinden. Auch wenn ich an die Programmiertechnische umsetzung denke ist das nicht mal eben erledigt, wenn man diesen Faktor abfangen möchte, wird es doch eher sehr komplex werden.
Ich wollte jetzt nicht als derjenige, der das Teil mal zusammengeschustert, momentan aber keine Zeit hat, reingrätschen und irgendwas kaputtreden, aber diese Komplexitätsgedanken sind damals der Ausschlag dafür gewesen, dass wir gesagt haben: Lasst uns das rechteck-basiert machen. Die Größe der Rechtecke ist dabei natürlich diskutierbar, aber bei Polygonen sehe ich wie Johannes ebenfalls die Überlappungs- und Auslassungsproblematik. Wenn man das anpacken Wollte, müsste könnte ich mir höchstens vorstellen, mit verschiedenen Ebenen/Prioritäten zu arbeiten, zwischen denen sich die Polygone dann ruhig überlappen können, da die Layer ohnehin von oben nach unten abgearbeitet werden und dann jeweils geguckt wird, ob die Koordinaten im aktuell betrachteten Layer innerhalb des Polygons liegen. Falls nicht, wird dann das darunter liegende Layer betrachtet. Ob das den Aufwand allerdings Wert ist, weiß ich nicht, auch, weil das bestimmen der Mitgliedschaft einer Koordinate innerhalb eines beliebigen Polygons nicht so ganz unaufwendig ist, evtl. auch was Rechenzeit betrifft. Viele Grüße, Eike
ohne jetzt tief in den hoodgen-problematiken drin zu stecken: vielleicht könnte es helfen, sich einmal die api von geojson.io anzugucken? bei geojson kann zumindest ein polygon-haltiges hoodfile reintun bekommen alle polygone angezeigt. Vielleicht kann die api noch andere Dinge, was viel Komplexität rausnimmt? Wollen wir uns beim Festival mal hierzu zusammensetzen? LG Lorenz Am 20.09.2017 um 12:45 schrieb Eike Baran via Dev:
On 20.09.2017 11:05, Johannes Rudolph via Dev wrote:
Moin
Also ich habe ja in den letzten Monaten das eine oder andere Hoodfile mit dem Hoodgen gebaut. Und muss sagen, dass diese durchaus sehr gut funktioniert und leicht zu händeln ist. Nach einer kleineren Anpassund meinerseits sind die Rechtecke auch nun kleiner als in der ursprünglichen Version. Diese kann man bei Bedarf sicherleich noch kleiner machen.
Was ich sehr angenhem finde ist das man in der akutellen Version keine Überschneidungen konstruieren kann, zumindestens wenn man nur die GUI nutzt und nicht anfängt an den Koordinaten im Hoodfile zu drehen.
Ich sehe den großen Vorteil von Polygonen halt noch nicht wirklich zumindestnes was den Hoodgen angeht, ich finde das kann man an der Stelle super so belassen. Wenn man nun hier wilde Polygone zieht wird es zu überhschneidungen/überlappungen oder auch zu abschnitten kommen die, dann nicht in einer der Hoods sich befinden. Auch wenn ich an die Programmiertechnische umsetzung denke ist das nicht mal eben erledigt, wenn man diesen Faktor abfangen möchte, wird es doch eher sehr komplex werden.
Ich wollte jetzt nicht als derjenige, der das Teil mal zusammengeschustert, momentan aber keine Zeit hat, reingrätschen und irgendwas kaputtreden, aber diese Komplexitätsgedanken sind damals der Ausschlag dafür gewesen, dass wir gesagt haben: Lasst uns das rechteck-basiert machen. Die Größe der Rechtecke ist dabei natürlich diskutierbar, aber bei Polygonen sehe ich wie Johannes ebenfalls die Überlappungs- und Auslassungsproblematik.
Wenn man das anpacken Wollte, müsste könnte ich mir höchstens vorstellen, mit verschiedenen Ebenen/Prioritäten zu arbeiten, zwischen denen sich die Polygone dann ruhig überlappen können, da die Layer ohnehin von oben nach unten abgearbeitet werden und dann jeweils geguckt wird, ob die Koordinaten im aktuell betrachteten Layer innerhalb des Polygons liegen. Falls nicht, wird dann das darunter liegende Layer betrachtet. Ob das den Aufwand allerdings Wert ist, weiß ich nicht, auch, weil das bestimmen der Mitgliedschaft einer Koordinate innerhalb eines beliebigen Polygons nicht so ganz unaufwendig ist, evtl. auch was Rechenzeit betrifft.
Viele Grüße, Eike _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Moin,
Also ich habe ja in den letzten Monaten das eine oder andere Hoodfile mit dem Hoodgen gebaut. Und muss sagen, dass diese durchaus sehr gut funktioniert und leicht zu händeln ist. Nach einer kleineren Anpassund meinerseits sind die Rechtecke auch nun kleiner als in der ursprünglichen Version. Diese kann man bei Bedarf sicherleich noch kleiner machen.
Jo, Das war meinerseits auch nicht so gemeint das es aktuell nicht funktionieren würde.
Was ich sehr angenhem finde ist das man in der akutellen Version keine Überschneidungen konstruieren kann, zumindestens wenn man nur die GUI nutzt und nicht anfängt an den Koordinaten im Hoodfile zu drehen.
Ich sehe den großen Vorteil von Polygonen halt noch nicht wirklich zumindestnes was den Hoodgen angeht, ich finde das kann man an der Stelle super so belassen. Wenn man nun hier wilde Polygone zieht wird es zu überhschneidungen/überlappungen oder auch zu abschnitten kommen die, dann nicht in einer der Hoods sich befinden. Auch wenn ich an die Programmiertechnische umsetzung denke ist das nicht mal eben erledigt, wenn man diesen Faktor abfangen möchte, wird es doch eher sehr komplex werden.
Sobald wir Überlappungen zu lassen ist, sehe ich das auch so das es schwierig wird, was die Umsetzung der Zeichnung betrifft.
Ich wollte jetzt nicht als derjenige, der das Teil mal zusammengeschustert, momentan aber keine Zeit hat, reingrätschen und irgendwas kaputtreden, aber diese Komplexitätsgedanken sind damals der Ausschlag dafür gewesen, dass wir gesagt haben: Lasst uns das rechteck-basiert machen. Die Größe der Rechtecke ist dabei natürlich diskutierbar, aber bei Polygonen sehe ich wie Johannes ebenfalls die Überlappungs- und Auslassungsproblematik.
Ich versuche hier mal zu unterscheiden. Ich hab mich in meiner ersten Mail glaube ich nicht ganz klar ausgedrückt. Wenn denn MR[0] annehmen wäre es ganz schön wenn der hoodgen in der Lage wäre solche hoods zu zeichnen. Da könnte man zwei Wege gehen indem man beim Zeichen Überlappungen zulässt oder nicht. Ich selber würde wenn überhaupt keine Überlappungen zulassen. Da es das saubere zeichnen einer hood nahe zu unmöglich macht. (zumindest wüsste ich nicht wie) Eine Möglichkeit wäre z.B. An den Kanten andockt. Das könnte das z.B. so aussehen [1]. Bzgl. Der Rechenleistung müsste man sich das mal genauer ansehen. Letztlich wird es nur bei VPN Routern ausgeführt und der code scheint sich von der Algorithmik her in Grenzen zu halten. Aber das sollten wir wie gesagt vor dem Merge noch mal genauer unter die Lupe nehmen.
Wenn man das anpacken Wollte, müsste könnte ich mir höchstens vorstellen, mit verschiedenen Ebenen/Prioritäten zu arbeiten, zwischen denen sich die Polygone dann ruhig überlappen können, da die Layer ohnehin von oben nach unten abgearbeitet werden und dann jeweils geguckt wird, ob die Koordinaten im aktuell betrachteten Layer innerhalb des Polygons liegen. Falls nicht, wird dann das darunter liegende Layer betrachtet. Ob das den Aufwand allerdings Wert ist, weiß ich nicht, auch, weil das bestimmen der Mitgliedschaft einer Koordinate innerhalb eines beliebigen Polygons nicht so ganz unaufwendig ist, evtl. auch was Rechenzeit betrifft.
Also was du meinst dürfte mit der Jetzigen Version des Hoodselectors bereit ohne Probleme gehen. Der Hoodselector geht iterativ die hoods von oben nach unten durch und schaut welche zu der aktuelle POS passt. Eine Optimierungsmöglichkeit, unabhängig von Polygons oder Rechtecken, wäre das der hoodgen selbst prüft ob eine hood in/um eine andere liegt. Als bsp. Osnabrück Stadt und Osnabrück Umland. Gezeichnet würde es folgendermaßen aussehen: [ { "name": "default", "bssid": "02:CA:FF:EE:BA:BF", "defaulthood": true, "servers": [ { "type": "fastd", "host": "default06.ffnw.de", "port": "11111", "publickey": "22e270ff9b2d1017c3a0b00dd22a58ef7e5915a355eeb16f0b8b52d7eb377869" }, { "type": "fastd", "host": "default06.ffnw.de", "port": "11112", "publickey": "49f91cb7adabccc5c8876394d3bbe4f1927aa54c21af1a811a88cc44b5a12bfb" } ], "boxes": [] }, { "name": "osnabrueck", "bssid": "02:00:0A:12:90:00", "defaulthood": false, "servers": [ { "type": "fastd", "host": "lk-os01.sn.ffnw.de", "port": "10000", "publickey": "148fa1af96a0ee6653d150fa11b6b018738a711f47b8d8bb05ad569880ad6415" }, { "type": "fastd", "host": "lk-os02.sn.ffnw.de", "port": "10001", "publickey": "c91a74b295f8d1372080c0a7536b094631c4cab6af3fd339e135c4f971c91242" } ], "boxes": [ [ [ 52.282, 7.99 ], [ 52.32, 8.15 ] ], [ [ 52.24, 7.99 ], [ 52.282, 8.036 ] ], [ [ 52.268, 8.06 ], [ 52.282, 8.15 ] ], [ [ 52.24, 8.036 ], [ 52.268, 8.15 ] ] ] }, { "name": "osnabrueck2", "bssid": "02:00:0A:12:60:00", "defaulthood": false, "servers": [ { "type": "fastd", "host": "os01.sn.ffnw.de", "port": "10002", "publickey": "e00d26eee0a91d7a9d38da736b051cbe1fef4166cb15ab41c4d1ada95e857c43" }, { "type": "fastd", "host": "os01.sn.ffnw.de", "port": "10003", "publickey": "30e2b86d25c9270ce084393de456a15e5326093998002b668c1bd9bc79b96c79" } ], "boxes": [ [ [ 52.268, 8.036 ], [ 52.282, 8.06 ] ] ] } ] Wie man sieht hat osnabrueck recht viele Koordinaten dafür das es ein Rechteck ist. Sortiert man die hoods jetzt in einer bestimmten Reihenfolge so wäre folgendes Möglich: [ { "name": "default", "bssid": "02:CA:FF:EE:BA:BF", "defaulthood": true, "servers": [ { "type": "fastd", "host": "default06.ffnw.de", "port": "11111", "publickey": "22e270ff9b2d1017c3a0b00dd22a58ef7e5915a355eeb16f0b8b52d7eb377869" }, { "type": "fastd", "host": "default06.ffnw.de", "port": "11112", "publickey": "49f91cb7adabccc5c8876394d3bbe4f1927aa54c21af1a811a88cc44b5a12bfb" } ], "boxes": [] }, { "name": "osnabrueck2", "bssid": "02:00:0A:12:60:00", "defaulthood": false, "servers": [ { "type": "fastd", "host": "os01.sn.ffnw.de", "port": "10002", "publickey": "e00d26eee0a91d7a9d38da736b051cbe1fef4166cb15ab41c4d1ada95e857c43" }, { "type": "fastd", "host": "os01.sn.ffnw.de", "port": "10003", "publickey": "30e2b86d25c9270ce084393de456a15e5326093998002b668c1bd9bc79b96c79" } ], "boxes": [ [ [ 52.268, 8.036 ], [ 52.282, 8.06 ] ] ] }, { "name": "osnabrueck", "bssid": "02:00:0A:12:90:00", "defaulthood": false, "servers": [ { "type": "fastd", "host": "lk-os01.sn.ffnw.de", "port": "10000", "publickey": "148fa1af96a0ee6653d150fa11b6b018738a711f47b8d8bb05ad569880ad6415" }, { "type": "fastd", "host": "lk-os02.sn.ffnw.de", "port": "10001", "publickey": "c91a74b295f8d1372080c0a7536b094631c4cab6af3fd339e135c4f971c91242" } ], "boxes": [ [ [ 52.24, 7.99 ], [ 52.32, 8.15 ] ] ] } ] Beides kann übrigens im hoodgen importiert und auch exportiert werden[2]. Aber da sehe ich bei Rechtecken keinen signifikanten Gewinn. Bei Polygonen hingegen könnte das schon wieder interessant werden. Ich selbst bin mit den Rechtecken zufrieden und mir ist es daher nicht wichtig diese Änderung zu haben. Seitens Gluon gibt es aber wohl ein paar die gerne Polygone hätten[3]. Schöne Grüße [0] https://git.ffnw.de/ffnw-firmware/packages/merge_requests/60 [1] http://umap.openstreetmap.fr/de/map/freifunk-hochstift-sites-karte_60146#10/... [2] https://hoodgen.ffnw.de/ [3] https://github.com/freifunk-gluon/gluon/pull/997
participants (4)
-
Eike Baran -
Jan-Tarek Butt -
Johannes Rudolph -
lrnzo