Erstellen effektiver Datenmodelle für das Erfassen von Felddaten

Die Bearbeitungsumgebung von ArcGIS Mobile, kombiniert mit der Performance der Geodatabase-Daten und des Transaktionsmodells, bietet eine Vielzahl von mobilen Bearbeitungslösungen und Arbeitsabläufen. Es ist sehr wichtig, dass Sie genau berücksichtigen, was in den Geodatabase-Daten und Transaktionsmodellen unterstützt oder nicht unterstützt wird, wenn Sie festlegen, wie Sie mobile Bearbeitungsanwendungen optimal mit ArcGIS Mobile unterstützen können.

Operationale und Grundkarten-Layer

Wenn Sie Karten entwerfen, die mobil mit ArcGIS Mobile bearbeitet werden, sollten Sie genau definieren, welche Karten-Layer mit einem GIS-Server synchronisiert werden (operationale Layer) und welche Layer unterstützende Hintergrundinformationen liefern (Grundkarten-Layer). Falls Layer in Ihrem Kartendokument vorhanden sind, die lediglich das Aussehen der Karte verbessern und mobilen Benutzern nicht bei der Durchführung ihrer Tasks helfen, sollten Sie diese vor dem Veröffentlichen der Karte entfernen. Gestalten Sie die Karte möglichst einfach. Vermeiden Sie die Verwendung von Definitionsabfragen, Auswahl-Layern, verbundenen Tabellen und sonstiger erweiterter ArcMap-Funktionalität. Berücksichtigen Sie die Einschränkungen des Geräts und die Bedingungen, unter denen eine Mobile-Karte verwendet wird. Möglicherweise besitzen Sie bereits mobile Anwendungen, die direkt auf einen Karten-Service zugreifen oder einen vorhandenen Cache verwenden, der aus einem mobilen Service extrahiert wurde.

Geodatabase-Unterstützung

ArcGIS Mobile unterstützt das Bearbeiten von Daten in dateibasierten und relationalen Mehrbenutzer-Geodatabases. Die Mobile-Karte kann Layer enthalten, die auf andere Datenquellen verweisen. Wenn Sie jedoch neue Features erfassen oder vorhandene Features aktualisieren möchten, muss die Datenquelle des Layers eine in einer Geodatabase gespeicherte Feature-Class sein.

Dies sind die Anforderungen für ArcGIS Mobile-Feature-Classes:

• Gespeichert in einer persönlichen oder Mehrbenutzer-ArcSDE-Geodatabase
• Muss eine GlobalID-Spalte enthalten

Jedes Feld, das Sie einer Feature-Class in der Geodatabase hinzufügen, verfügt über bestimmte Eigenschaften, die sein Verhalten bei der Bearbeitung oder beim Abfragen definieren. Die ArcGIS Mobile-Anwendungen nutzen diese Eigenschaften überall voll.

