Die Zielgruppe für diesen Workflow besteht hauptsächlich aus Bilddatenmanagern von Organisationen, die für eine Reihe von Nutzerkreisen 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. Doch auch wenn nur ArcGIS Desktop verwendet wird, können mit diesem Workflow Höhendaten verwaltet und verteilt werden.
Dieser Workflow bezieht sich auf zellenbasierte Raster-Höhendaten und 3D-Punktdaten, die in LAS-Dateien gespeichert sind (in diesem Workflow können auch die LAS-Dataset- und Terrain-Dataset-Formate verwendet werden).
Im Folgenden wird die allgemeine Struktur der Verwaltung von Höhendaten aufgeführt. Die einzelnen Punkte werden weiter unten besprochen.
- Datenspeicherung (Größe, Anforderungen und Speicherorte)
- Vorbereiten von Daten (kann eine Vorverarbeitung erfordern)
- Erstellen eines Mosaik-Datasets für jede Sammlung (Quelle)
- Erstellen eines Mosaik-Datasets aus jeder Sammlung (Master)
- 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. Entwurfsmethoden für die erfolgreiche Gestaltung eines geographischen Informationssystems werden unter Systementwurfsstrategien
beschrieben.
Wichtig ist auch 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 in Teil 3 können Sie sehen, wie dies das Laden der Daten, die Qualitätssicherung/Qualitätskontrolle (QA/QK) sowie 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 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 ihre 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 unkomplizierter, höhendatenbasierter Produkte benötigt. In vielen Fällen handelt es sich hierbei 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 dann für die Benutzer bereitgestellt werden, ohne dass die ursprünglichen Quelldaten übertragen werden. Beispiele:
- Sichtfeldberechnungen für Sichtbarkeits- und Sichtlinienanalysen: Zur Bestimmung der Objekte, die von einem Standpunkt aus gesehen werden können, zur Platzierung von Mobilfunkantennen und Mikrowellen-Kommunikationsgeräten oder zur Planung von Kahlhieben
- Anwendungen im Katastrophenmanagement: Zur Evakuierungsplanung, für den Überschwemmungsschutz und für ein webbasiertes Überlagern aktueller Überschwemmungsdaten für Echtzeit-Entscheidungsprozesse
- Industrielle Planungen: Für Windprofile und die Sichtbarkeit von Windparkstandorten oder für den Bau von Dämmen für Wasserkraftwerke
- Berechnung kartografischer Konturlinien: Zur Anzeige auf Karten
- Berechnung von Profilen entlang gerader Linien oder Liniensegmente: Zur Erarbeitung von Pipelineführungen und Druckberechnungen, zur Straßenplanung oder zur Planung der Einschläge für den Straßenbau und der 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). Beispiele:
- 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 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 von Daten
- Interner Zugriff oder Zugriff über das Intranet bzw. 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.
Export bezieht sich auf das Extrahieren von Daten in einer bestimmten Ausdehnung und Raumbezug. Durch das Exportieren können unverarbeitete Datenwerte, eine Version dieser Werte, für die ein Resampling durchgeführt wurde, oder eine verarbeitete Version, wie z. B. ein Schummerungs- oder Neigungsbild, bereitgestellt werden. 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 Bittiefen 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 | Beschreibung |
|---|---|
GTOPO | GTOPO ist ein globales Höhen-Dataset mit einer Auflösung von 30 Bogensekunden (etwa 1 km), das unter Global 30 Arc-Second Elevation (GTOPO30) zum Download bereitsteht. |
SRTM | Die Shuttle Radar Topography Mission (SRTM) liefert Höhendaten im beinahe globalen Maßstab, die von einem Space Shuttle gewonnen wurden, und erstellt daraus die umfassendste hochauflösende digitale Topografiedatenbank der Erde. Sie ist verfügbar unter Shuttle Radar Topography Mission. |
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 | LIDAR-Daten können aus unterschiedlichen Quellen stammen. In diesem speziellen Fall stammen die Daten aus dem Oregon Metro Regional Land Information System (RLIS) |
Datenmanagement-Organisation und -Services (Produkte)
Ein Hauptziel besteht darin, sicherzustellen, dass alle Daten unabhängig von ihrer jeweiligen Ausdehnung 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 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 Bittiefen bestimmt. In diesem Fall werden sie anhand der Bittiefe 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
- Geschummerte Reliefs
- Neigung
- Ausrichtung (wird für Visualisierungen und Analysen verwendet)
Wenn von der Anwender-Community mehr als eine Geoid-Korrektur benötigt wird, kann der Datenmanager Geoide 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. Sie können zwischen folgenden Optionen wählen:
- 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, schlägt die Orthorektifizierung in allen NoData-Flächen fehl. 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 Renderings (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. Das sind 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, als 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).
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 Sie problemlos das Mosaik-Dataset nach diesen Informationen abfragen.
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'.
- LAS-Dateien, LAS-Datasets und Terrain-Datasets müssen 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 Performance des Servers 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ß (mehr als 5.000 Zeilen oder Spalten), die Daten sind nicht gekachelt oder weisen keine Pyramiden auf, und die Performance des Servers 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. Beispiel:
- 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 (mehrere). 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 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.
- Rufen Sie das Dialogfeld Umgebung auf.
- Klicken Sie im Hauptmenü auf Geoverarbeitungs > umgebung.
- Klicken Sie im Werkzeug auf die Schaltfläche Umgebungen.
- Erweitern Sie den Abschnitt Raster-Speicherung.
- Aktivieren Sie Pyramiden berechnen.
- Klicken Sie auf den Dropdown-Pfeil Resampling-Verfahren für Pyramiden und auf BILINEAR.
- Klicken Sie auf den Dropdown-Pfeil Pyramidenkomprimierungstyp und dann auf LZW.
- Aktivieren Sie Statistiken berechnen.
- Geben Sie als X- und Y-Sprungfaktor 1000 ein.
Dieser Wert wird durch Division der Anzahl der Spalten durch 1.000 gewonnen.
- Klicken Sie auf den Dropdown-Pfeil Komprimierung und dann auf LZ77.
- Überprüfen Sie, ob unter Kachelgröße die Breite und Höhe auf jeweils 128 festgelegt wurde.
Projektion
Wenn die Projektion nicht für die einzelnen Datasets definiert ist, verwenden Sie das Werkzeug Projektion definieren.
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 Fenster Katalog oder das Inhaltsverzeichnis klicken, dann auf Eigenschaften 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.
FWTools
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.