Historisierung der PostGIS-Daten - Versionsgeschichte

Rahn am 22. August 2011 um 08:39 Uhr

2011-08-22T08:39:32Z

Rahn am 22. August 2011 um 08:39 Uhr

2011-08-22T08:39:23Z

Rahn am 14. September 2009 um 08:33 Uhr

2009-09-14T08:33:52Z

Neue Seite

Wünschenswert und vor dem Hintergrund der sich ändernden Rechtslage auch notwendig wäre die Historisierung aller in der PostGIS-DB gespeicherter Daten bei Änderung und Löschung. Dazu gibt es einen Ansatz des Kantons Solothurn, der übertragbar scheint. Die Historisierung müsste von kvwmap automatisch betrieben werden, so dass beim Anlegen von Layern die für die Historisierung notwendigen Ergänzungen am Layer und an der Datenbanktabelle von kvwmap und nicht vom Admin vorgenommen werden. Gleichzeitig müsste es eine "historische generische Layersuche" geben, die es ermöglicht, nach allen Daten unter Berücksichtigung der Dimension Zeit zu suchen (Zeitpunkte oder Zeiträume). Es müsste untersucht werden, wie das Ganze bei Exporten und damit verbundenen Reimporten von Massendaten funktioniert. Also bei der kvwmap-Mobil-Version oder bei Shape-Exporten mit anschließender Bearbeitung und Reimport.

← Nächstältere Version		Version vom 22. August 2011, 08:39 Uhr
Zeile 1:		Zeile 1:
−	~~== Historisierung der PostGIS-Daten ==~~
	--[[Benutzer:Eulenberger\|Andreas Eulenberger]] 9:50, 09. Mai 2011 (CEST)		--[[Benutzer:Eulenberger\|Andreas Eulenberger]] 9:50, 09. Mai 2011 (CEST)
	Wünschenswert und vor dem Hintergrund der sich ändernden Rechtslage auch notwendig wäre die Historisierung aller in der PostGIS-DB gespeicherter Daten bei Änderung und Löschung. Dazu gibt es einen Ansatz des Kantons Solothurn, der übertragbar scheint. Die Historisierung müsste von kvwmap automatisch betrieben werden, so dass beim Anlegen von Layern die für die Historisierung notwendigen Ergänzungen am Layer und an der Datenbanktabelle von kvwmap und nicht vom Admin vorgenommen werden. Gleichzeitig müsste es eine "historische generische Layersuche" geben, die es ermöglicht, nach allen Daten unter Berücksichtigung der Dimension Zeit zu suchen (Zeitpunkte oder Zeiträume). Es müsste untersucht werden, wie das Ganze bei Exporten und damit verbundenen Reimporten von Massendaten funktioniert. Also bei der kvwmap-Mobil-Version oder bei Shape-Exporten mit anschließender Bearbeitung und Reimport.		Wünschenswert und vor dem Hintergrund der sich ändernden Rechtslage auch notwendig wäre die Historisierung aller in der PostGIS-DB gespeicherter Daten bei Änderung und Löschung. Dazu gibt es einen Ansatz des Kantons Solothurn, der übertragbar scheint. Die Historisierung müsste von kvwmap automatisch betrieben werden, so dass beim Anlegen von Layern die für die Historisierung notwendigen Ergänzungen am Layer und an der Datenbanktabelle von kvwmap und nicht vom Admin vorgenommen werden. Gleichzeitig müsste es eine "historische generische Layersuche" geben, die es ermöglicht, nach allen Daten unter Berücksichtigung der Dimension Zeit zu suchen (Zeitpunkte oder Zeiträume). Es müsste untersucht werden, wie das Ganze bei Exporten und damit verbundenen Reimporten von Massendaten funktioniert. Also bei der kvwmap-Mobil-Version oder bei Shape-Exporten mit anschließender Bearbeitung und Reimport.

