Verwalten von Höhendaten, Teil 2: Entwurfs- und Datenmanagementplan

Die Zielgruppe für diesen Workflow besteht hauptsächlich aus den Bilddatenmanagern von Organisationen, die für eine Reihe von Anwender-Communitys Höhendaten verfügbar machen müssen. Bei diesem Workflow wird davon ausgegangen, dass der Bilddatenmanager die Daten in ArcGIS Desktop verwaltet und mit ArcGIS Server in Form eines oder mehrerer Image-Services verteilt. Dieser Workflow gilt jedoch auch für die Verwaltung und Verteilung von Höhendaten, wenn nur ArcGIS Desktop verwendet wird.

Dieser Workflow bezieht sich auf zellenbasierte Raster-Höhendaten. 3D-Punktdaten (z. B. LAS) und Terrain-Dataset-Formate müssen zur Verwendung in diesem Workflow in Raster-Datasets konvertiert werden.

Im Folgenden wird die allgemeine Struktur der Verwaltung von Höhendaten aufgeführt. Die einzelnen Punkte werden weiter unten besprochen.

1. Datenspeicherung (Größe, Anforderungen und Speicherorte)
2. Vorbereiten von Daten (kann eine Vorverarbeitung erfordern)
3. Erstellen eines Mosaik-Datasets für jede Sammlung (Quelle)
4. Erstellen eines Mosaik-Datasets aus jeder Sammlung (Master)
5. Erstellen unterschiedlicher Mosaik-Datasets für Visualisierung, Analyse, Benutzerzugriff und Veröffentlichung (referenziert)

Datenspeicherung

Die Datenspeicherung wird an dieser Stelle nicht besprochen, erfordert jedoch je nach Anforderungen etwas Planung. Wenn Sie zu einigen Besonderheiten Ihrer Systemarchitektur Informationen benötigen, finden Sie diese auf den Folien der Präsentation von der Internationalen Esri Benutzerkonferenz 2011: System Architecture for Large Image Services.

Wichtig ist jedoch die Datenorganisation. Im Idealfall können Sie die Daten in Ordnern organisieren, die nach Produkten gruppiert sind. Speichern Sie beispielsweise die SRTM-Daten in einem Ordner und die NED-Daten mit einer Auflösung von 1/3 Bogensekunde in einem anderen. In den Schritten (Teil 3) können Sie sehen, wie dies das Laden der Daten in QA/QK und die längerfristige Verwaltung erleichtert.

Datenverwendung

Dieser Workflow konzentriert sich auf drei unterschiedliche Modi für die Verwendung von Höhendaten. Die meisten Endbenutzer müssen lediglich Visualisierungen der Topografie anzeigen können, während ein kleinerer Teil der Benutzer die Ergebnisse einer topografischen Analyse anzeigen möchte. Der kleinste Teil der Benutzer, z. B. Ingenieure, müssen auf die eigentlichen Höhenwerte zugreifen, um eigene Analysen durchzuführen.

Dabei ist es wichtig, die Unterschiede zu verstehen und den richtigen Verwendungsmodus für die verschiedenen Benutzer zu implementieren, da dieser beträchtliche Auswirkungen auf die Systemeffizienz und die Reaktionszeiten haben kann. Die unterschiedlichen Verwendungsmodelle, auf die wiederholt Bezug genommen wird, sind die jeweiligen Verwendungen von Viewer, Analyseergebnissen und Datenwerten.

Verwendungsmodell 1: Verwendung des Viewers

Benutzer müssen Repräsentationen der Höhendaten anzeigen können. Deshalb muss der Datenmanager entsprechende Visualisierungsprodukte auf dem Server erstellen und diese Ansichten für die Benutzer verfügbar machen. Dies bezieht sich auf die größte, technisch jedoch am wenigsten anspruchsvolle Benutzergruppe, die einen problemlosen Zugriff auf eine beliebige Anzahl relativ einfacher, höhendatenbasierter Produkte benötigt. In vielen Fällen handelt es sich dabei um die Öffentlichkeit. Beispiele:

• Geschummertes Relief-Bild: zum Einfügen in eine topografische Karte oder Grundkarte
• Bildliche Darstellung einer Neigung: für Zwecke der Stadtplanung, Anfälligkeitsanalysen für Erdrutsche usw.
• Bildliche Darstellung der Ausrichtung: für Zwecke der Landwirtschaft, der Begrenzung und Verwaltung von Lebensräumen für Wildtiere, der Klimamodellierung usw.

Für Benutzer mit ArcGIS können diese Produkte dank des Zugriffs auf die Höhendaten natürlich von der Anwendung selbst generiert werden.

Verwendungsmodell 2: Verwendung von Analyseergebnissen

Benutzer definieren Parameter und einen relevanten Bereich für die serverseitige Analyse von Höhendaten und rufen dann die Ergebnisse ab. Dies bezieht sich auf eine Gruppe von Benutzern, die Zugriff auf eine Anzahl von Analyseprodukten benötigen. Diese können auf dem Server generiert werden. Die Ergebnisse sind meist Karten oder diskrete Features, die für die Benutzer bereitgestellt werden, ohne dass die ursprünglichen Quelldaten übertragen werden. Beispiele:

• Berechnung und Erstellung von Karten für Überschwemmungsgebiete: FEMA, Versicherungsfirmen, kommunale oder regionale Behörden, Immobilien und öffentliche Verwendung
• Anwendungen im Katastrophenmanagement: Evakuierungsplanung, Überschwemmungsschutz und webbasiertes Overlay aktueller Überschwemmungsdaten für Echtzeit-Entscheidungsprozesse
• Sichtfeldberechnungen für Sichtbarkeits- und Sichtlinienanalysen: Bestimmung der Objekte, die von einem Standpunkt aus gesehen werden können, Platzierung von Mobilfunkantennen und Mikrowellen-Kommunikationsgeräten oder Planung von Kahlhieben
• Militäroperationen: geschützte Truppenrouten, die vor Heckenschützen sicher sind
• Industrielle Planungen: Windprofile und Sichtbarkeit von Windparkstandorten oder Bau von Dämmen für Wasserkraftwerke
• Berechnung kartografischer Konturlinien: Anzeige auf Karten
• Berechnung von Profilen entlang gerader Linien oder Liniensegmente: Erarbeitung von Pipelineführungen und Druckberechnungen, Straßenplanung oder Einschläge für die Straßenplanung und Kosten für den Abtransport

Bei diesen Anwendungen benötigen die Benutzer im Allgemeinen nicht die eigentlichen Höhenwerte. Wenn diese Produkte lediglich verteilt werden, können die Bandbreitenanforderungen aufgrund der geringeren Datengröße leicht reduziert werden. Die unverarbeiteten Höhenwerte etwa sind 32-Bit-Ergebnisse, während ein Sichtfeld ein 1-Bit- oder 8-Bit-Ergebnis sein kann.

Verwendungsmodell 3: Verwendung von Datenwerten

Benutzer benötigen Zugriff auf die Höhenwerte. Dies bezieht sich auf Benutzer, die die Original-Höhendaten in digitalem Format benötigen, damit numerische Berechnungen unterstützt werden (oft in clientseitigen Web- oder Desktopanwendungen). Beispiel:

• Als Eingabe in einem sekundären Prozess: zur Orthokorrektur von Bildern
• Als Eingabe in eigenen Datenmodellen oder Prozessen: zum Erstellen von Konturlinien oder zum Durchführen von Wasserlaufanalysen für die hydrografiegestützte Erstellung von Bewässerungssystemen oder Überschwemmungsmodellen

Von den drei Verwendungsmodellen ist dieses das zeit- und serverressourcenintensivste, da häufig wesentlich größere Datenmengen verwendet und übertragen werden müssen.

Anforderungen

Zur Bereitstellung der richtigen Daten und des Zugriffs, um den oben genannten Verwendungsmodellen zu entsprechen. Dies ist nicht als vollständige Auflistung der Anforderungen gedacht, sondern lediglich als Einführung in einige wichtige Anforderungen für Höhendaten zu verstehen. Sie müssen dann entscheiden, ob diese Anforderungen auf Ihre Organisation zutreffen, und die entsprechenden Entscheidungen für eine ordnungsgemäße Implementierung treffen.

