Versionierung der Planstände (Brainstorm) #3

New Issue

2025-12-11T06:53:04+01:00

Daniel commented

2025-12-11 06:53:04 +01:00

Ich bin gerade dabei, die Datenhaltung für den Plan auf eine Postgre-DB umzustellen, damit wir von dort aus vielleicht gleich weiter machen können. (Plugin-technisch soll der Nutzer eingeben können, ob er in ner DB oder mit gpkg arbeiten will- so zumindest die erste Idee)

An der Stelle die Frage: wie gestalten wir die Versionierung der Planstände?

Idee: Der Nutzer drückt nen Knopf "Planstand festschreiben" oder sowas, und es wird der Datenbestand mit einem Tag nochmal in den Tabellen abgelegt. Die Daten werden dann immer über den Tag gefiltert. (Nur Daten ohne Tag für aktuellen Stand)
Idee: Der Nutzer drückt den Knopf und der Datenbestand wird in ne gpkg gesichert. Die könnte man dann als Quelle angeben, wenn man das Plugin startet, um den Datenstand wiederherzustellen.

Idee 1 hat den vorteil, dass man alles an einem Ort hat und schnell in und her schalten kann. die Frage ist: wie oft muss man das machen, um einen alten Planstand zu sehen?
Idee 2 hat den Vorteil, dass die DB kleiner bleibt und nicht mit 1000 Versionen zugemüllt ist, dafür ist es etwas aufwändiger, alte Stände wieder zu laden. Dafür spart man sich aber auch ne Menge funktionen im Plugin, wie "datenstand laden", "datenstand löschen" und sowas.

Ich bin gerade dabei, die Datenhaltung für den Plan auf eine Postgre-DB umzustellen, damit wir von dort aus vielleicht gleich weiter machen können. (Plugin-technisch soll der Nutzer eingeben können, ob er in ner DB oder mit gpkg arbeiten will- so zumindest die erste Idee) An der Stelle die Frage: wie gestalten wir die Versionierung der Planstände? 1. Idee: Der Nutzer drückt nen Knopf "Planstand festschreiben" oder sowas, und es wird der Datenbestand mit einem Tag nochmal in den Tabellen abgelegt. Die Daten werden dann immer über den Tag gefiltert. (Nur Daten ohne Tag für aktuellen Stand) 2. Idee: Der Nutzer drückt den Knopf und der Datenbestand wird in ne gpkg gesichert. Die könnte man dann als Quelle angeben, wenn man das Plugin startet, um den Datenstand wiederherzustellen. Idee 1 hat den vorteil, dass man alles an einem Ort hat und schnell in und her schalten kann. die Frage ist: wie oft muss man das machen, um einen alten Planstand zu sehen? Idee 2 hat den Vorteil, dass die DB kleiner bleibt und nicht mit 1000 Versionen zugemüllt ist, dafür ist es etwas aufwändiger, alte Stände wieder zu laden. Dafür spart man sich aber auch ne Menge funktionen im Plugin, wie "datenstand laden", "datenstand löschen" und sowas.

22ottomi added the Feature label 2026-04-28 08:35:13 +02:00

22munzke commented

2026-05-07 09:44:53 +02:00

Ich favorisiere die zweite Variante.
Grundsätzlich sollten wir uns Gedanken machen, was wir als Planstand bzw. Version auffassen. Für mich fallen da zwei Sachen darunter: einerseits Bearbeitungsstände, wie z.B. geprüfte/zur Anhörung freigegebene Daten und dann die "echten" Planstände wie Gesamtplan, 1. Änderung etc.

Ich favorisiere die zweite Variante. Grundsätzlich sollten wir uns Gedanken machen, was wir als Planstand bzw. Version auffassen. Für mich fallen da zwei Sachen darunter: einerseits Bearbeitungsstände, wie z.B. geprüfte/zur Anhörung freigegebene Daten und dann die "echten" Planstände wie Gesamtplan, 1. Änderung etc.

Daniel commented

2026-05-07 10:14:37 +02:00