• Subtypes – Mit dem Konzept von Subtypes ist es möglich, den in einer einzelnen Feature-Class gespeicherten Inhalt in Subklassen zu unterteilen. Ein Subtype verfügt über eine Sammlung von Subtype-Codes. Für jeden Subtype-Code können Sie bestimmte Domänen und Standardwerte für andere Felder in der Feature-Class zuweisen. Innerhalb der ArcGIS Mobile-Anwendungen wird jeder Subtype-Code in einer Auswahlliste angezeigt, die wiederum Standardwerte und andere Auswahllistenwerte für andere Felder festlegt.
• Domänen – Domänen mit kodierten Werten und Bereichsdomänen werden von ArcGIS Mobile unterstützt. Jeder Domänenwert wird in einer Auswahlliste angezeigt, wenn Attributwerte erfasst oder aktualisiert werden. Die Standardwerte werden mit einem Sternchen (*) gekennzeichnet. Wenn Sie keinen Standardwert für ein Feld mit einer Domäne angeben, markiert ArcGIS Mobile dieses Feld als erforderlich und fordert Sie auf, einen gültigen Wert einzugeben, bevor die Änderungen übernommen werden. Bereichsdomänen stellen hilfreiche Tipps in der Anwendung bereit, die den Bereich gültiger Werte angeben, die Sie eingeben können. Außerdem markieren sie Felder als erforderlich, wenn kein Standardwert angegeben ist, wie dies z. B. bei Domänen mit kodierten Werten der Fall ist.
• Raster – Felder vom Typ "Raster" werden als besonderer Feldtyp erkannt, der zum Speichern von Fotos verwendet werden kann. Sie können entweder nach Fotos suchen und sie dem Raster-Feld hinzufügen oder die eingebettete Kamera direkt im mobilen Gerät verwenden.
• Datumsangaben – Datumsfelder weisen kein Konzept eines Standardwerts auf; die ArcGIS Mobile-Anwendungen machen jedoch das Festlegen des aktuellen Datums und der aktuellen Uhrzeit einfacher.
• Telefonnummern – Wenn Sie mithilfe eines Textfelds Telefonnummern speichern und ihre Telefonnummer ordnungsgemäß formatieren, sodass sie von einem Windows Mobile-Gerät mit einem eingebetteten Mobilfunkchip erkannt wird, können Sie das Telefon starten und die Nummer direkt in der mobilen Anwendung anrufen.

Hinweis:

Feature-Classes, die Z- und/oder M-Werte enthalten, können bearbeitet werden. Die Z- und/oder M-Werte gehen jedoch verloren. Für neu erfasste Features werden keine Z- und M-Werte festgelegt.

ArcGIS Mobile unterstützt auf mobilen Geräten nicht das Erstellen neuer Karten-Layer oder das Ändern des Schemas von Attributfeldern. Das Kartenschema muss bereits in der Geodatabase vorhanden sein. Sie müssen also einen entsprechenden Datenbankentwurf erstellen, der die geplanten Datenerfassungen und -bearbeitungen ermöglicht. Falls möglicherweise Features erfasst werden sollen, die im aktuellen Datenmodell nicht vorhanden sind, oder unstrukturierte Informationen (z. B. Feldbemerkungen) hinzugefügt werden, sollten Sie eine zusätzliche Feature-Class im Geodatabase-Schema erstellen, die diese Informationen aufnehmen kann.

Hinweis:

Es ist äußerst wichtig, dass Sie nach dem Erstellen eines mobilen Caches die Daten und/oder das Kartenschema nicht ändern. Eine und jede Interaktion zwischen dem mobilen Cache und der Karte/Geodatabase erfordert, dass das Schema aus Gründen der Konsistenz überprüft wird. Dies wird als Prüfsumme bezeichnet. Wenn die Karte oder die Geodatabase geändert wird, nachdem der Cache erstellt wurde, erhalten Sie bei dem Versuch, Änderungen zu synchronisieren, eine Prüfsummen-Fehlermeldung.

Überlegungen zum Geodatabase-Entwurf

Ein wichtiger Schritt beim Erstellen der mobilen Lösungen ist der Entwurf eines Geodatabase-Informationsmodells, das die mobilen Arbeitsabläufe optimal unterstützt. Die ArcGIS Mobile-Anwendungen und das SDK nutzen beide die Intelligenz, die Sie in das Datenmodell einbauen, in vollem Umfang und wie Sie diesen Inhalt mit Feature-Layern in ArcMap anzeigen.

Wenn Sie den Zweck eines vorhandenen Datenmodells für die mobile Verwendung ändern möchten, können Sie einen der folgenden Schritte ausführen:

• Nutzung des vorhandenen Informationsmodells vor Ort unter Verwendung der Geodatabase-Replikation.
• Transformieren des vorhandenen Informationsmodells unter Verwendung eines Extraktions-, Transformations- und Ladeprozesses (ETL).

