kvmobile

App kvmobile

Aktueller Stand

kvmobile funktioniert zur Zeit für die Erfassung von Punktobjekten mit Bildern und Position. Die aktuellste Version kann man im Github finden unter [1]. Für die Verwendung mit kvwmap-Server müssen einige Voraussetzungen erfüllt werden, die hier beschrieben sind. Gerade sind wir dabei die Anwendung für die Bearbeitung von Linien und Flächen weiterzuentwickeln. Dabei setzen wir auf die Leaflet Draw API siehe [2] und Demo.

Ankündigung

kvwmap bekommt einen kleinen Ableger zur Erfassung Geodaten mit mobilen Endgeräten. Wir haben dieses Jahr gestartet eine entsprechende App zu programmieren, mit der Haltestellen erfasst werden können. Die App soll offline funktionieren und die Daten mit der Datenbank des Web-GIS kvwmap synchronisieren können. Der Zugriff auf die Datenbank erfolgt über das Web-GIS kvwmap. Nutzer der App müssen sich also an einer Stelle in kvwmap authotisieren und können dann Daten eines in der Stelle zugeordneten Layers austauschen. Eine Hintergrundkarte kann für das Bearbeitungsgebiet vor der Arbeit im freien Einsatz gecached werden. Wie das passiert ist aber noch nicht genau festgelegt. Denkbar wäre das cachen von Rasterkarten aber auch die Verwendung von Vektor-Tiles, die dann aber natürlich in der App gerändert werden müssten. Da viele sicher das Luftbild im Hintergrund benötigen, wird man wohl um das cachen von Rasterkacheln in der mobilen App nicht drum herum kommen. kvmobile unterscheidet sich jedenfalls von dem ursprünglichen Ansatz einer mobilen Nutzung von kvwmap dadurch, dass kein Server mehr auf dem mobilen Endgerät notwendig ist. Die Ressourcen des Endgerätes (Handy, Tablet, etc.) werden über die Plattform Cordova hergestellt. Cordova stellt eine API zur Verfügung mit der man mit JavaScript auf mobile Ressourcen, z.B. die Camera, GPS, Speicher, Internet, etc. zugreifen kann. Wobei hier nicht der Browser mit JavaScript auf die Ressourcen zugreift, sondern man programmiert das in seiner Entwicklungsumgebung nur so als wäre es eine Web-Anwendung. Cordava erzeugt dann in einem build Prozess aus dieser Web-Anwendung eine App für die jeweilige Zielplattform. (zum Test zunächst Android 25)

kvmobile ist eine App, die zunächst für Android entwickelt wird. Da kvmobile auf der Platform cordova entwickelt wird, können später aber auch Apps für andere Betriebssysteme wie iOS oder BlackBerry kompiliert werden.

Es ist geplant die Anwendung in 2017 für Tests dem Auftraggeber zur Verfügung zu stellen, damit sie in 2018 erstmalig in der Praxis eingesetzt werden kann. Ist die Einführung erfolgreich, werden weitere Funktionen hinzugefügt. Das Ziel ist die Erfassung beliebiger Daten von Layern, die in kvwmap als mobile Layer freigegeben wurden. Dabei sollen die Erfassungsformulare entsprechend der Definition im Attribut-Editor auch generisch auf der App erscheinen. Ein weiterer Schritt wäre die wahlweise Erfassung von verschiedenen Layern in einer einzelnen App. Derzeit kann in der App erstmal nur ein Layer erfasst werden.

Offline Daten

kvmobile ist so konzipiert, dass Daten, die in kvwmap als PostGiS-Layer definiert sind und bei denen die sync-Option in den Layereinstellungen ausgewählt sind, nach dem Laden in der App offline bearbeitet werden können. Dazu werden die Daten von der App in eine sqlite Datenbank-Tabelle geschrieben, die lokal auf dem Endgerät liegt und die gleiche Datenstruktur wie auf dem Server hat. Alle Änderungen und neue Daten werden zunächst in diese sqlite Datenbank geschrieben. Alle dafür verwendeten SQL-Statement (Deltas) werden ebenfalls in der Datenbank gespeichert. Hat der kvmobile Nutzer eine Internetverbindung, kann er eine Syncronisation aufrufen. Dabei werden die Deltas an den Server übermittelt dort ausgeführt und die auf dem Server hinterlegten Deltas an den Client gesendet, der diese wiederum auch ausführt.

