Entwerfen effektiver Datenmodelle für das Erfassen von Felddaten

GIS-Karten (Geographic Information System) bestehen aus operationalen und Grundkarten-Layern. Operationale Layer dienen zum Bearbeiten und Identifizieren von Features. Grundkarten-Layer stellen visuelle Referenzinformationen im Hintergrund bereit. Beispielsweise verfügt ein Außendienstprojekt, das die Erfassung von XY-Positionen und Attributen neu platzierter Wasserventile in einer Unterteilung beinhaltet, über einen operationalen Wasserventil-Layer. Dies ist der Layer, der vor Ort bearbeitet wird. Sie können auch einen operationalen Layer für Wasserleitungen zum Identifizieren einzelner Wasserleitungen als Hilfestellung für den Außendienstmitarbeiter verwenden. Unter diesen operationalen Layern können Sie einen Grundkarten-Layer mit Luftbilddaten für diesen operationalen Bereich einbeziehen, um Straßen, Parks und andere Hintergrund-Interessenbereiche anzuzeigen.

Für Außendienstprojekte sollte die Karte so einfach wie möglich gestaltet sein. Vermeiden Sie unnötige Layer und andere Zusatzfunktionen von ArcGIS for Desktop. Berücksichtigen Sie die Einschränkungen des mobilen Geräts und die Bedingungen im Außendienst, wo die Karte verwendet wird.

Geodatabase-Unterstützung

Mobile-Services und Mobile-Caches, die mit dem Werkzeug Mobile-Cache erstellen, ArcGIS for Windows Mobile erstellt wurden, unterstützen die Bearbeitung von Daten in dateibasierten und Mehrbenutzer-ArcSDE-Geodatabases. Die Mobile-Karte kann Layer enthalten, die auf andere Datenquellen verweisen. Sollen diese Layer auch bearbeitet werden können, muss die Datenquelle des Layers zumindest eine in einer Geodatabase gespeicherte Feature-Class sein. Näheres zu den Anforderungen an einen editierbaren Layer können Sie dem nachstehenden Abschnitt Datenschemaanforderungen für die Zwecke von operationalen Layern entnehmen.

Hinweis:

Beachten Sie bitte auch, dass eine Feature-Class keine Feldnamen aufweisen darf, die für die SQL-Sprache reserviert sind.

Hinsichtlich der Anforderungen an die Datenquelle unterliegen gehostete Feature-Services weniger Beschränkungen als Mobile-Services. Ihre Daten können aus einer dateibasierten Geodatabase, einer ArcSDE-Geodatabase, CSV oder Shapefiles stammen. Wenn Sie diese Quelldaten als gehostete Feature-Services veröffentlichen, lassen sie sich über die Außendienstanwendungen bearbeiten. Wird ein Datensatz jedoch in Form eines gehosteten Feature-Services veröffentlicht, werden die Daten in den Online-Speicher ArcGIS Online für Organisationen oder Portal for ArcGIS kopiert; daher gelangen eventuelle vom Außendienstteam vorgenommenen Änderungen nicht zurück in die Quelldatenbank, sondern nur in den Online-Speicher.

Datenschema und Zweck des operationalen Karten-Layers

Ziehen Sie beim Entwerfen eines Schemas für operationale Karten-Layer den Zweck der einzelnen Karten-Layer in Betracht und beachten Sie die Schemaanforderungen eines Layers. Darüber hinaus müssen Sie die Eigenschaften der Felder von Karten-Layern berücksichtigen.

Datenschemaanforderungen für die Zwecke von operationalen Layern

Die Zwecke, die für einen operationalen Layer festgelegt werden können, werden in der folgenden Liste beschrieben: Ein Karten-Layer kann nur für einen der folgenden Zwecke verwendet werden:

