Reihenfolge der Punkte sicherstellen

[adschm]

Ich habe gerade nach längerem Nachdenken festgestellt, dass für ein Polygon die Reihenfolge der Punkte eine Information darstellt.
Wie stellen wir sicher, dass wir die Reihenfolge der Punkte in der Datenbank erhalten? Sollten wir hierfür die ID verwenden und als Konvention festlegen, dass die fortlaufend sein muss? Dann sollten wir das entsprechend bei den Abfragen mit ORDER BY ID ASC auch so benutzen. Ist aber dann Mist, wenn man z.B. nachträglich einen Punkt hinzufügen will.
Tatsächlich brauchen wir wahrscheinlich ein zusätzliches Feld "sort", das für ein Polygon immer von 1 bis n läuft und das NUR zum sortieren verwendet wird.
Allerdings sollten wir das nicht einer zufälligen Sortierung der Abfrage überlassen, sonst kommt Murks raus. Wie macht das die Geo-DB, die im Wiki vorgeschlagen wurde?

[adschm]

Wenn man die ID verwenden will, könnte man für jede Änderung natürlich auch alle IDs wieder am Ende anfügen (= altes Polygon "löschen" und neues erstellen).

[ChristianDresel]

das ist richtig, die Tabelle polygons hat ja eine ID, diese Nummer ist fortlaufend. Ja demnach sollte man der Abfrage unbedingt noch ein Order by mitgeben.
Nachträglich Punkte würde ich so lösen, das man das Polygon einfach neu aufbaut, neu in die Datenbank schreibt und dann das alte verwirft.
Aktueller Zustand sollte so sein, wenn sich 2 Polygone überschneiden, das dann zuerst das mit der niedrigeren ID getroffen wird und das 2. nie (da man beim 1. Treffer ja schon aus der Schleife raus fliegt). Demnach würde in dem Fall oben das man ein erweiteres Polygon neu einfügt folgendes entstehen:
PolygonALT (ohne den zusätzlichen Punkt) und PolygonNEU (mit dem zusätzlichen Punkt aber höhere ID) sind in der DB, zu diesen Zeitpunkt wird PolygonALT verwendet da es die niedrigere ID hat, Sobald man dann das PolygonALT aus der db wirft, werden die Router sofort das PolygonNEU verwenden (was auf die gleiche Hood zeigt).
Demnach sehe ich das neu hinzufügen einzelner Punkte nicht als Problem an (ob das überhaupt oft passieren wird?) und wäre mit einem ORDER BY bei der Abfrage glücklich :)

[ChristianDresel]

Wir hatten in Nürnberg eine Diskussion warum man es vielleicht genau andersherum haben will. Das neue Polygone die ein altes Polygon schneiden die Router zu sich ziehen:

Man macht am Anfang ein relativ großes Polygon z.b. Nürnberg Stadt. Nach nem Jahr kamen weitere 70 Router in dem Polygon hinzu und man will nun "Nürnberg Innenstadt" haben. Nach weiteren 2 Jahren kamen wieder 40 Router in der Fußgängerzone hinzu und man will nun "Nürnberg Fußgängerzone" haben.

Sprich die Polygone werden immer spezifischer/genauer.
Dementsprechend würde es Sinn machen mit der höchsten ID anfangen und abzubrechen sobald man einen Treffer hat.

[adschm]

Ich weiß nicht, ob ich verschachtelte Polygone will. Entsprechend deiner Beschreibung erscheint es aber u.U. sinnvoll. Ich würde dies im Hinterkopf behalten und nach einer Anfangsphase mit nicht überschneidenden Polygonen kann man ja nochmal drüber nachdenken.

Unabhängig davon ist mir beim Nachkucken aufgefallen, dass wir zwar die Ecken der Polygone per ID sortieren, aber nicht die Polygone selbst. Hier müssten wir ggf. noch ein ORDER BY ergänzen und stünden dabei nun genau vor der Frage, ob und wie man das sortieren will.
Im Moment haben wir für sich überschneidende Poly-Hoods quasi "undefined behavior".
Man könnte natürlich auch damit warten, bis man die oben besprochene Entscheidung getroffen hat.

[ChristianDresel]

Ich gebe dir recht, ich will am Anfang auch keinesfalls verschachtelte Polygone. Wenn wir aber bisschen Erfahrung damit haben und das alles gut funktioniert will ich mir die Option auf jeden Fall offen halten.

Ich denke über das ORDER BY machen wir uns Gedanken wenn wir uns sicher sind, das wir mit verschachtelten Polygone arbeiten wollen. Demnach würde ich es aktuell so lassen wie es ist, Erfahrung mit sammeln und wenn es dann soweit ist, kann man die Diskussion ja nochmal anstoßen,

[adschm]

Umgezogen nach FreifunkFranken#13