Bilder werden beim Syncronisieren nicht automatisch mit übertragen, da dies sehr viele sein können. Sind in einem Layer viele Bilder vorhanden und ist im Projektgebiet schlechter Internet-Empfang, Empfiehlt es sich die Bilder vor dem offline-arbeiten über eine USB-Verbindung auf das Endgerät zu übertragen. Ansonsten werden die einzelnen Bilder einmalig nachgeladen wenn man ein Formular zur Ansicht aufmacht in dem ein oder mehrere Bilder zum Datensatz gehören. Die Bilder stehen dann lokal auf dem Endgerät zur Verfügung. Macht man selber neue Bilder, werden diese auch zunächst lokal auf dem Endgerät gespeichert und dazu Image-Deltas angelegt. Hat der Nutzer Internet, kann er die Funktion Bild-Upload aufrufen und neuen lokalen Bilder werden zum Server gesendet. Dazu sollte man eine gute Internetverbindung z.B. mit WLAN haben.

Als Hintergrundkarten werden Kacheln verwendet. Standardmäßig wird hier die ORKA von MV eingesetzt. Wird die App aufgerufen mit Inernetverbindung ist die Hintergrundkarte überall zu sehen. Will man jedoch offline Arbeiten und die Hintergrundkarten auch nutzen sollten man sich die Kacheln von seinem Projektgebiet vorher herunterladen und auch per USB auf das Endgerät laden. Für einige Gebiete sind vorgefertigte Kacheln in tar.gz Dateien gepackt worden in Zukunft wäre jedoch ein entsprechender Kacheldownloader sindvoll. Eine entsprechende Anfrage für so ein Kachel-Download-Tool wurde an HRO gestellt.

Changemanagement und Historisierung

In kvmobile werden Änderungen der Reihe nach als SQL-Statements in die Deltas Tabelle geschrieben. Das führt zu zwei Problemen:

1. Wenn bei einer Synchronisierung der Daten mit dem Server ein Delta-Statement fehl schlägt, z.B. weil ein Serverseitiges Constraint nicht erfüllt wird, müssen alle folgenden Deltas abgebrochen werden, da sonst inkonsistente Datenbestände entstehen können. Das gilt besonders wenn verknüpfte Tabellen verwendet werden.
2. Wenn ein Datensatz gelöscht wird, müssen vorherige Änderungen nicht ausgeführt werden und im Client erzeugte neue Datensätze können aus dem Delta raus und es muss dazu kein INSERT Delta angelegt werden.

Um diese Probleme löschen zu können, wird eine einfache Historisierung eingeführt, die im folgenden ausführlich beschrieben wird. Im Client bekommen die Datentabellen alle eine zusätzliche Spalte endet, die nicht mit synchronisiert wird. Wenn dort ein Zeitstempel drin steht ist der Datensatz untergegangen, sonst nicht. Der Ausgangszustand nach einer Synchronisation ist eine leere Deltas-Tabelle und alle Datensätze haben im Attribut endet = NULL. Bei Änderungen im Client passiert folgendes:

Änderungen

INSERT

• Ablauf
  • INSERT Delta erzeugen
  • INSERT Delta eintragen
  • INSERT Delta als SQL ausführen
• Ergebnis
  • Neuer INSERT Datensatz in Deltatabelle
  • Neuer Datensatz in Datentabelle mit endet = NULL

1. UPDATE

(wenn es noch keinen Datensatz mit gleicher id und endet IS NOT NULL gibt)

• Ablauf
  • UPDATE Delta erzeugen
  • UPDATE Delta eintragen
  • vorhandenen Datensatz als neuen Datensatz mit endet = Datum neu einfügen
  • UPDATE Delta als SQL ausführen auf Datensatz mit id und endet IS NULL
• Ergebnis
  • Neuer UPDATE Datensatz in Deltatabelle
  • Kopie von Datensatz mit Zustand von vor der Änderung in Datentabelle mit endet = Datum
  • Aktueller Datensatz mit letzten Änderungen in Datentabelle

n. UPDATE

(wenn es schon einen Datensatz mit gleicher id und endet IS NOT NULL gibt)

• Ablauf
  • UPDATE Delta erzeugen
  • UPDATE Delta eintragen
  • UPDATE Delta als SQL ausführen auf Datensatz mit id und endet IS NULL
• Ergebnis
  • Neuer UPDATE Datensatz in Deltatabelle
  • Aktueller Datensatz mit letzten Änderungen in Datentabelle

