Hood-Bildung - Gemeindegrenzen

fff at mm.franken.de fff at mm.franken.de
Mi Sep 19 12:44:07 CEST 2018


Hi Christian und Michael,

> 1. Die Umrüstung von mysql auf pqsql 

[1]

> 2. Was sagt die Performance? 

"is-in" von PostGIS ist auch mit riesigen Datenmengen performant.

Bei nur 5k Router kann man die Zuordnung "Router/Hood" natürlich auch
einfach einmal berechnen und in einer Tabelle ablegen.
Sollte dann auch nicht viel teurer sein.

Mit herzlichem Gruss,
Markus

[1] PySQL to PostgreSQL:
https://wiki.postgresql.org/wiki/Converting_from_other_Databases_to_PostgreSQL


> 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