Die geeignetste Vorgehensweise zum Kennenlernen des erforderlichen Ansatzes besteht darin, zu berücksichtigen, wie die mobilen Benutzer die Informationen beschreiben, die sie vor Ort erfassen/aktualisieren müssen. Die Beschreibung der mobil erfassten Informationen kann sich deutlich davon unterscheiden, wie die Informationen in der Enterprise-Geodatabase modelliert werden. Häufig werden räumliche Daten, die mobil aufgezeichnet werden, in Teilstücken erfasst. Beim Erfassen von Daten des Stadtparks beginnen die mobilen Benutzer beispielsweise an einem Ende und arbeiten sich durch den Park. Sie können einen Teil eines Seeufers erfassen, zwischendurch eine Parkbank aufnehmen und dann zum Seeufer zurückkehren. Im Unternehmens-Datenmodell werden Seen als Polygon-Features dargestellt, vor Ort werden sie jedoch als Ufer-Linien-Features erfasst. Deshalb kann es von Vorteil sein, Seen in einer separaten Geodatabase, die zum Erfassen von mobilen Daten dient, als Uferlinien zu modellieren.

Sie können Prozesse definieren, die Ihr Unternehmens-Datenmodell in ein mobiles Datenmodell transformieren. Diese Prozesse werden als ETL bezeichnet. Für dieses Beispiel können Sie einen Prozess definieren, der die Ufer-Linien-Features transformiert und zu Seepolygonen zusammenfügt, wenn Sie die Änderungen zwischen der mobilen Geodatabase und der Enterprise-Geodatabase synchronisieren.

Außerdem sollten Sie folgende zusätzliche Fragen zum Geodatabase-Entwurf berücksichtigen:

• Welche Teile des vorhandenen Datenmodells werden vor Ort benötigt (Datasets, Felder, Ausdehnungen usw.)?
• Gibt es Niederlassungen, die die mobil erfassten Bearbeitungen verwalten müssen?
• Sind neue Datasets/Layer erforderlich, um die neuen Daten, die mobil erfasst werden, aufnehmen zu können?
• In welchen Abständen müssen Aktualisierungen zwischen mobilen und Unternehmensdaten erfolgen?
• Müssen Datasets und Felddefinitionen transformiert werden, bevor sie mobil verwendet werden können?

Nachfolgend sind eine Geodatabase-Replikation und ETL als zwei separate Modelle für die Verwaltung von mobilen Bearbeitungsanwendungen unter Verwendung von Mehrbenutzer-Geodatabases beschrieben.

Geodatabase-Replikationsmodell

Sie können einfach den Inhalt Ihrer Produktions-Geodatabase zur mobilen Verwendung veröffentlichen und dann die Versionierung verwenden, um die Änderungen, die vom Außendienst eintreffen, von anderen Änderungen, die im Büro vorgenommen werden, zu trennen. Es gibt jedoch eine Reihe von potenziellen Problemen bei dieser Vorgehensweise. Wenn Sie beispielsweise Aktualisierungen vom mobilen Gerät synchronisieren möchten, muss von außerhalb der Unternehmens-Firewall auf die Produktions-Geodatabase zugegriffen werden. In den meisten Unternehmen ist dies nicht möglich. Eine bessere Methode ist die Verwendung der Geodatabase-Replikation und die Trennung der mobil erfassten Informationen von den kontinuierlich im Büro aktualisierten Informationen.

Unter Verwendung der Geodatabase-Replikation können Sie eine separate Enterprise-Geodatabase-Instanz erstellen, in der die mobil vorgenommenen Bearbeitungen gespeichert werden und die regelmäßig Aktualisierungen mit der Parent-Geodatabase synchronisiert, aus der Sie die Replikation erstellt haben. Bei dieser Vorgehensweise müssen Sie nur die Informationen replizieren, die Sie vor Ort benötigen (nicht das gesamte Informationsmodell), und Sie können mobile Web-Services aus der Master-Produktions-Geodatabase isolieren. Einige Anwendungsbeispiele für Replikationen: verteilte Systeme, in denen regionale Niederlassungen mobile Mitarbeiter haben und die nicht mit der Hauptniederlassung verbunden sind; oder wenn ein in einem Fahrzeug eingebauter Laptop eine replizierte Geodatabase enthält und die mobil vorgenommenen Änderungen synchronisiert werden, sobald das Gerät wieder im Fahrzeug angeschlossen wird. Bei beiden Beispielen sollten Sie ggf. auch die Metadaten für alle Feldbearbeitungs-Tasks speichern, die nicht in die Enterprise-Geodatabase gehören (z. B. GPS-Messdaten für die differenzielle Korrektur der erfassten Daten).