• Verteilen eines Bildes, eines Ergebnisses oder der Daten
• Interner Zugriff oder Zugriff über das Intranet oder Internet
• Bereitstellen eines oder mehrerer Höhenmodelle oder Repräsentationen
• Zugriff für 1, 10, 100 oder 1 Million Benutzer
• Bereitstellen des Zugriffs auf die Quelldaten
• Viele Datenquellen, die als eine verwaltet werden
• Eingeschränkter Zugriff auf Quelle und Verwaltung
• Inhalte müssen leicht aktualisiert oder ersetzt werden können

Datendownload und -export

Bilddatenmanager und Endbenutzer müssen sich bewusst sein, dass die Daten bei jeder Stichprobennahme von Höhendaten geändert werden. Wenn beispielsweise ein Dataset nicht in der vollen Auflösung oder in einer anderen Projektion oder Pixelausrichtung angezeigt wird, erfolgt ein Resampling der Daten. Es ist nicht ungewöhnlich, dass ein Höhen-Dataset zu viele Details enthält. Dies ist beispielsweise der Fall, wenn ein von einem Dataset mit 5-Meter-Punktabstand erstelltes Sichtfeld auf einen Maßstab von 1:1.000 vergrößert wird – dies ist viel zu nah.

Bei einigen Anwendungen müssen die Benutzer möglicherweise auf die Zahlenwerte in einem relevanten Bereich zugreifen (Verwendung der Datenwerte). Zum Bereitstellen numerischer Datenwerte für einen Client sind zwei Methoden verfügbar: Export oder Download.

Der Begriff Export bezeichnet die Übertragung von Datenwerten in einer vom Benutzer definierten Fläche, für die ein Resampling auf die richtige Auflösung oder Projektion durchgeführt wird. Der Begriff Download (Herunterladen) bezeichnet die Übertragung der Original-Datenwerte (volle Auflösung, kein Resampling), meist innerhalb einer angegebenen Fläche. Es wird deutlich, dass bei einem Download eine sehr große Datenmenge vom Server auf den Client übertragen werden kann (insbesondere, wenn die Daten eine große Fläche abdecken und eine hohe Anzahl von Datasets umfassen). Daher müssen entsprechende Einschränkungen implementiert werden, um sicherzustellen, dass der Benutzer und das System auf das Ergebnis vorbereitet sind, etwa durch Festlegen einer maximalen Datenmenge bei der Übertragung oder den Entwurf einer Webanwendung mit einer Warnung.

Datenquellen

Im Folgenden finden Sie eine Liste der Beispieldaten, die in diesem Workflow verwendet werden. Diese Daten können unterschiedliche Bit-Tiefen aufweisen, meist 16 Bit oder Gleitkomma, mit oder ohne Vorzeichen.

Bei diesem Workflow wird davon ausgegangen, dass der Datenmanager interne, lokal gespeicherte Daten verwendet.

Daten	Description
GTOPO	GTOPO ist ein globales Höhen-Dataset mit einer Auflösung von 30 Bogensekunden (etwa 1 km), das unter http://www1.gsi.go.jp/geowww/globalmap-gsi/gtopo30/gtopo30.html zum Download bereitsteht.
SRTM	Die Shuttle Radar Topography Mission (SRTM) liefert von einem Space Shuttle erfasste Höhendaten in beinahe globalem Maßstab und erstellt daraus die umfassendste hochauflösende digitale Topografiedatenbank zur Erde. Sie ist unter http://srtm.usgs.gov/index.php verfügbar.
NED 10, NED 30	Das National Elevation Dataset (NED) wurde vom USGS für die USA entwickelt. NED-Daten stehen in den USA in Auflösungen von 1 Bogensekunde (etwa 30 Meter, "NED 30") und 1/3 Bogensekunde (etwa 10 Meter, "NED 10") zur Verfügung. Siehe http://ned.usgs.gov/.
LIDAR	Die LIDAR-Daten können aus unterschiedlichen Quellen stammen. In diesem speziellen Fall stammen die Daten aus dem Oregon Metro Regional Land Information System (RLIS) und wurden in ein DEM und ein DSM konvertiert.

Datenmanagement-Organisation und -Services (Produkte)

