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