• Auswählen von Daten –Für Mobile-Services hat der jeweilige Typ des Daten-Repository möglicherweise Auswirkungen auf die Art der Datenerfassung durch Ihren Außendienst. Stammen Ihre Daten aus einer File-Geodatabase, sind sie nach dem Hosten auf einem ArcGIS-Server schreibgeschützt, selbst wenn Sie eine GlobalID hinzugefügt haben. In diesem Fall können Sie immer noch das Werkzeug Mobile-Cache erstellen verwenden, um einen Mobile-Cache zu erstellen, den Sie zu Ihrem Projekt zwecks Datenerfassung hinzufügen können. Wenn die Daten jedoch aus einer ArcSDE-Datenbank stammen und vor dem Veröffentlichen nicht beim Server registriert werden, sind sie ebenfalls schreibgeschützt. Diese Einschränkungen gelten jedoch nicht für Feature-Services, d. h. die Daten können auch dann weiterhin bearbeitet werden, wenn sie keine GlobalID aufweisen oder in einer File-Geodatabase gespeichert sind.
• Bereitstellung schreibgeschützter Referenzinformationen – Für das Schema eines schreibgeschützten Layers besteht keine Einschränkung.
• Identifizieren des aktuellen Benutzers – Ein Identitäts-Layer muss ein Punkt-Layer mit zwei Feldern sein: ein Feld zum Speichern der Benutzeridentität und ein Feld zum Speichern des Anzeigenamens des Benutzers. Wenn der Layer nicht von Außendienstmitarbeitern bearbeitet werden soll, ist keine GlobalID erforderlich. Soll der Layer bearbeitet werden, können Sie ihn als Mobile-Service auf einem ArcGIS-Server oder als Feature-Service auf ArcGIS Online für Organisationen bzw. Portal for ArcGIS hosten oder ihn mithilfe des Werkzeugs Mobile-Cache erstellen cachen.
• Protokollierungs-Layer – Ein Protokollierungs-Layer muss ein bearbeitbarer Punkt-Layer sein, der ein Datums-/Zeitfeld und ein Textfeld für den Computernamen aufweist (oder Identitätsinformationen, falls Sie über einen Identitäts-Layer verfügen). Sie können den Layer sowohl als Mobile-Service auf einem ArcGIS-Server als auch als Feature-Service auf ArcGIS Online für Organisationen bzw. Portal for ArcGIS hosten oder ihn mithilfe des Werkzeugs Mobile-Cache erstellen cachen.
• Außendienstteam-Layer – Ähnlich wie bei einem Protokollierungs-Layer muss ein Außendienstteam-Layer ein bearbeitbarer Punkt-Layer sein, der ein Datums-/Zeitfeld und ein Textfeld für den Computernamen oder für Identitätsinformationen aufweisen. Da der Layer alle letzten bekannten Positionen von Außendienstmitarbeitern synchronisiert und aktualisiert, muss er aus einem Mobile-/Feature-Service und nicht aus einem lokalen Mobile-Cache stammen.
• Für Benutzer unsichtbar – Für das Schema eines ausgeblendeten Layers besteht keine Einschränkung.

Weitere Informationen zum Zweck eines Layers finden Sie unter Eigenschaften von operationalen Layern.

Karten-Layer-Felder und Feldeigenschaften

Folgendes Geodatabase-Verhalten wird in ArcGIS for Windows Mobile-Anwendungen unterstützt:

• Subtypes – Dienen zum Klassifizieren von Features, die in einer einzelnen Feature-Class gespeichert sind. Beispielsweise lassen sich Baum-Features nach Baumtyp klassifizieren. Wenn Sie im Außendienst ein neues Baum-Feature erstellen, kann der Außendienstmitarbeiter den Typ des zu erstellenden Baums auswählen, wodurch die Eingabe des Typs als getrenntes Attribut vermieden wird.
• Domänen – Sowohl Domänen mit codierten Werten als auch Bereichsdomänen werden unterstützt. Jede Domäne mit codierten Werten wird beim Erfassen oder Aktualisieren von Attributwerten als Auswahlliste angezeigt. Bereichsdomänen geben den Bereich der gültigen Werte an, die für ein numerisches und/oder Datums-Attribut eingegeben werden können.
• Standardwerte – Ist einem Attributfeld ein Standardwert zugewiesen, wird das Feld von den Außendienstanwendungen automatisch mit dem Standardwert ausgefüllt. Beispielsweise kann das Höhenattributfeld für einen Baum auf den Wert 10 festgelegt sein. Dem Höhenwert für alle neuen Baum-Features wird automatisch der Wert "10" zugewiesen. Wenn die Baumhöhe unter- oder oberhalb des Wertes "10" liegt, kann Ihr Außendienstteam das Höhenfeld aktualisieren. Jedes Attributfeld einer Feature-Class kann einem Standardwert zugewiesen werden.
• Anlagen – Mit der Aktivierung einer Feature-Class zur Speicherung von Anlagen können Informationen verwaltet werden, die mit Features in Beziehung stehen. Anlagen müssen den Feature-Classes der Geodatabase hinzugefügt werden, bevor sie vor Ort verwendet werden können. Anlagen werden häufig zum Speichern digitaler Fotos eines Features verwendet. Sie können mehrere Anlagen für ein Feature erfassen und anzeigen.
• Raster/BLOB – (wird von gehostetem Feature-Service nicht unterstützt) – Felder vom Typ "Raster/BLOB" werden als spezieller Feldtyp erkannt, der zum Speichern von Fotos verwendet werden kann. Sie können nach Fotos suchen und sie dem Raster-Feld hinzufügen, oder Sie können die in Ihrem mobilen Gerät integrierte Kamera direkt verwenden. Beachten Sie, dass für jedes Feature nur ein Bild pro Raster-/BLOB-Feld vorhanden sein darf.
  Achtung:

  Wenn Sie Bilder mit einem BLOB-Feld speichern möchten, sollten Sie "esri_picture" oder "picture_" dem Feldnamen als Präfix voranstellen. "esri_picture" and "picture_WaterValve" werden beispielsweise akzeptiert.

• Datumsangaben – Attributfelder können Datumswerte speichern. Ihr Außendienstteam kann das aktuelle Datums-/Zeitfeld durch Auswahl aus dem eingeblendeten Kalender eingeben.
• Telefonnummern – Wenn Sie ein Textfeld zum Speichern von Telefonnummern verwenden und die Telefonnummer im Format (XXX)XXX-XXXX eingeben, damit sie von einem Windows Mobile-Gerät mit eingebettetem Chip für Mobilfunk erkannt wird, können Sie das Telefon einschalten und die Nummer direkt über die ArcGIS-Anwendung anwählen.

Hinweis:

Feature-Classes, die Z- oder M-Werte unterstützen, können bearbeitet werden, allerdings werden Z- und M-Werte nicht beibehalten. Für neu erfasste Features werden keine Z- und M-Werte festgelegt.

ArcGIS for Windows Mobile unterstützt auf mobilen Geräten weder das Erstellen neuer Karten-Layer noch das Ändern des Schemas von Attributfeldern. Falls möglicherweise Features erfasst werden sollen, die im aktuellen Datenmodell nicht vorhanden sind, oder unstrukturierte Informationen wie beispielsweise Notizen vor Ort hinzugefügt werden, sollten Sie eine zusätzliche Feature-Class im Geodatabase-Schema erstellen, die diese Informationen aufnehmen kann.

Überlegungen zum Geodatabase-Entwurf

Hinweis:

Wenn Sie Ihre Karte als Feature-Service veröffentlichen möchten, überspringen Sie den Rest dieses Abschnitts.

Wenn Sie über eine vorhandene Mehrbenutzer-Geodatabase verfügen, die Sie für ein Außendienstprojekt verwenden möchten, führen Sie einen der folgenden Schritte aus:

• Nutzung der vorhandenen Struktur durch Verwendung der Geodatabase-Replikation.
• Transformieren der Geodatabase mithilfe eines ETL-Prozesses (Extrahieren, Transformieren, Laden).

In den folgenden Abschnitten werden die Geodatabase-Replikation und ETL-Modelle für die Verwaltung von mobilen Bearbeitungsanwendungen mithilfe von vorhandenen Geodatabases beschrieben.

Geodatabase-Replikationsmodell

