Wunsch-Liste

Ideen für zukünftige Entwicklungen, Diskussion über geplante Entwicklungen. Bei allgemeinem Konsens werden diese Punkte in die ToDo-Liste aufgenommen. zur ToDo-Liste

Aliasnamen für Layer

Es wäre schön, wenn beim Layer erstellen die Vergabe eines Aliasnames möglich wäre. Verschiedene Planungsstände werden bei uns in verschiedenen Stellen verwaltet. Um in der Liste der Layer bei der Administration den Überblick zu behalten heißen die dann rrep_hochspannung, lep_hochspannung, rok_hochspannung usw. Das macht für den Anwender wenig Sinn, da er innerhalb einer Stelle nur einen Planungsstand sieht.

Historisierung der PostGIS-Daten

--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.

Funktionalität

Allgemein/sonstiges

- Layer bzw. Tabellen die historisiert werden sollen können ausgewählt werden, keine automatische Historisierung aller Tabellen, bzw. nur Tabellen eines bestimmten Shema’s werden historisiert

- ALK/ALB keine Historisierung erforderlich, nur für Fachdaten nicht für Basisdaten

- es soll eine Nachvollziehbarkeit erreicht werden, im Sinne wer hat wann welche Werte geändert (eng verzahnt mit der Suche) [create_user, last_user, start_date, archive_date] mit der Möglichkeit herauszufinden welche Veränderungen vorgenommen wurden [change_type, change_affected_columns]

- räumlich zeitliches Archiv von Geodaten

- Rechtssicherheit soll gewährleistet werden (ALKIS)

Suche in den historisierten Daten

- Kalenderfunktion zum Auswählen eines bestimmten Zeitpunktes und anzeigen der Geometrie und Sachdaten zu diesem Zeitpunkt

- zeitliche Verfolgung eines Datensatzes bzw. Anzeigen wann Änderungen vorgenommen worden sind (Zeitstrahl) incl. Auswahlmöglichkeit des Zeitpunktes der Anzeige auf dem Zeitstrahl

- suche über Attribute wie jetzt auch nur mit Angabe einen Zeitpunktes oder Zeitraumes

Editieren und Löschen der Daten (kvwmap Funktionen plus andere Möglichkeiten)

- Sachdaten bearbeiten mit generischem Layer Editor

- Geometrie bearbeiten mit geometrie Editor

- Shape Dateien ausgeben, mit externem GIS Programm bearbeiten (z.B. ArcGIS) und wieder einlesen, also aktualisieren von Shapes (externe Daten z.B. LUNG) direkt über die kvwmap Funktion

- Shape Dateien können auch über die Konsole ein und ausgelesen werden, auch dort sollte es funktionieren

- Änderung von Daten mit direktem Zugriff auf die Datenbank aus einem externen GIS (z.B. QuantumGIS)

- Bearbeiten von Daten in der Datenbank über pgAdmin3 (nur Admin)

- Unterstützung der mobilen kvwmap Version, Layer Exportieren und wieder aktualisieren

- Möglichkeit zur Sperrung der Bearbeitung von Layern

- beim Löschen eines Datensatzes soll dieser „historisiert gesetzt werden“ und nicht aus der DB gelöscht

Wiederherstellung

- von einzelnen Datensätzen

- der ganzen Datensammlung

Anwenderfreundlichkeit

Zuverlässigkeit

Performance

- Kosten gering, Open Source

- Performance (Reaktionszeiten) von ? (1s)

Unterstützbarkeit

- Anpassungsmöglichkeit bei Datenbankwechsel von Postgre zu einer anderen Datenbank

- Wechsel des GIS Systems kvwmap

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

Ansätze aus der Diplomarbeit von Tobias Beckmann

Einfache Themenübersicht

--Hschmidt 10:50, 4. Mai 2011 (CEST)
Analog zur "Benutzer-Stellen-Übersicht" wäre eine "Themen-Gruppen-Übersicht" wünschenswert. Wenn man die Layer-Tabelle noch mit einem Feld "abstract" erweitert, könnte aus der Datenbank eine aktuelle Übersicht der Themen nach Gruppen gruppiert ausgegeben werden:

Gruppe | Name | Kurzbeschreibung (wirklich kurz!).

--Reißland 13:55, 4. Mai 2011 (CEST) Wenn man dabei etwas mehr Arbeit investieren würde und weitere Informationen zu den Themen (Datentyp, Koordinatensystem, Tabellen-/Attributnamen etc.) bereitstellt, könnte das Ganze als "Metadatenkatalog" für die kvwmap-Nutzer fungieren.

Alle Abfragehaken löschen

--Markus Hentschel 12:15, 21. Apr 2011 (CEST) Ein Link/Button, der alle Abfragehaken des Users in der Stelle löscht. Vielleicht unterhalb von "neu laden"?

ALK+DOP Ausdruck

--Markus Hentschel 07:38, 18. Apr 2011 (CEST) Es wird der kombinierte ALK+DOP Ausdruck als Produkt gefordert. Irgendwie müsste also geloggt werden, wenn im ALK-Auszug auch das Luftbild zu sehen ist.

Logging der CSV-Exporte

--Markus Hentschel 07:38, 18. Apr 2011 (CEST) Die ÖbVI wollen über den CSV-Export listenförmige Zusammenstellungen aus dem ALB machen und das möglicherweise auch dem Bürger verkaufen. Dafür muss der CSV-Export protokolliert werden. Es muss auch unterscheidbar sein, ob für interne Zwecke exportiert wurde oder für den Bürger.

Umringspolygon speichern

--Markus Hentschel 14:00, 15. Feb 2011 (CET) Von Seiten der ÖbVIs besteht der Wunsch, ein Umringspolygon als ASCII-Datei speichern zu können, das das Katasteramt dann in die ALK-Auskunft laden kann, d.h. es muss das *.uko-Format entstehen.