← Nächstältere Version		Version vom 22. August 2011, 08:39 Uhr
Zeile 1:		Zeile 1:
−	Wünschenswert und vor dem Hintergrund der sich ändernden Rechtslage auch notwendig wäre die Historisierung aller in der PostGIS-DB gespeicherter Daten bei Änderung und Löschung. Dazu gibt es einen Ansatz des Kantons Solothurn, der übertragbar scheint. Die Historisierung müsste von kvwmap automatisch betrieben werden, so dass beim Anlegen von Layern die für die Historisierung notwendigen Ergänzungen am Layer und an der Datenbanktabelle von kvwmap und nicht vom Admin vorgenommen werden. Gleichzeitig müsste es eine "historische generische Layersuche" geben, die es ermöglicht, nach allen Daten unter Berücksichtigung der Dimension Zeit zu suchen (Zeitpunkte oder Zeiträume). Es müsste untersucht werden, wie das Ganze bei Exporten und damit verbundenen Reimporten von Massendaten funktioniert. Also bei der kvwmap-Mobil-Version oder bei Shape-Exporten mit anschließender Bearbeitung und Reimport.	+	== Historisierung der PostGIS-Daten ==
		+	--[[Benutzer:Eulenberger\|Andreas Eulenberger]] 9:50, 09. Mai 2011 (CEST)
		+	Wünschenswert und vor dem Hintergrund der sich ändernden Rechtslage auch notwendig wäre die Historisierung aller in der PostGIS-DB gespeicherter Daten bei Änderung und Löschung. Dazu gibt es einen Ansatz des Kantons Solothurn, der übertragbar scheint. Die Historisierung müsste von kvwmap automatisch betrieben werden, so dass beim Anlegen von Layern die für die Historisierung notwendigen Ergänzungen am Layer und an der Datenbanktabelle von kvwmap und nicht vom Admin vorgenommen werden. Gleichzeitig müsste es eine "historische generische Layersuche" geben, die es ermöglicht, nach allen Daten unter Berücksichtigung der Dimension Zeit zu suchen (Zeitpunkte oder Zeiträume). Es müsste untersucht werden, wie das Ganze bei Exporten und damit verbundenen Reimporten von Massendaten funktioniert. Also bei der kvwmap-Mobil-Version oder bei Shape-Exporten mit anschließender Bearbeitung und Reimport.
		+
		+	'''Diplomarbeit Thema: "Konzeption zum Aufbau einer Historienverwaltung in kvwmap"'''
		+
		+	Der Hauptbestandteil der Diplomarbeit ist eine Anforderungsanalyse, damit auf dieser Grundlage eine Implementierung erfolgen kann.
		+
		+	Anforderungen (engl. requirements) sind Funktionen und Bedingungen, die ein System erfüllen sollte, um Ziele des Auftraggebers zu erreichen. Dabei handelt es sich auch um Interaktionen zwischen einem System und seinen Benutzern bzw. die Zustände des Systems vor und nach den Interaktionen. Wegen der Vielfalt von Anforderungen eines Systems werden sie durch eine Kategorisierung voneinander unterschieden.
		+
		+	'''Kategorien von Anforderungen'''
		+
		+	Nach dem sogenannten FURPS+-Modell werden Anforderungen kategorisiert. ”FURPS“ ist eine Abkürzung für die folgenden Attribute
		+
		+	• Funktionalität (engl. functional) - Features, Fähigkeiten, Sicherheit.
		+
		+	• Anwenderfreundlichkeit (engl. Usability) - Humanfaktoren, Hilfe, Dokumentation.
		+
		+	• Zuverlässigkeit (engl. Reliability) - Misserfolgsquote, Wiederanlauffähigkeit,
		+	Vorhersagbarkeit.
		+
		+	• Performance (engl. Performance) - Reaktionszeiten, Durchsatz, Genauigkeit,
		+	Verfügbarkeit, Ressourceneinsatz.
		+
		+	• Unterstützbarkeit (engl. Supportability) - Anpassungsfähigkeit, Wartbarkeit,
		+	Internationalisierung, Konfigurierbarkeit.
		+
		+
		+	{\| border=1
		+	\|-
		+	! Nr !! Kategoie !! Name
		+	\|- style="background:#FC9272"
		+	\| 1 \|\| F \|\| Auswahl der zu historisierenden Datenbanktabellen
		+	\|-
		+	\| 2 \|\| F \|\| Historisierung für ALK/ALB - Daten
		+	\|- style="background:#FC9272"
		+	\| 3 \|\| A \|\| Nachvollziehbarkeit und Nachweisbarkeit der Änderungen
		+	\|- style="background:#FFF7BC"
		+	\| 4 \|\| F \|\| eigene Eingabe von Gültigkeitszeiträumen
		+	\|- style="background:#FC9272"
		+	\| 5 \|\| F \|\| Kalenderfunktion zur Anzeige
		+	\|- style="background:#FC9272"
		+	\| 6 \|\| F \|\| zeitliche Verfolgung der Änderungen eines Datensatzes
		+	\|- style="background:#FFF7BC"
		+	\| 7 \|\| F \|\| Suche nach Attribute zu einem Zeitpunkt oder in einem Zeitraum
		+	\|- style="background:#FC9272"
		+	\| 8 \|\| F \|\| Historisierung der Änderungen über den generischem Layer Editor (Sachdaten und Geometrie)
		+	\|- style="background:#FC9272"
		+	\| 9 \|\| F \|\| Historisierung der Daten die über Shape Dateien aktualisiert werden [kvwmap]
		+	\|- style="background:#FFF7BC"
		+	\| 10 \|\| F \|\| Historisierung der Daten die über Shape Dateien aktualisiert werden [Konsole]
		+	\|- style="background:#FC9272"
		+	\| 11 \|\| F \|\| Historisierung der Daten die über direktem Zugriff auf die Datenbank aus einem externen GIS Programm (z.B. QuantumGIS, OpenJump)aktualisiert werden
		+	\|- style="background:#FFF7BC"
		+	\| 12 \|\| F \|\| Historisierung der Daten die über pgAdmin3 aktualisiert werden
		+	\|- style="background:#FC9272"
		+	\| 13 \|\| F \|\| Unterstützung der mobilen kvwmap Version
		+	\|- style="background:#FC9272"
		+	\| 14 \|\| F \|\| Möglichkeit zur Sperrung der Bearbeitung von Layern oder Mehrbenutzerverwaltung
		+	\|- style="background:#FC9272"
		+	\| 15 \|\| F \|\| Wiederherstellen von einzelnen Datensätzen
		+	\|- style="background:#FC9272"
		+	\| 16 \|\| F \|\| Wiederherstellen der ganzen Datensammlung
		+	\|- style="background:#FC9272"
		+	\| 17 \|\| A \|\| für den Standardbearbeiter sollte die Handhabung einfach sein
		+	\|- style="background:#FC9272"
		+	\| 18 \|\| P \|\| keine oder möglichst geringe Kosten
		+	\|- style="background:#FC9272"
		+	\| 19 \|\| P \|\| akzeptable Performance
		+	\|-
		+	\| 20 \|\| U \|\| weitere Verwendbarkeit bei einem Datenbankwechsel von PostgreSQL zu einer anderen Datenbank
		+	\|- style="background:#FFF7BC"
		+	\| 21 \|\| U \|\| weitere Verwendbarkeit bei einem Wechsel des GIS Systems
		+	\|- style="background:#FC9272"
		+	\| 22 \|\| F \|\| Möglichkeit Fehler manuell zu beheben
		+	\|- style="background:#FFF7BC"
		+	\| 23 \|\| F \|\| Historisierung von Rasterbildern
		+	\|}
		+
		+
		+
		+	'''Implementierung'''
		+
		+	Ansätze aus der Schweiz, Live + Repository
		+
		+	Erweiterung der Tabellen um 7 Spalten, eine id zur Verknüfung, create_date, archive_date, last_user, create_user, change_type, change_affected_columns
		+
		+	[[Bild:tabtest.jpg]]
		+
		+	Ansätze aus der Diplomarbeit von Tobias Beckmann