Sie können einfach den Inhalt Ihrer Mehrbenutzer-Geodatabase zur mobilen Verwendung veröffentlichen und dann die mobil erfolgten von den im Büro vorgenommenen Änderungen mittels Versionierung trennen. Es gibt jedoch eine Reihe von potenziellen Problemen bei dieser Vorgehensweise. Wenn Sie beispielsweise Aktualisierungen vom mobilen Gerät synchronisieren müssen, ist der Zugriff von außerhalb der Unternehmens-Firewall auf die Produktions-Geodatabase erforderlich. 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 Änderungen gespeichert werden und die regelmäßig Aktualisierungen mit der Parent-Geodatabase synchronisiert. Bei dieser Vorgehensweise müssen Sie nur die Informationen replizieren, die Sie vor Ort benötigen (nicht die gesamte Geodatabase), 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 nicht mit der Hauptniederlassung verbunden sind; 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 können Metadaten für alle mobilen Bearbeitungsaufgaben gespeichert werden, die nicht in die Enterprise-Geodatabase gehören (z. B. GPS-Messdaten (Global Positioning System) für die differenzielle Korrektur der erfassten Daten).

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 sind 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 vollständigen Straßennamens. Wenn Sie den Straßennamen auf einem mobilen Gerät anzeigen möchten, fassen Sie diese Attribute in einem Feld zusammen, das Sie für die Beschriftung verwenden können.

Geoverarbeitungsmodelle können verwendet werden, 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. Definieren Sie einen Satz Geoverarbeitungsmodelle oder benutzerdefinierte räumliche ETL-Werkzeuge, 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

Die Planung der Verwaltung Ihrer Änderungen im Außendienst und deren Integration in die Geodatabase ist in Ihrem Transaktionsmodell enthalten. Teilweise wird dies durch die von Ihnen getroffenen Entscheidungen für die Geodatabase definiert, teilweise aber auch durch die Anzahl der zu unterstützenden mobilen Bearbeiter und die gewünschte Isolation der Änderungen.

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

• Soll die Standardversion der Geodatabase mit vor Ort durchgeführten Änderungen aktualisiert werden? Falls nicht, soll eine Version für alle vor Ort durchgeführten Änderungen gelten oder soll es für jeden Bearbeiter vor Ort eine separate Version geben?
• Können Sie die Geodatabase ohne Versionierung aktualisieren?
• Müssen die im Außendienst vorgenommenen Änderungen archiviert werden?
• Wie werden Konflikte zwischen Datenaktualisierungen im Außendienst behandelt?

In den folgenden Abschnitten werden 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 über wenige Außendienstmitarbeiter verfügen, die einfache Bearbeitungsaufgaben wie die Aktualisierung von Attributen durchführen, und kaum die Gefahr besteht, dass sie dasselbe Feature vor Ort 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 Service veröffentlichen. Sobald die Bearbeiter die Datenerfassung oder -pflege abgeschlossen haben und ihre Änderungen mit der Geodatabase synchronisiert haben, wird ArcGIS for Desktop benötigt, um die Versionsbearbeitungen im Büro mit der Parent-Version zu abzugleichen.

ArcGIS for Windows Mobile Client-Bearbeitungsumgebung

ArcGIS for Windows Mobile-Anwendungen haben kein Konzept zum Starten, Beenden und Speichern von Änderungen wie andere ArcGIS-Anwendungen. Jede vorgenommene Änderung wird so lange im mobilen Cache 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 – Sie können jedoch nicht lediglich eine einzelne Feature-Bearbeitung rückgängig 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, da die Außendienstmitarbeiter möglicherweise nicht permanent mit dem Internet verbunden sind oder ihre Geräte heruntergefahren und aufgeladen werden müssen. Sobald die Verbindung mit dem Server hergestellt ist, können die im Cache gespeicherten Aktualisierungen mit der Back-End-Datenbank synchronisiert werden.

Wenn Änderungen vom mobilen Gerät übermittelt werden, werden nur Änderungen, sogenannte "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.

Je nach Anzahl der erwarteten Änderungen und Art der Datenverbindung (GPRS, General Packet Radio Service) 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.