Also in der Ordnerstruktur bewerten wir alle Schritte bis zur Genehmigung als 1.-6. Entwurf und heben die theoretisch auch auf. Allerdings ist die Unübersichtlichkeit der Akten auch ein klein wenig unsere Nemesis. Wobei wir uns bei Variante 2 darum gar nicht selber Gedanken machen müssen, weil es an jedem LK selber liegt, wann er gerne den Export-Button drücken möchte. Die Frage ist- was ist der Workflow, um einen alten Planstand wiederherzustellen? lädt man dann die Gpkg wieder rein und kopiert Objekte in die DB und löscht dafür neuere Stände? Oder lädt man die gpkg und editiert dann die aktuellen Objekte auf den alten Stand?Ich denke, dass der Plan und seine Änderungen Versionen sind, ist unumstritten. Die Zwischenstände könnten aber auch jeweils interessant sein. Wäre die Planung sauber strukturiert und linear, bräuchte man das nicht. Aber erfahrungsgemäß ist es ein ständiges Hin und Her.
Wir brauchen ein Plan41-DB-Git... Dann behandelt man die Entwürfe als Releases und gibt den Hauptversionen (Plan, 1. Änderung...) coole Namen.

Oder- weniger cool, aber auch weniger kompliziert: eigentlich braucht man nur spezifische Planstände zu spezifischen Zwecken vernetzt. Also wäre vielleicht ein "in zentrale Datenbank übertragen"- button ne Idee. Man bearbeitet seine Entwürfe in der gpkg, undwenn man was teilen oder veröffentlichen will, geht es in die DB. entweder beim LK oder wirklich zentral

Aber ein so richtiges Zufriedenheitsgefühl erzeugt keine meiner Ideen bei mir... fühlt sich alles nicht rund an.

Also in der Ordnerstruktur bewerten wir alle Schritte bis zur Genehmigung als 1.-6. Entwurf und heben die theoretisch auch auf. Allerdings ist die Unübersichtlichkeit der Akten auch ein klein wenig unsere Nemesis. Wobei wir uns bei Variante 2 darum gar nicht selber Gedanken machen müssen, weil es an jedem LK selber liegt, wann er gerne den Export-Button drücken möchte. Die Frage ist- was ist der Workflow, um einen alten Planstand wiederherzustellen? lädt man dann die Gpkg wieder rein und kopiert Objekte in die DB und löscht dafür neuere Stände? Oder lädt man die gpkg und editiert dann die aktuellen Objekte auf den alten Stand?Ich denke, dass der Plan und seine Änderungen Versionen sind, ist unumstritten. Die Zwischenstände könnten aber auch jeweils interessant sein. Wäre die Planung sauber strukturiert und linear, bräuchte man das nicht. Aber erfahrungsgemäß ist es ein ständiges Hin und Her. Wir brauchen ein Plan41-DB-Git... Dann behandelt man die Entwürfe als Releases und gibt den Hauptversionen (Plan, 1. Änderung...) coole Namen. Oder- weniger cool, aber auch weniger kompliziert: eigentlich braucht man nur spezifische Planstände zu spezifischen Zwecken vernetzt. Also wäre vielleicht ein "in zentrale Datenbank übertragen"- button ne Idee. Man bearbeitet seine Entwürfe in der gpkg, undwenn man was teilen oder veröffentlichen will, geht es in die DB. entweder beim LK oder wirklich zentral Aber ein so richtiges Zufriedenheitsgefühl erzeugt keine meiner Ideen bei mir... fühlt sich alles nicht rund an.

22ottomi commented

2026-05-08 08:03:11 +02:00

Eine zentrale Datenbank wäre Klasse, aber das ist unrealistisch, es sei denn Erik springt wieder ein ... das pro LK zu machen wird auch schwierig, zu viele Befindlichkeiten in den LK, mir gefällt Idee 1 besser, da muss man sich nicht um die Ablage und Anbindung kümmern, zusätzlich ist aber ein Export eines Bestimmten Standes (z.B. 1. Änderung) auch nicht schlecht ...

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: AG_QGIS/Plugin_SN_Plan41#3