Bearbeiten einer replizierten Geodatabase, die zum Verwalten von mobilen Änderungen erstellt wurde

ETL-Modell

Häufig unterscheidet sich die Darstellung von räumlichen Informationen in einer Unternehmensdatenbank vom mobilen Erstellen und Aktualisieren der Informationen vor Ort. Ein Beispiel ist das Modellieren von Seepolygonen als Ufer-Linien-Features, sodass sie stückweise erfasst werden können. Ein weiteres ist das Verbinden von normalisierten Datentabellen oder Attributfeldern, die in der Enterprise-Geodatabase gespeichert sind, in eine Tabelle oder ein Attribut in der mobilen Geodatabase. Ein anderes Beispiel ist das Speichern von Straßenattributdaten. Häufig wird der gesamte Straßenname in mehreren Attributen gespeichert (mit Präfix, Name, Suffix usw.). In ArcMap verwenden Sie einen Ausdruck zum Beschriften des Straßennamens. Wenn Sie den Straßennamen auf einem mobilen Gerät anzeigen möchten, müssen Sie diese Attribute in einem Feld zusammenfassen, das Sie für die Beschriftung verwenden können.

Sie können Geoverarbeitungsmodelle verwenden, um die ETL-Prozesse zwischen mobilen und Enterprise-Geodatabases zu verwalten. Sie können auch die Erweiterung "ArcGIS Data Interoperability" einsetzen, um diese Transformationsprozesse visuell zu entwerfen. Beachten Sie dabei, dass die definierten Prozesse möglicherweise nicht bidirektional sind. Sie müssen einen Satz Geoverarbeitungsmodelle oder benutzerdefinierte Spatial ETL-Werkzeuge definieren, um Ihr Datenmodell für ein mobiles Gerät zu transformieren, und einen zweiten Modellsatz, um die mobilen Daten wieder an das Unternehmensschema anzupassen.

Mobiles Transaktionsmodell

Nachdem Sie das optimale Geodatabase-Datenmodell für die mobilen Editier-Tasks definiert haben, definieren Sie ein geeignetes Transaktionsmodell zum Verwalten von Aktualisierungen, die vom mobilen Gerät eintreffen. Teilweise wird dies durch die von Ihnen getroffenen Entscheidungen für das Datenmodell definiert, teilweise aber auch durch die Anzahl der zu unterstützenden mobilen Bearbeiter und die gewünschte Isolation der Bearbeitungen.

Für das Transaktionsmodell sollten Sie Folgendes berücksichtigen:

• Sollen mobile Änderungen die Version „DEFAULT“ aktualisieren? Falls nicht, soll eine Version für alle mobilen Änderungen gelten oder soll es für jeden mobilen Bearbeiter eine separate Version geben?
• Kann ich die Geodatabase überhaupt ohne Versionierung aktualisieren?
• Müssen die mobil vorgenommenen Änderungen archiviert werden?
• Wie werden Konflikte zwischen Feldaktualisierungen behandelt?

Sie benötigen Einblicke in die Funktionsweise des jeweiligen Transaktionsmodells aus Sicht der Geodatabase, bevor Sie die Transaktions-Geodatabase erstellen und mobile Karten-Services veröffentlichen. Sie müssen wissen, wie die mobile Bearbeitungsanwendung Änderungen synchronisiert.

In den folgenden Erläuterungen sind einige der wichtigsten Funktionen beschrieben, die Sie berücksichtigen sollten, wenn Sie Ihre Geodatabase für die mobile Nutzung entwerfen.

