Hood-Bildung - Gemeindegrenzen

michael at fritscher.net michael at fritscher.net
Mi Sep 19 12:14:00 CEST 2018


Moin,

kurz: klingt lecker :-) Danke fürs Ausprobieren!

2 Anmerkungen:

1. Die Umrüstung von mysql auf pqsql dürfte eigentlich recht einfach 
machbar sein, gerade beim v2 Keyxchange. Ist mir aber egal, wenn die php 
Variante auch gut funktioniert (scheint sie ja bisher).
2. Was sagt die Performance? Du könntest ja mal Schaittach 100x auf die 
Karte klatschen, immer bissle verschoben, und gucken was passiert, wenn 
alle durchgeschaut werden. Wenn das max. 2-3 Sekunden dauert könnte man 
das durch einen Cache ablindern. Wir haben ja nur Größenordnung 5k 
Router, also 5k unterschiedliche Koords, da könnte man die 
Koord->Hoodzuordnung speichern. Der Cache würde dann halt bei 
Hoodänderungen geleert werden.

Grundsätzlich wäre ich klar für weiter ausprobieren :-)

Viele Grüße und Danke,
Michael Fritscher



Am 2018-09-19 11:52, schrieb Christian Dresel:
> hi
> 
> um gegen ein System zu sein, sollte man ein System erstmal verstehen.
> Bisher war ich dagegen, weil ich dachte es ist zu aufwendig. Aber hey
> ich spiel doch gerne mit Technik und so hab ich mal bisschen 
> herumprobiert.
> Mein Ergebniss möchte ich nun mal der Community vorstellen und würde
> mich über bisschen Feedback (sowohl technisch als auch nicht technisch)
> freuen.
> 
> Ich hab Markus seine Anleitung erstmal soweit abgearbeitet das ich eine
> GeoJson File von Schnaittach (und Simmelsdorf und noch irgendein
> Nachbarort den Markus genannt hat) lokal hatte, das sieht dann so aus:
> 
> http://fff-jupiter.fff.community/schnaittach.GeoJson
> 
> Hier drinnen ist bereits für jeden Ort ein MultiPolygon (keine Ahnung 
> ob
> das der richtige Begriff ist, aber so wird es hier genannt) enthalten.
> 
> Nun ist der Punkt von Markus "Ist-in-Abfrage" allerdings nicht ganz
> leicht umzusetzen, der keyxchange hat keine PostgreSQL und das
> nachzurüsten uff... Will ich mir eigentlich ersparen. Also hab ich mal
> geguckt wie ich das in PHP (damit ist der keyxchange geschrieben)
> einfacher lösen kann. Ich bin dabei auf diese Funktion gestolpert:
> 
> http://assemblysys.com/php-point-in-polygon-algorithm/
> 
> Man muss jetzt aus der GeoJson natürlich ein Array erstellen, dies hab
> ich erstmal händisch gemacht (das in ne Schönform zu bringen sollte
> technisch kein Problem sein) mit dem Bereich Simmelsdorf, sieht dann so 
> aus:
> 
> http://fff-jupiter.fff.community/poly/array.txt
> 
> Danach hab ich noch 3 Koordinaten reingeklopft gegen die ich testen 
> will
> (später würde der Router hier seine Koordinaten hinschicken und der
> keyxchange schaut in welchen MultiPolygon das liegt):
> 11.339509 49.559324
> 11 49
> 11.327267 49.618443
> 
> Im moment sich lat/lon noch verdreht, da die MultiPolygon so aufgebaut
> ist, hab ich erstmal damit gearbeitet. Das Ergebnis sieht dann so aus:
> 
> http://fff-jupiter.fff.community/poly/index.php
> (Sourcecode kann hier angeguckt werden:
> http://fff-jupiter.fff.community/poly/index.txt )
> 
> Man sieht, die Funktion arbeitet auch mit Koordinanten korrekt, die
> ersten 2 Koordinaten liegen eindeutig nicht im Bereich Simmelsdorf, die
> 3. aber schon.
> 
> So wie könnte man dies nun technisch in den keyxchange klopfen:
> 
> Schritt 1) Der Knoten schickt seine Koordinaten an den keyxchange.
> Schritt 2) wir prüfen die Koordinaten gegen alle (ich nenn dieses
> Hoodsysten jetzt mal frech so) GeoJson-Hood. Passen die Koordinaten des
> Knoten in eine dieser vorhandenen GeoJson-Hoods, wird diese Hood an den
> Knoten zurückgegeben und er konfiguriert sich auf diese Hood falls sie
> in keine GeoJson-Hood passen, machen wir mir Schritt 3 weiter ansonsten
> endet hier der Ablauf bereits
> Schritt 3) wir prüfen wie jetzt auch schon, zu welcher voronoi Hood der
> Knoten gehört und geben ihn diese Hood zurück.
> 
> Bisher arbeitet der Keyxchange nur mit Schritt 1 und 3, man würde also
> einen Schritt 2 "dazwischen" schieben.
> 
> Vorteile:
> - Wer GeoJson verwenden will, kann dies tun. Wer es nicht tun will
> bleibt einfach bei den alten voronoi System, es ist die freie
> Entscheidung jedermann (und das ist mir persönlich sehr wichtig)
> - Das GeoJson System liegt "über" den voronoi System. Somit werden 
> Hoods
> die aktuell nach voronoi arbeiten absolut nicht beeinflusst sofern "da
> drinnen" niemand eine Geo-Json Hood anlegt. Die Systeme können also
> wunderbar pararell agieren
> 
> Nachteil:
> - Das Zeug muss man erstmal umsetzen
> - Der Wartungsaufwand vom keychange steigt etwas an, man muss auf noch
> mehr Sachen acht geben
> 
> So Meinungen? Was meint ihr? Umsetzbar? Sollen wir es probieren? Hab 
> ich
> Dinge übersehen?
> 
> mfg
> 
> Christian
> 
> On 06.09.2018 09:46, fff at mm.franken.de wrote:
>> Moin Michael,
>> 
>>>> Markus, wir können uns da gerne mal (virtuell oder physikalisch)
>>>> zamhocken und da was zusammenbrauen ;-)
>> 
>> Habe mal etwas Doku zusammengetragen:
>> https://wiki.freifunk-franken.de/w/Hood_nach_Gemeinden
>> 
>> Vielleicht hilft das Dir und anderen Hood-Profis ja ein bisschen?
>> 
>> Rückfragen gern per Mail oder telefonisch.
>> 
>> Mit herzlichem Gruss,
>> Markus
>> 



Mehr Informationen über die Mailingliste franken