Version vom 30. Januar 2024, 14:13 Uhr

Aktueller Stand

Für die Nutzung der Daten von kvwmap auf kleineren Endgeräten wie Handy's und auch ohne ständige Internet-Verbindung wurde die APP kvmobile entwickelt.

Die APP wird als HTML-CSS-JavaScript Anwendung ständig weiterentwickelt. Der Source Code ist auf github verfügbar. Die APP wird über Cordova für das Android Betriebssystem gebaut und verschiedene Versionen als APK-Datei zum Download angeboten.

Serverseitig ist das Plugins#Mobile Plugin mobile erforderlich. Das Plugin ermöglicht das Arbeiten im Offline-Modus in kvmobile sowie die Synchronisierung von Geodaten und Fotos zwischem dem Server und dem mobilen Endgerät.

Die APP kvmobile verbindet sich über Benutzername und Passwort mit einer Stelle in einem kvwmap und stellt dem Nutzer die in der Stelle verfügbaren Layer mobile zur Verfügung. Ohne kvwmap funktioniert die APP also derzeit nicht. kvmobile muss sich erst mindestens ein mal mit dem Server verbunden haben um die dortigen Layer auf das Endgerät zu holen. Anschließend kann der Nutzer offline arbeiten. Erst wenn wieder Internet vorhanden ist können die Daten mit dem Server synchronisiert werden.

Für die Synchronisierung wird ein Versionierungskonzept mit uuid's und Deltas verwendet. Alle Daten haben eine eindeutige uuid und eine Versionsnummer pro Layer. Wenn kvmobile sich die Daten erstmalig holt, werden diese so wie sie sind in der sqlite Datenbank in kvmobile gespeichert. Werden Änderungen durchgeführt, egal ob auf Server oder Client werden die dazugehörigen SQL-Requests als sogenannte Deltas mit hochgezählter Versionsnummer gespeichert. Bei der Synchronisierung schickt kvmobile seine Deltas zum Server, die dort ausgeführt werden, und holt sich die Deltas vom Server die vom Zeitpunkt der letzten Synchronisierung bis jetzt angelegt wurden und führt diese auf dem Client aus. In der APP kvmobile wird die neue Version gesetzt, damit sie weiß bis zu welcher Änderungen die Deltas schon ausgeführt wurden.

Werden die selben Objekte von verschiedenen kvmobil APP's gleichzeitig bearbeitet, überschreibt immer die letzte Synchronisierung vorherige. Wenn die Abstände zwischen den Synchronisierungen größer sind, z.B. weil schlechtes Internet verfügbar ist, ist es also ratsam die Daten die bearbeitet werden sollen vorher in Bereiche für verschiedene Mitarbeiter aufzuteilen.

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.

Installation auf Android

• Aktuelle Version der apk-Datei von [1] auf dem mobilen Endgerät über einen Browser runterladen und lokal auf dem Gerät speichern, z.B. unter Downloads.
• Heruntergeladene Daten öffnen.
• Bestätigen, dass kvmobile installiert werden soll.
• App wurde installiert. Öffnen
• Authentifizierung mit Fingerabdruck, Muster oder Code. Je nachdem was auf dem Gerät eingestellt ist.
• Ok zur Meldung "Wählen Sie eine Konfiguration aus und Stellen die Zugangsdaten zum Server ein"
• Nach unten scrollen und Einstellung Konfiguration öffen und die gewünschte Konfiguration auswählen.

• Die App startet neu. Noch mal authentifizieren und dann Hinweis bestätigen.
• In Einstellungen unter Server den Nutzernamen und das Passwort eintragen.

• Button "Stellen abfragen" anklicken
• Stelle auswählen und Button "Einstellungen Speichern" klicken

• Unter Layer Button "Layer abfragen" anklicken"

• Warten bis alle Layer geladen sind. Die Liste der Layer wird angezeigt.
• Einen Layer zur Bearbeitung auswählen

• Oben Listen- oder Kartenansicht auswählen.

Offline Daten

Layer

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. Derartige Daten werden in kvmobile als Layer bezeichnet. Jeder Layer in kvmobile entspricht einem Layer in kvwmap. Zur Verarbeitung in kvmobile 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.

Overlay

In kvmobile werden auch die Layer aus kvwmap geladen, die den Status sync nicht gesetzt haben. Um sie von den Layern zu unterscheiden heißen sie in kvmobile Overlays. Die Overlays können in kvmobile nur in der Karte angezeigt werden. Derzeig in Version 1.7.13 können die Sachdaten der Overlays noch nicht abgefragt oder angezeigt werden. Das ist noch in Entwicklung.

Background-Layer

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. Es wurde auch ein Dienst auf gdi-service.de eingerichtet über den Kacheln herunter geladen werden können. Der Konfigurationsdatei configurations.js sind für jeden Landkreis in dem bisher kvmobile genutzt wird verschiedene Hintergrundkarten konfiguriert. Der Layer Vektorkacheln offline z.B. läd die Kacheln für die Ausdehnung der Anwendung und cached diese auf dem mobilen Endgerät. Dazu ist die Funktion Einstellungen > Offline-Karten > herunterladen anzuwenden.

Einstellungen

Unter dem Menüpunkt Einstellungen können die Farben für die Marker, Linien und Polygone angegeben werden, die mit dem Attribut Status klassifiziert sind. Im Abschnitt Farben kann man auf das Kästchen klicken und die Farbe aus einem Color-Picker wählen und übernehmen.

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.