Bearbeiten einer nicht versionierten Geodatabase

Falls Sie nur wenige mobile Bearbeiter haben, die einfache Editier-Tasks durchführen (z. B. Aktualisieren von Attributfeldern), und kaum die Gefahr besteht, dass sie dasselbe Feature mobil aktualisieren, ist ein nicht versioniertes Transaktionsmodell am besten für Ihre Zwecke geeignet. Ein möglicher Nachteil dieser Methode ist, dass der mobile Bearbeiter nur direkte Aktualisierungen vornehmen kann. Falls unter Umständen Aktualisierungen synchronisiert werden müssen, die noch nicht abgeschlossen sind, wird die Synchronisierung problematisch. Mit Versionierung können die mobilen Mitarbeiter Aktualisierungen flexibler synchronisieren.

Mit einem versionierten Transaktionsmodell können Sie mobile Änderungen isolieren und zusätzliche Nachbearbeitung und Qualitätssicherungsprüfungen hinzufügen, bevor die Aktualisierungen abgeglichen werden. Je nachdem, wie mobile Änderungen isoliert werden sollen, können Sie eine einzelne Version bereitstellen, in der alle mobilen Änderungen gespeichert werden, oder für jeden mobilen Bearbeiter eine separate Version erstellen. Wenn Sie eine Version für jeden Bearbeiter erstellen, müssen Sie für jeden Bearbeiter einen mobilen Karten-Service veröffentlichen. Sobald die Bearbeiter die Datenerfassung oder -pflege abgeschlossen und ihre Aktualisierungen mit der Geodatabase synchronisiert haben, wird ArcGIS Desktop benötigt, um die Versionsänderungen im Büro mit der Parent-Version abzugleichen.

ArcGIS Mobile Client-Bearbeitungsumgebung

ArcGIS Mobile-Anwendungen haben kein Konzept zum Starten, Beenden und Speichern von Änderungen wie andere ArcGIS-Anwendungen. Jede vorgenommene Änderung wird im Cache des mobilen Service auf dem Gerät gespeichert, bis Sie die Aktualisierungen mit dem Server synchronisieren. Sie können eine Bearbeitung in der Anwendung abbrechen, woraufhin alle mobil vorgenommenen Aktualisierungen rückgängig gemacht und der Originalzustand des Features vor der Bearbeitung wiederhergestellt wird. Es ist jedoch nicht möglich, nur eine einzelne Feature-Bearbeitung rückgängig zu machen.

Beim Aktualisieren des Feature-Layers werden die Änderungen nicht direkt mit der Geodatabase synchronisiert.

Zurückschreiben von Änderungen

Die mobil durchgeführten Aktualisierungen werden lokal im Cache des mobilen Service auf dem mobilen Gerät gespeichert. Dies ist wichtig, damit keine Aktualisierungen verloren gehen, wenn die Außendienstmitarbeiter vor Ort keine Verbindung haben oder ihre Geräte herunterfahren und aufladen müssen. Sobald die Verbindung mit dem Server hergestellt ist, können die im Cache gespeicherten Aktualisierungen mit dem Server synchronisiert werden.

Wenn Änderungen vom mobilen Gerät übermittelt werden, werden nur Deltas an den Server gesendet. Wenn Sie beispielsweise ein Attribut eines Features ändern, werden nur die Änderungen an diesem einen Feld erfasst und nicht die gesamte Zeile als bearbeitet markiert. Daher werden bei der Synchronisierung der Änderungen nur die Informationen, die tatsächlich geändert wurden, zurück an den Server übermittelt. Bei der Synchronisierung von Aktualisierungen im Außendienst muss wenn möglich Bandbreite und Speicherplatz gespart werden.

Je nach der Anzahl der erwarteten Änderungen und der Art der Serververbindung (z. B. GPRS) können Sie festlegen, dass Features nur gesendet werden, wenn Anwendung und Gerät sich wieder im Büro befinden, um sicherzustellen, dass eine stabile Hochgeschwindigkeitsverbindung vorliegt.