Ein Hauptziel besteht darin sicherzustellen, dass alle Daten unabhängig von ihrem jeweiligen Umfang als Einheit verwaltet und verteilt werden. Als Alternative (die sich häufig im Laufe der Zeit ergibt, wenn eine Organisation wächst und einzelne Projekte abgeschlossen werden) können Daten aus unterschiedlichen geographischen Gebieten als separate Datasets verwaltet werden. ArcGIS bietet jedoch die Möglichkeit, sehr große Dataset-Sammlungen effizient zu verwalten, wodurch die zuvor durch Datenduplizierung und unnötigen Verwaltungsaufwand entstandenen Erstellungs- und Wartungskosten gesenkt werden.

Organisation von Mosaik-Datasets

Das Mosaik-Dataset ist die optimale Datenstruktur zum Verwalten, Anzeigen und Veröffentlichen von Höhendatensammlungen, da damit alle unterschiedlichen Raster-Dateiformate und -Auflösungen verwaltet werden können und die Dateien auf dem Datenträger in ihrem ursprünglichen Format vorliegen. Außerdem sind so zahlreiche Optionen zum Anzeigen und Verarbeiten von Höhendaten verfügbar, z. B. dynamisches Mosaikieren, das die beste Auflösung für die Anzeige bei geeigneten Maßstäben zulässt, sowie Datenverarbeitungsfunktionen zum Erstellen mehrerer Produkte, ohne die Quelldaten kopieren zu müssen.

Zu den spezifischen Funktionen für Höhendaten zählen "Schummerung", "Geschummertes Relief", "Ausrichtung" und "Neigung".

Es empfiehlt sich, Mosaik-Datasets in zwei Typen einzuteilen: Datasets, die hauptsächlich für die Verwaltung verwendet werden, und Datasets, die andere Datenrepräsentationen (z. B. Schummerungen) bereitstellen und veröffentlicht werden. Diese Trennung kann die Organisation unterstützen. Sie können die Bilddaten innerhalb eines Mosaik-Datasets verwalten, jedoch ein anderes Mosaik-Dataset verwenden, um den Inhalt freizugeben oder zu verbreiten (zu veröffentlichen).

Im Folgenden finden Sie eine Übersicht über die unterschiedlichen Mosaik-Dataset-Typen und ihre möglichen Verwendungszwecke:

• Quelle: Wird zum Verwalten der Bilddaten verwendet. Enthält im Allgemeinen eine Sammlung ähnlicher Bilddaten. Sie können mehrere dieser Quell-Mosaik-Datasets verwenden, um verschiedene Sammlungen zu verwalten, z. B. SRTM und NED. Diese können direkt veröffentlicht oder (meist) als Quelle für andere Mosaik-Datasets verwendet werden.
• Master (oder abgeleitet): Wird verwendet, um mehrere Quellen als einzelnes Mosaik-Dataset zu kompilieren. Die Quelle eines Master-Mosaik-Datasets besteht im Allgemeinen aus mindestens einem Quell-Mosaik-Dataset, sie kann jedoch auch andere Bilder oder Services umfassen.
• Referenziert: Ein bestimmter Mosaik-Dataset-Typ, der hauptsächlich zum Freigeben oder Veröffentlichen von Bildern verwendet wird. Er wird mit einem Mosaik-Dataset als Eingabe erstellt und erlaubt keine Bearbeitung der Elemente in der Tabelle. Daher sind die Eingaben vor Änderungen geschützt. Dieser Typ wird häufig verwendet, um unterschiedlich verarbeitete Ausgaben der Quell- oder Master-Mosaik-Dataset-Eingaben bereitzustellen.

Quell- und (abgeleitete) Master-Mosaik-Datasets sind symbolische Namen, mit denen die Organisationsstruktur der Mosaik-Datasets wiedergegeben wird. Ein Referenz-Mosaik-Dataset bildet dagegen eine Mosaik-Dataset-Form, die sich physisch unterscheidet.

Die Höhendaten können in Ordnern gespeichert werden, die von Ihnen selbst oder vom Datenanbieter organisiert werden, sie alle werden jedoch mit einem oder mehreren Mosaik-Datasets und Image-Services verwaltet und verteilt. Die Daten in einem Quell-Mosaik-Dataset werden meist über die gleiche Anzahl von Bändern und gleiche Bit-Tiefen bestimmt. In diesem Fall werden sie anhand der Bit-Tiefe und des Produkts bestimmt. Beispielsweise können die von LIDAR abgeleiteten Daten in einem Quell-Mosaik-Dataset und die SRTM-Daten in einem anderen organisiert werden. Dies trägt zur Organisation der Daten bei und ermöglicht die Trennung von Daten mit unterschiedlichen vertikalen Einheiten. Beispielsweise werden die von LIDAR abgeleiteten Daten in Fuß und die SRTM-Daten in Meter gemessen. Damit können Sie bei Bedarf auch die Footprints verfeinern oder die NoData-Werte steuern, die sich zwischen den einzelnen Produkten unterscheiden können.