zwischen dem UPDATE eines neuen und eines vorhandenen Datensatzes gibt es keine Unterschiede, außer, dass in der Deltastabelle bei einem neuen Datensatz nach vor UPDATE Deltas ein INSERT Delta steht und bei vorhandenen nur UPDATE Deltas.

DELETE eines vorhandenen Datensatzes

• Ablauf
  • DELETE Delta erzeugen
  • Alle Deltas mit gleicher id löschen (können nur UPDATE Deltas sein, weil es kein INSERT gibt für schon vorhandene Datensätze und kein DELETE weil man einen Datensatz nicht zwei mal löschen kann.)
  • DELETE Delta eintragen
  • DELETE Delta als SQL ausführen auf Datensatz mit gleicher id und endet IS NULL
• Ergebnis
  • Es gibt nur einen DELETE Delta von diesem Datensatz in der Deltatabelle
  • Datensatz mit endet IS NULL fehlt in Datentabelle
  • Datensatz mit endet = Datum existiert noch

DELETE eines neuen Datensatzes

(nach der Synchronisierung angelegter und auch ggf. geänderter Datensatz)

• Ablauf
  • DELETE Delta erzeugen
  • Alle Deltas mit gleicher id löschen (können INSERT und UPDATE Statements sein, denn neue Datensätze haben ein INSERT und DELETE geht nur ein mal.)
  • kein! DELETE Delta eintragen weil ein neuer, der gelöscht wurde nicht synchronisiert werden muss.
  • DELETE Delta als SQL ausführen auf Datensatz mit gleicher id und endet IS NULL
• Ergebnis
  • Der Datensatz taucht gar nicht mehr in der Deltatabelle auf.
  • Datensatz mit endet IS NULL fehlt in Datentabelle
  • Datensatz mit endet = Datum existiert noch

Deltas vor dem Synchronisieren

• Neue Datensätze haben ein INSERT wenn nichts geändert wurde oder ein oder mehrere UPDATES
• vorhandene Datensätze haben wenn nichts geändert wurde keine Deltas, ein oder mehrere UPDATES oder ein DELETE

Wiederherstellung

Um ein Delta, welches zu einem Fehler auf dem Server führt korrigieren oder aufheben zu können wurden Wiederherstellungen eingeführt. Bei einer Wiederherstellung werden folgende Schritte immer ausgeführt:

• Ablauf
  • alle UPDATE und DELETE Deltas mit der id löschen
  • den Datensatz mit endet = NULL gelöscht
  • den historische Datensatz mit endet = Datum auf endet = NULL setzen.

Die Vorgehensweise bei den Deltas unterscheiden sich jedoch wie folgt:

Einen geänderten Datensatz wiederherstellen

• Ablauf
  • Beim Löschen von Deltas sind nur UPDATE Deltas betroffen, weil der Datensatz ja nicht auf dem Client erzeugt oder gelöscht wurde.
• Ergebnis
  • Es gibt genau einen Datensatz mit endet = NULL in der Version wie nach der letzten Synchronisation.
  • Der Datensatz hat keine Deltas.

Einen gelöschten Datensatz wiederherstellen

• Ablauf
  • Beim Löschen der Deltas ist nur ein DELETE Delta betroffen, weil nach einem Delete keine UPDATE oder INSERT Deltas mehr da sind.
• Ergebnis
  • Es gibt genau einen Datensatz mit endet = NULL in der Version wie nach der letzten Synchronisation.
  • Der Datensatz hat keine Deltas.

Einen neuen Datensatz, der zuvor geändert wurde wiederherstellen

• Ablauf
  • Beim Löschen von Deltas sind nur UPDATE Deltas betroffen. Das INSERT Delta brauchen wir noch, weil der Datensatz ja neu auf dem Client ist.
• Ergebnis
  • Es gibt genau einen Datensatz mit endet = NULL in der Version wie nach dem neuen Anlegen des Datensatzes.
  • Der Datensatz hat nur ein INSERT Delta.

Einen neuen Datensatz, der zuvor gelöscht wurde wiederherstellen

• Ablauf
  • Beim Löschen von Deltas sind praktisch keine betroffen, weil der neue Datensatz ja gelöscht wurde und keine Deltas von ihm da sind.
  • Ein INSERT Delta erzeugen auf der Basis des wiederherzustellenden Datensatzes.
  • Das INSERT Delta eintragen.
• Ergebnis
  • Es gibt genau einen Datensatz mit endet = NULL in der Version wie nach dem neuen Anlegen des Datensatzes.
  • Der Datensatz hat nur ein INSERT Delta.