Die Quell-Mosaik-Datasets werden mithilfe des Master-Mosaik-Datasets kombiniert. Manchen Quellen können Funktionen hinzugefügt werden, um sicherzustellen, dass die Daten die gleichen Informationen repräsentieren, z. B. die Konvertierung von Fuß in Meter oder von Ellipsoid-Daten in orthometrische Daten. (Unter den meisten Bedingungen wird empfohlen, ein Mosaik-Dataset mit orthometrischer Bodenhöhe als Master-Service zu erstellen und zu verwalten und als Grundlage für weitere Mosaik-Datasets zu verwenden.)

Endprodukte und Services

Aus dem Master-Mosaik-Dataset können verschiedene referenzierte Mosaik-Datasets erstellt werden, um die folgenden empfohlenen Höhendaten-Services bereitzustellen:

• Orthometrische Bodenhöhe
• Orthometrische Oberflächenhöhe: wenn Oberflächenhöhendaten (DSM) verfügbar sind (d. h., Gebäude, Baumkronen, Brücken usw. angezeigt werden)
• Ellipsoid-Bodenhöhe
• Für Visualisierungen
  • Schummerung
  • Geschummertes Relief
  • Slope
  • Ausrichtung (wird für Visualisierungen und Analysen verwendet)

Wenn von der Anwender-Community mehr als eine Geoid-Korrektur benötigt wird, kann der Datenmanager Geoids als Image-Services veröffentlichen und den Benutzern auf diese Weise entsprechende Optionen zur Verfügung stellen.

Überlegungen zu Ozeanen

In allen Fällen muss der Datenmanager entscheiden, wie Ozeane dargestellt werden. Die richtige Wahl hängt von den Anwendungen ab, die die Daten unterstützen müssen. Folgende Optionen sind verfügbar:

• Ozeane sind Höhen mit dem Wert 0
• Ozeane sind NoData-Werte
• Ozeane werden mit bathymetrischen Daten dargestellt

Bei den meisten Anwendungen können sämtliche Meeresspiegelhöhen mit 0 dargestellt werden. Wenn das Meer als NoData definiert ist, gelingt die Orthokorrektur in allen NoData-Flächen nicht. Eine einfache Methode, Flächen mit dem Wert 0 aufzufüllen, besteht darin, dem Mosaik-Dataset ein weltweites Dummy-Bild mit sehr geringer Auflösung hinzuzufügen, in dem alle Pixelwerte 0 sind. Wenn die Werte in den Daten (z. B. SRTM) NoData sind, wird daraufhin der Wert 0 im Dummy-Bild angezeigt.

Wenn der Datenmanager beschließt, bathymetrische Daten einzufügen, weisen die Ozeane negative Höhenwerte auf, und der Meeresboden wird visualisiert. Dies ermöglicht Flexibilität hinsichtlich des Rendering (der Anzeige) der Daten in verschiedenen Services. In einer Client-Anwendung kann für Wasser eine blaue Füllung angezeigt werden, wenn die Höhe geringer als 0 ist, während in einer anderen Client-Anwendung die Höhe unterhalb des Meeresspiegels in der gleichen Fläche als geschummertes Terrain gerendert wird.

Übersichten

Im Grunde sind Übersichten von Mosaik-Datasets mit Raster-Dataset-Pyramiden vergleichbar. Es handelt sich um Bilder mit einer geringeren Auflösung. So soll die Anzeigegeschwindigkeit beschleunigt und die Auslastung der CPU verringert werden, da weniger Raster untersucht werden, um das mosaikierte Bild anzuzeigen. Es gibt jedoch insofern einen großen Unterschied, da viele der Parameter, mit denen sie erstellt werden, beeinflusst werden können. Die Übersichten können zur Abdeckung nur bestimmter Bereiche oder für bestimmte Auflösungen erstellt werden. Mit ihnen lassen sich alle im Mosaik-Dataset enthaltenen Raster anzeigen und nicht nur die einzelnen Raster. Übersichten beginnen üblicherweise da, wo Rasterpyramiden aufhören. Wenn Sie nicht alle Pyramiden eines Rasters verwenden möchten, können Sie auch eine Basispixelgröße angeben, ab der Übersichten generiert werden sollen.

Der Datenmanager sollte die beste Vorgehensweise für Übersichten ermitteln. Übersichten können aus den Projektdaten erstellt werden. Wenn jedoch geeignete Datasets mit niedrigerer Auflösung aus alternativen Quellen verfügbar sind, z. B. GTOPO, ETOPO oder GMTED2010, wird deren Verwendung empfohlen. Der verbleibende Teil dieses Workflows beruht auf dieser Vorgehensweise, um einen aus mehreren Datasets bestehenden Image-Service mit unterschiedlichen räumlichen Auflösungen für eine große Region zu erstellen (sodass meist keine Übersichten benötigt werden).

Weitere Informationen zu Übersichten finden Sie unter Übersichten über Mosaik-Datasets.

Metadaten

Zahlreiche Eigenschaften sollten vom Datenmanager hinsichtlich aller Höhendaten überprüft werden. Der Datenmanager muss prüfen und entscheiden, welche Komponenten wichtig sind und welche Metadatenfelder für die Datenbenutzer verfügbar gemacht werden sollen. Die unten angegebenen Metadaten werden für die Zwecke der Qualitätssicherung und Systemkonfiguration empfohlen.

Der Datenmanager sollte u. a. die folgenden Metadaten überprüfen:

• Datenquelle oder -eigentümer
• Copyright
• Horizontales Koordinatensystem (Projektion, Datum und Einheiten)
• Vertikales Datum (spezifisches Modell, ellipsoidförmig oder orthometrisch) und Einheiten (Fuß oder Meter)
• Horizontale Genauigkeit (meist als CE90 oder CE95 gemessen, kann aber auch als RMS-Fehler oder RMSE angegeben werden)
• Vertikale Genauigkeit (meist als LE90 gemessen)
• Auflösung (in der Datendatei gespeicherte Stichprobenabstände, nicht identisch mit der horizontalen Genauigkeit der Daten)
• Höhenoberflächentyp (DEM oder DSM)
• Definition von NoData-Werten in diesem Dataset:
  • Gibt es Flächen mit NoData-Werten?
  • Wenn ja, werden diese durch einem einzigen Wert dargestellt?
  • Sind die NoData-Werte auf die Kanten der Datasets beschränkt, oder gibt es Löcher von NoData-Werten innerhalb der gültigen Daten?
  • Manche Produkte weisen zugehörige Feature-Classes auf, in denen leere Regionen definiert sind. Untersuchen Sie, ob diese Flächen mit einem Wert aufgefüllt wurden und ob dieser dem NoData-Wert entspricht.
• Wurden die Daten einer anderen Quelle entnommen?
• Erfassungsdatum der unverarbeiteten Daten
• QA/QK-Abschluss: Datum, ausführende Person, Methoden und/oder Standards
• Können die Daten freigegeben werden oder sind sie vertraulich (Daten können proprietär oder klassifiziert, frei für öffentliche Freigabe sein)?

Bei eindeutigen Metadatenfeldern müssen sie der Attributtabelle des Mosaik-Datasets möglicherweise manuell hinzugefügt werden, z. B. die horizontalen und vertikalen Genauigkeiten. Auf diese Weise können Benutzer problemlos das Mosaik-Dataset nach diesen Informationen abfragen.

Tipp:

Es empfiehlt sich, für die zu verwendenden Produkte (oder Unterprodukte) eine Liste zu erstellen, da Sie die Daten im Mosaik-Dataset möglicherweise ändern müssen, um etwa mit der Funktion "Arithmetisch" eine Konvertierung aus einer Einheit in eine andere vorzunehmen.

Formatoptimierung

Formatoptimierungen sind nicht immer erforderlich. Dies ist jedoch der Fall, wenn die Daten in einem Format vorliegen, das nicht optimal oder gut unterstützt wird. Im Folgenden werden einige Empfehlungen aufgeführt, mit denen Sie die Vorverarbeitung von Höhendaten beim Erstellen einer einzelnen Sammlung und Veröffentlichen als Service unterstützen.

• Konvertierung von Punkt- oder TIN-Daten in ein Raster-Format. Je nach Quelle können Sie zwischen mehreren Geoverarbeitungswerkzeugen wählen. Informationen dazu finden Sie unter Toolset 'In Raster' oder 3D Analyst-Toolset 'Konvertierung'.
• Informationen zur Konvertierung von LIDAR-Daten in Höhenflächen in ArcGIS 10.0 erhalten Sie im Blog Lidar Solutions in ArcGIS part2: Creating raster DEMs and DSMs from large lidar point collections.
  Hinweis:

  In ArcGIS 10.1 müssen LAS-Dateien und Terrain-Datasets nicht in Raster-Datasets konvertiert werden. Sie werden direkt im Mosaik-Dataset unterstützt.

• Das optimale Format für Höhendaten sind in einem gekachelten TIFF-Format gespeicherte 32-Bit-Gleitkommawerte mit LZW-Komprimierung. Die LZW-Komprimierung erfolgt verlustfrei und schnell, die Daten in einer Datei werden automatisch gekachelt. Zudem belegen NoData-Werte im Raster-Format keinen Speicherplatz.
• Esri empfiehlt allgemein, Höhendaten nur aus dem ursprünglichen Format zu konvertieren, wenn das Dateiformat ineffizient ist und sich dies negativ auf die Serverleistung auswirkt. Wenn beispielsweise eine der folgenden Bedingungen zutrifft, sollten die Daten vor dem Hinzufügen zum Mosaik-Dataset konvertiert werden:
  • Die Höhendaten sind in einem ineffizienten Dateiformat gespeichert, z. B. ASCII XYZ (ineffizient zu lesen)
  • Die Höhendatendateien sind groß (Anzahl der Spalten oder Zeilen über 5000), die Daten sind nicht gekachelt oder weisen keine Pyramiden auf, die Serverleistung ist wichtig

In einigen Fällen sollten Sie vor dem Konvertieren der Daten eine Leistungsprüfung durchführen, um zu ermitteln, ob die Daten geeignet sind oder durch eine Konvertierung optimiert werden können. Beispiele:

• Wenn das Original als JPEG 2000 gespeichert ist, sollten Sie sich bewusst sein, dass zur Dekomprimierung Zeit erforderlich ist, was sich erheblich auf die Leistung auswirken kann. Die beste Leistung erzielen Sie möglicherweise, wenn Sie die Daten in ein gekacheltes TIFF-Format konvertieren.
• Wenn die ursprünglichen Daten im Esri GRID-Format vorliegen, empfiehlt sich ebenfalls eine Konvertierung, wenn in einer Umgebung mit zahlreichen Verarbeitungsvorgängen die Skalierbarkeit wichtig ist.

Dateikonvertierung

Wenn die Dateien aus einem Format in ein anderes konvertiert werden, ohne dass Änderungen der Bit-Tiefe oder anderer Eigenschaften des Datasets erforderlich sind, verwenden Sie das Werkzeug 'Raster in anderes Format (mehrfach)'. Wenn Sie an einigen Eigenschaften Änderungen vornehmen müssen, verwenden Sie das Werkzeug 'Raster kopieren'. Wenn Sie dieses Werkzeug auf zahlreiche Datasets anwenden, können Sie mit der rechten Maustaste auf das Werkzeug klicken und dann auf "Batch" klicken oder aber ein Skript für die Aufnahme mehrerer Datasets schreiben. In beiden Fällen müssen die Umgebungen festgelegt werden. Das ist auf Anwendungsebene möglich, wenn Sie dies auf mehrere Werkzeuge anwenden, andernfalls auf Werkzeugebene.

Schritte:

1. Rufen Sie das Dialogfeld Umgebung auf.
   • Klicken Sie im Hauptmenü auf Geoverarbeitungs > umgebung.
   • Klicken Sie im Werkzeug auf die Schaltfläche Umgebung.
2. Erweitern Sie den Abschnitt Raster-Speicherung.
3. Aktivieren Sie Pyramiden berechnen.
   1. Klicken Sie auf den Dropdown-Pfeil Resampling-Verfahren für Pyramiden, und klicken Sie auf BILINEAR.
   2. Klicken Sie auf den Dropdown-Pfeil Pyramidenkomprimierungstyp und dann auf LZW.
4. Aktivieren Sie Statistik berechnen.
   1. Geben Sie als X- und Y-Sprungfaktor 1000 ein.

   Dieser Wert wird durch Division der Anzahl der Spalten durch 1.000 gewonnen.

5. Klicken Sie auf den Dropdown-Pfeil Komprimierung und dann auf LZ77.
6. Überprüfen Sie, ob unter Kachelgröße die Breite und Länge auf jeweils 128 festgelegt sind.

Projektion

Wenn die Projektion nicht für die einzelnen Datasets definiert ist, verwenden Sie das Werkzeug 'Projektion definieren'. Weitere Informationen finden Sie im folgenden Blog: My image is in the wrong spot.

Im Allgemeinen sollten Dateien nicht erneut projiziert werden.

Pyramiden erstellen

Wenn die Daten keine Pyramiden enthalten und die Kacheln groß sind (Anzahl der Zeilen oder Spalten größer als 5.000), wird empfohlen, Pyramiden zu erstellen. Sie können ermitteln, ob eine Datei Pyramiden enthält, indem Sie mit der rechten Maustaste in das Katalogfenster oder das Inhaltsverzeichnis klicken, dann auf "Eigenschaften" klicken und unter "Raster-Information" nach "Pyramiden" suchen.

Verwenden Sie beim Erstellen von Pyramiden für mehrere Datasets das Werkzeug 'Pyramiden und Statistiken berechnen'. Verwenden Sie die gleichen Umgebungseinstellungen wie oben.

Pyramiden erfordern einigen zusätzlichen Festplattenspeicherplatz und werden in separate Dateien mit der Erweiterung .ovr geschrieben.

Hinweis:

Die in diesem Workflow verwendeten Daten weisen keine Pyramiden auf. Der Grund dafür besteht hauptsächlich darin, dass die verschiedenen Auflösungen integriert und zusammen verwendet werden (und dadurch keine verringerten Auflösungen der Quelldaten erforderlich sind), sowie in der Kachelstruktur der Daten (keine der einzelnen Dateien ist extrem groß).

FWTools

Tipp:

Wenn die Anzahl der Datendateien 100.000 übersteigt und neue Pyramiden erstellt werden, können Sie sich entscheiden, Pyramiden in die Datendateien zu schreiben, damit nicht zu viele zusätzliche Dateien generiert werden. Es wird empfohlen, dazu das Dienstprogramm FWTools zu verwenden, das nicht im Lieferumfang von ArcGIS enthalten ist.

FWTools können Sie auf der Website http://fwtools.maptools.org herunterladen. Führen Sie dann die folgenden Befehle aus:

gdal_translate.exe -of Gtiff -co "TILED=YES" -co "COMPRESS=LZW" Input.xxx Output.tif
gdaladdo.exe -r average -ro --config TILED YES --config PHOTOMETRIC_OVERVIEW LZW output.tif 2 4 8 16

Fügen Sie bei 16-Bit-Bildern -co NBITS=12 vor "Input.xxx" ein.

Wenn die erstellten Dateien größer als 4 GB sind, fügen Sie entweder BIGTIFF=YES oder BIGTIFF=IF_NEEDED vor "Input.xxx" ein.

Berechnen von Statistiken

Statistiken werden für Raster-Datasets oder Mosaik-Datasets benötigt, wenn bestimmte Geoverarbeitungsvorgänge oder Tasks in ArcGIS Desktop-Anwendungen ausgeführt werden, z. B. eine Kontraststreckung angewendet wird oder Daten klassifiziert werden. In diesem Workflow müssen nicht für jede Datenquelle Statistiken berechnet werden, da keine angezeigt oder eigenständig verwendet werden. Zudem werden keine Funktionen oder Produkte erstellt, die von den Statistiken aus den einzelnen Datasets abhängen. Statistiken werden für Mosaik-Datasets zu Anzeigezwecken berechnet.

Weitere Informationen zu Statistiken finden Sie im Abschnitt Raster-Dataset-Statistik.