Desktop Help 10.0 - Laden großer Raster-Datasets in ArcSDE

Dieses Thema gilt nur für ArcEditor und ArcInfo.

Aufgrund der Natur solcher Daten sind Raster meist recht groß. Raster-Datasets und Raster-Kataloge sind selten kleiner als mehrere Gigabyte (GB). Sie können im Datenbankmanagementsystem (DBMS) einige Terabyte (TB) einnehmen. Die Verarbeitung solch umfangreicher Raster-Daten stellt selbst für erfahrenste Datenbankadministratoren (DBA) eine Herausforderung dar. In diesem Thema finden Sie die grundlegenden Schritte zum Laden großer Mengen von Raster-Daten in ein Raster-Dataset oder einen Raster-Katalog. Es wird davon ausgegangen, dass Sie bereits die Entscheidung getroffen haben, Raster in einer ArcSDE-Geodatabase zu speichern.

Für das Erstellen großer Raster-Datenbanken stehen drei grundlegende Prozesse zur Verfügung: Vorbereiten des Ladevorgangs für die Daten, Laden der Daten sowie Überprüfen und Validieren des Endprodukts. Dies schließt die folgenden Tasks ein:

Vorbereiten des Ladevorgangs für die Daten

Konfigurieren des Systems
Schätzen des Speicherplatzes für das DBMS
Zuweisen des Speicherplatzes für das DBMS

Laden der Daten

Vorbereiten der Quelldaten
Erstellen des Raster-Objekts
Laden der Raster-Daten in das Raster
Berechnen der DBMS-Statistik
Berechnen der Raster-Statistik

Überprüfen und Validieren

Anzeigen des fertig gestellten Ergebnisses

Konfigurieren des Systems

Die Konfiguration des Systems besteht aus zwei Schritten: Konfigurieren des DBMS und Konfigurieren von ArcSDE.

Konfigurieren der DBMS-Parameter

Die Konfigurationen für die einzelnen von Esri unterstützten DBMS unterscheiden sich voneinander, doch das Grundziel ist dasselbe – eine möglichst große Erhöhung des Datendurchsatzes in die Datenbank. Um sehr umfangreiche Mengen an Raster-Daten laden zu können, sollte das DBMS für die Schreibleistung optimiert werden. Jedoch kann DBMS-System, das für das Laden von mehreren Hundert Gigabyte an Raster-Daten oder mehr optimiert wurde, die Leistung anderer Anwendungen beeinträchtigen, die dieselben Ressourcen für andere Tasks verwenden. Daher wird empfohlen, bei einem DBMS, das nicht ausschließlich zum Laden von Raster-Daten verwendet wird, eine erneute Konfiguration des Systems zu erwägen und die Raster-Daten zu Zeiten mit geringer Auslastung zu laden. Auf diese Weise werden Auswirkungen auf die Arbeit anderer Benutzer vermieden. Sie können auch eine eigene Instanz des DBMS erstellen, die nur zum Laden der Raster-Daten verwendet wird.

Zum Speichern von Raster-Daten in SQL Server, Oracle, DB2 und Informix sind Richtlinien vorhanden. In den unten aufgeführten Informationen ist das Wichtigste aus diesen Richtlinien zusammengefasst.

Konfigurieren der DBMS-Parameter für SQL Server

Steuern Sie die von SQL Server verbrauchten Ressourcen nur, wenn auch andere Anwendungen auf dem Server ausgeführt werden.
Verwenden Sie die Option "lightweight pooling", um die Anzahl der Kontextumschaltungen in Threads zu verringern.
Legen Sie das Wiederherstellungsmodell der Datenbank nach Möglichkeit auf einfach fest. Dies ist sinnvoll, weil die Wiederherstellung auf einen bestimmten Zeitpunkt während des Ladens der Raster-Datasets nicht erforderlich ist und die Protokolle durch die anhaltende Protokollierung unnötig vergrößert werden.
Deaktivieren Sie "autoclose" und "autoshrink", da diese Optionen negative Auswirkungen auf die Performance haben können.

Weitere Informationen finden Sie unter Raster-Datasets und Raster-Kataloge in einer Geodatabase in SQL Server.

Konfigurieren der DBMS-Parameter für Oracle

Nehmen Sie die Konfiguration so vor, dass alle Prüfpunkte mit "online redo log"-Umschaltungen zusammenfallen. Oracle-DBAs legen die Initialisierungsparameter für Oracle LOG_CHECKPOINT_INTERVAL und LOG_CHECKPOINT_TIMEOUT auf 0 fest. Dadurch wird erzwungen, dass der Prüfpunkt mit einer "log"-Umschaltung zusammenfällt.
Vergrößern Sie die "online redo log"-Dateien mindestens auf jeweils 1 GB.
Vergrößern Sie den Datenblockpuffer-Cache so, dass die fehlerhaften Blöcke aufgenommen werden können, indem Sie die Größe von DB_BUFFER_CACHE erhöhen.
Erstellen Sie die Oracle-Datenbank mit einer Datenblockgröße von 8 KB. Dies ist die optimale Datenblockgröße zum Speichern von BLOB-Daten, die inzwischen der zugrunde liegende Standardspeichertyp für alle ArcGIS-Binärdaten sind. Große Datenblöcke von 16 KB oder 32 KB führen mit hoher Wahrscheinlichkeit zu ungenutztem Platz in den BLOB-Protokollsegmenten. Konsultieren Sie die Oracle-Dokumentation, um umfassende Informationen zur BLOB-Speicherung zu erhalten.

Weitere Informationen finden Sie unter Raster-Datasets und Raster-Kataloge in einer in Oracle gespeicherten Geodatabase.

Konfigurieren der DBMS-Parameter für DB2

Erstellen Sie getrennte Puffer-Pools für die Raster-Tablespaces.
Erstellen Sie einen umfangreichen Puffer-Pool für den Tablespace, in dem die Raster-Blocktabelle gespeichert ist.
Wenn DB2 auf einer AIX-Plattform installiert ist, legen Sie die folgenden Parameter fest:

db2set DB2_MMAP_READ=OFF
db2set DB2_MMAP_WRITE=OFF

Weitere Informationen finden Sie unter Raster-Datasets und Raster-Kataloge in einer Geodatabase in DB2.

Konfigurieren der DBMS-Parameter für Informix

Konfigurieren Sie die "onconfig"-Parameter:

Legen Sie BUFFERS auf einen genügend großen Wert fest, um vor den Cleanern zu bleiben.
Legen Sie die LOGSIZE auf 100000 fest.
Stellen Sie sicher, dass das physische Protokoll nicht im rootdbs-dbspace erstellt wird.
Legen Sie LOG_BACKUP_MODE so fest, dass die logischen Protokolle kontinuierlich gesichert werden.
Legen Sie die LOGSMAX auf 100 fest.
Legen Sie RA_PAGES auf 125 fest.
Legen Sie RA_THRESHOLD auf 85 fest.
Legen Sie RESIDENT auf -1 fest.
Legen Sie den NETTYPE-Parameter so fest, dass Remote-Verbindungen bevorzugt werden, wenn Sie direkte Verbindungen verwenden möchten.

Weitere Informationen finden Sie unter Raster-Datasets und Raster-Kataloge in einer Geodatabase in Informix.

Konfigurieren des ArcSDE-Servers

ArcSDE verwendet für den Datentransfer zwischen dem ArcSDE-Client und dem ArcSDE-Server Transportpuffer. Wenn der Datenpuffer des Clients während eines Schreibvorgangs den festgelegten Schwellenwert erreicht, wird er geleert und der Inhalt an den ArcSDE-Server übermittelt. Während dieser Puffer vom ArcSDE-Server verarbeitet wird, akzeptiert der ArcSDE-Client weitere Daten im Puffer. Der Client sendet den Inhalt seines Puffers erneut, sobald der Schwellenwert erreicht wurde, jedoch nur, wenn der ArcSDE-Server wartet. Bei Raster-Daten wird die Größe des Transportpuffers über den ArcSDE-Serverparameter RASTERBUFSIZE gesteuert. Standardmäßig ist dieser Parameter auf 200 KB festgelegt, was für die meisten Ladevorgänge ausreichend ist. Der von RASTERBUFSIZE angegebene Speicher wird von ArcSDE verwendet, um den Puffer auf dem ArcSDE-Client und auf dem ArcSDE-Server zu verdoppeln. Wenn Sie den empfohlenen Standardwert von 200 KB verwenden, werden 400 KB auf dem Client und 400 KB auf dem Server zugewiesen. Neben den Transportpuffern weist ArcSDE für Daten, die vom DBMS gelesen und in das DBMS geschrieben wurden, drei weitere Puffer auf dem Server zu. Dadurch erhöht sich der auf dem Server zugewiesene Speicher auf insgesamt 1000 KB. Wenn Sie eine direkte Verbindung verwenden, werden die Funktionen von ArcSDE-Client und -Server auf dem Client ausgeführt. Daher ist der von einer direkten Verbindung zugewiesene Speicher sieben Mal so groß wie der von RASTERBUFSIZE angegebene. Ändern Sie die Größe von RASTERBUFSIZE nur, wenn die Standardgröße für die unkomprimierte Raster-Kachelgröße nicht ausreicht. Die unkomprimierte Raster-Kachelgröße ermitteln Sie, indem Sie die Kachelbreite mit der Kachelhöhe multiplizieren und diesen Wert mit dem Faktor der Pixeltiefe multiplizieren. Wenn Sie zum Beispiel die Standardwerte 128 x 128 für die Kachelbreite und die Kachelhöhe verwenden, beträgt das Produkt dieser zwei Werte 16.384. Multiplizieren Sie dieses Produkt mit dem Faktor der Pixeltiefe aus der Tabelle unten, um die unkomprimierte Größe der Raster-Kachel zu erhalten. Bei einer Pixeltiefe von 32 entspricht die unkomprimierte Größe 65.536 Byte. Dies liegt weit unter dem Standardwert von 200 KB. Wenn Sie die Kachelgröße jedoch auf 256 x 256 erhöhen, beträgt die unkomprimierte Größe 262.144 Byte. Ohne Erhöhen des Parameters RASTERBUFSIZE wird möglicherweise der Fehler SE_RASTER_BUFFER_TOO_SMALL (-294) ausgegeben. In diesem Fall müssen Sie den Parameter RASTERBUFSIZE auf ca. 300 KB erhöhen.

Pixeltiefe	Faktor Pixeltiefe
1-Bit	0,125
4-Bit	0,25
8-Bit	1
16-Bit	2
32-Bit	4
64-Bit	8

Liste des Pixeltiefenfaktors für Pixeltiefen

Wenn Sie die Einstellung des Parameters RASTERBUFSIZE ändern möchten, verwenden Sie das ArcSDE-Werkzeug "sdeconfig" mit der "alter"-Option:

sdeconfig -o alter -v RASTERBUFSIZE=10240000 -u sde -p esri

Die Änderung wird eigentlich in der Tabelle SDE.SERVER_CONFIG vorgenommen, in der der neue Wert gespeichert wird. Der Wert wirkt sich auf alle ArcSDE-Sitzungen aus, in denen nach dem Ändern des Parameters eine Verbindung hergestellt wird.

Erhöhen Sie den Parameter RASTERBUFSIZE nur so viel wie für die unkomprimierte Raster-Kachelgröße erforderlich ist. Ein zu großer Parameterwert kann sich nachteilig auf den Fluss der Raster-Daten durch das System auswirken.

Verbindungsarchitektur

Die Erstellung der Pyramide mit verringerter Auflösung stellt einen Multi-Thread-Vorgang mit hoher Prozessorauslastung dar. Dieser Task wird vom ArcSDE-Server ausgeführt. Wenn Sie den Computer mit der größten CPU-Leistung in Ihrer Client-/Serverarchitektur als Server verwenden, können Sie einen höheren Durchsatz von Raster-Daten in die Datenbank erzielen. Zur Ermittlung der CPU-Leistung multiplizieren Sie die Anzahl der CPUs mit ihrer Prozessorgeschwindigkeit.

Der Server kann eigenständig ausgeführt werden, so wie beim Herstellen einer Verbindung mit einem ArcSDE-Service. Sie können ihn aber auch in die Client-Anwendung (z. B. ArcCatalog) einbetten, so wie beim Herstellen einer direkten Verbindung.

Die Entscheidung für oder gegen die Verwendung einer direkten Verbindung beim Laden von Raster-Daten hängt davon ab, ob die CPU-Leistung auf dem Client oder dem Server mit dem ArcSDE-Service größer ist. Sofern die CPU-Leistung des Clients besser ist, verwenden Sie eine direkte Verbindung, um die Pyramiden auf dem Client zu erstellen.

Sie müssen auch die Kapazität des Servers mit dem ArcSDE-Service berücksichtigen. Es kann sein, dass der Server zwar eine höhere CPU-Leistung als der Client bietet, doch seine Kapazitätsgrenze aufgrund von Anforderungen anderer Anwendungen bereits erreicht ist. Wenn der Server mehr CPU-Leistung als der Client bietet und er seine Kapazitätsgrenze noch nicht erreicht hat, stellen Sie eine Verbindung mit dem ArcSDE-Service her.

Schätzen des Speicherplatzes für das DBMS

Es wird empfohlen, den Speicherplatz für das DBMS vor dem Beginn umfangreicher Ladeprojekte für Raster-Daten zu organisieren. Dazu müssen Sie eine Schätzung des für die Raster-Daten in der Datenbank erforderlichen Speicherplatzes sowie des Speicherplatzes für die Bereitstellung der Bilddateien vor dem Laden vornehmen. Sobald Sie über eine Schätzung des erforderlichen Speicherplatzes verfügen, können Sie den Speicherplatz im DBMS zuweisen, die DBTUNE-Parameter in ArcSDE einrichten und mit dem Laden der Raster-Daten beginnen.

Die Raster-BLK-Tabelle ist die mit Abstand umfangreichste der Raster-Tabellen und -Indizes. Sie ist typischerweise 150-mal größer als das nächstgrößte DBMS-Objekt, der zusammengesetzte Index der Raster-Blocktabelle. Die anderen Tabellen und Indizes des Raster-Objekts sind Tausende Mal kleiner und werden meist mit dem zusammengesetzten Index der Raster-Blocktabelle als einzelner DBMS-Speicherplatz gruppiert. Da die Raster-Blocktabelle so viel größer als alle anderen Objekte ist, erfolgt die Schätzung der Größe der Raster-Daten primär anhand dieser Raster-Blocktabelle.

Bei Raster-Datasets und Raster-Katalogen werden die Pixeldaten im DBMS in der BLK-Tabelle gespeichert. Mosaik-Datasets verweisen hingegen auf die Raster-Datasets und speichern die Pixeldaten nicht in der BLK-Tabelle. Die BLK-Tabelle BLK bleibt leer, außer das Mosaik-Dataset-Übersichten werden im DBMS gespeichert.

Zum Schätzen des Speicherplatzes, den eine Raster-Blocktabelle in der Datenbank einnehmen wird, stehen zwei grundsätzliche Methoden zur Verfügung. Bei einer Methode werden einige Beispielbilder geladen und der erwartete Gesamtspeicherplatz für die Raster-Blocktabelle in der Datenbank anhand des Speicherplatzes für die Stichprobe extrapoliert. Bei der anderen Methode wird der erforderliche Speicherplatz über eine Formel berechnet, die die erwarteten Eigenschaften der Raster-Objekte als Eingabe akzeptiert. Die erste Methode führt meist zu besseren Schätzungen als die zweite, doch ist die Formel in Fällen nützlich, in denen die Quelldaten vor dem Erstellen der Datenbank nicht ohne weiteres verfügbar sind. Um die Größe einer Raster-Blocktabelle genau schätzen zu können, müssen Sie bereits die folgenden Eigenschaften ermittelt haben, die die Speichergröße einer Raster-Blocktabelle beeinflussen:

Weitere Informationen zum Erfassen der grundlegenden Informationen für Raster-Datasets

Größenschätzung für die Raster-Blocktabelle anhand einer Stichprobe

Erstellen Sie ein kleines Raster-Objekt, indem Sie mit ArcCatalog eine Anzahl von Beispiel-Raster-Datasets laden. Für das Raster-Objekt müssen dieselben Einstellungen für Komprimierungstyp, Komprimierungsqualität, Pixeltiefe, Anzahl der Bänder und Kachelgröße wie für das letztlich erstellte Raster-Objekt festgelegt sein, das von dargestellt wird. Diese Raster-Eigenschaften beeinflussen die Speichergröße eines Raster-Objekts in der Datenbank.

Nach dem Laden von Beispiel-Raster-Daten mit ArcCatalog ermitteln Sie den Speicherplatz, der von der Blocktabelle des Raster-Beispielobjekts in der Datenbank eingenommen wird.

Für Oracle erfolgt dies durch Abfragen der BLOCKS-Spalte in der Oracle-Systemtabelle USER_TABLES für die Raster-Blocktabelle des Raster-Objekts. Dazu müssen Sie zunächst den Namen der Raster-Blocktabelle des Raster-Objekts ermitteln, wozu Sie die "rastercolumn_id" aus der Tabelle SDE.RASTER_COLUMN benötigen.

Hinweis:

In den folgenden Beispielen dieses Dokuments wird davon ausgegangen, dass die Business-Tabelle des Beispiel-Raster-Objekts mit EARTH benannt ist.

Rufen Sie die rastercolumn_id für das Raster-Objekt ab.

SQL> select rastercolumn_id
from sde.raster_columns
where table_name = 'EARTH';

RASTERCOLUMN_ID 
=--------------- 
             14

Rufen Sie die Größe der Raster-Blocktabelle mit der folgenden Abfrage ab.

SQL> exec dbms_stats.gather_table_stats (NULL,'EARTH'); 
SQL> select sum(length(rasterband_id)) 
          + sum(length(rrd_factor))
          + sum(length(row_nbr))
          + sum(length(col_nbr))
          + sum(length(block_data)) "total size"
      from sde_blk_14; 
total size 
=----------- 
762707968

Die Gesamtgröße der Raster-Blocktabelle beträgt 762.707.968 Byte oder ca. 727 MB.

Ermitteln Sie das Verhältnis zwischen der Größe des Beispiel-Raster-Datasets und der Gesamtgröße aller Quelldateien für das Raster-Dataset, die Sie laden möchten. In diesem Beispiel beträgt die Größe des Beispiel-Raster-Datasets 2 GB, während der Datenanbieter eine Gesamtgröße aller Raster-Dataset-Dateien von etwa 3 TB angegeben hat.

Konvertieren Sie zunächst die Gesamtgröße von 3 Terabyte in Gigabyte:
```
3 TB * 1024 = 3072 GB
```
Die Verhältnis zwischen der Gesamtgröße des Raster-Datasets und der Größe des Beispiel-Raster-Datasets wird wie folgt berechnet:
```
total size of all rasters / sample raster size = total size to sample size
```
Beispiel:
```
3072 / 2 = 1536
```
Durch Multiplikation des Verhältnisses zwischen der Raster-Dataset-Gesamtgröße und der Größe des Beispiel-Raster-Datasets mit der Größe der in der Datenbank gespeicherten Beispieldaten erhalten Sie eine grobe Schätzung des Gesamtspeicherplatzes, der zum Speichern aller Raster-Dataset-Dateien im Raster-Objekt erforderlich ist.
```
727 MB * 1536 = 1,116,672 MB = 1090 GB = 1.06 TB
```

Um die Größe der Beispieldaten in SQL Server zu ermitteln, rufen Sie erst die Größe der Beispieldaten ab, und wechseln Sie dann zum oben beschriebenen Schritt 3.

Rufen Sie die rastercolumn_id für das Raster ab.

1> select rastercolumn_id 
2> from sde.sde_raster_columns 
3> where table_name = 'EARTH';

rastercolumn_id 
=--------------
              3

Ermitteln Sie anhand der ID den Speicherplatz für die Beispieldaten.
```
1> exec sp_spaceused 'sde_blk_3'; 
2> go 
name        rows   reserved   data       index_size  used
=--------------------------------------------------------------
SDE_blk_3   4233   29712 KB   29632 KB   16 KB       64 KB
```
In diesem Fall betrug die Größe des ursprünglichen Raster-Datasets 50 MB, doch nach dem Laden beträgt die Größe des eingenommenen Speicherplatzes 29.632 KB + 16 KB = 29.648 KB, also ungefähr 29 MB.

Größenschätzung für die Raster-Blocktabelle anhand einer Formel

Die folgende Formelmethode liefert eine grobe Größenschätzung für die Raster-Blocktabelle. Wenn die Quelldaten ganz oder teilweise verfügbar sind, sollten Sie die oben beschriebene Schätzmethode für die Raster-Blocktabelle verwenden, da diese genauere Ergebnisse liefert.

Arbeite Sie mit einer groben Schätzung der Ausdehnung in Meter oder Fuß. Bei Raster-Datasets mit einer Pixelauflösung in Meter (zum Beispiel 5 Meter, 15 Meter oder 150 Meter) rufen Sie die Schätzung in diesen Einheiten ab. Wenn die Auflösung in Fuß oder Zoll ausgedrückt ist, rufen Sie die Ausdehnung entsprechend in diesen Einheiten ab. Eine gute Möglichkeit, die Ausdehnung abzurufen, besteht darin, mit ArcMap einen Polygonumriss für die Bildausdehnung zu erstellen. Sie müssen so viel leeren Raum wie möglich entfernen, da in der Geodatabase keine leeren Blöcke gespeichert werden.
Konvertieren Sie die Ausdehnung in Pixel.
```
(Extent of raster in pixel units) / (pixel resolution) = Number of pixels
```
Bei Quell-Raster-Datasets mit einer Auflösung von 15 Meter und einer Ausdehnung von 450 Quadratkilometer wird die Konvertierung in Pixel wie folgt berechnet:
```
(km² to m² conversion factor) / (the pixel resolution in m²) = pixels
(450 km² * 1,000,000) / (15 x 15) = 2,000,000 pixels
```
Nehmen Sie als weiteres Beispiel eine Fläche von 50 Quadratmeilen mit einer Auflösung von 1 Fuß. Die geschätzte Ausdehnung in Pixel beträgt etwa:
```
(mi² to ft² conversion factor) / (the pixel resolution in ft²) = pixels
(50 mi² * 5280²)/ (1 x 1) = 1,393,920,000 pixels
```
Multiplizieren Sie den Wert mit der Anzahl der Bänder. Wenn es sich um ein Einzelband-Raster-Dataset in Graustufen oder Schwarzweiß handelt, können Sie diesen Schritt überspringen. Angenommen, die 15-Meter-Daten aus Schritt 2 weisen in diesem Beispiel drei Bänder auf (die die RGB-Farben darstellen).
```
2,000,000 pixel extent * 3 bands = 6,000,000 pixels
```
Konvertieren Sie den Wert in Byte, indem Sie den Faktor der Pixeltiefe aus der Tabelle anwenden.
Pixeltiefe
Bytefaktor
1-Bit
0,125
4-Bit
0,25
8-Bit
1
16-Bit
2
32-Bit
4
64-Bit
8
Liste des Pixelbytefaktors für Pixeltiefen
```
8-bit data: 6,000,000 pixels * 1 = 6,000,000 Bytes / 1024² = 5.7 MB
16-bit data: 6,000,000 pixels * 2 = 12,000,000 Bytes / 1024² = 11.4 MB
```
Fügen Sie die Pyramide mit verringerter Auflösung hinzu. Durch die Pyramide mit verringerter Auflösung wird die Größe des Rasters um ein Drittel erhöht. Multiplizieren Sie die Bytezahl aus Schritt 4 daher mit 1,33.
```
5.72 MB * 1.33 = 7.67 MB
```
Wenden Sie die Raster-Komprimierung an. Die folgende Tabelle gibt ein Beispiel für die erwarteten Einsparungen bei verschiedenen Komprimierungs- und Qualitätsstufen. Die genauen Werte schwanken je nach verwendeten Daten.
Komprimierungstyp
Komprimierungsfaktor
LZ77
0,5
JPEG 75 %
0,15
JPEG 50 %
0,1
JPEG 2000 80/100
0,36
JPEG 2000 60/100
0,15
JPEG 2000 55/100
0,11
JPEG 2000 50/100
0,07
JPEG 2000 45/100
0,06
Komprimierungsfaktoren für Komprimierungstypen
Wenn Sie das Beispiel in Schritt 5 fortführen und eine JPEG-Komprimierung mit einer Qualität von 50 Prozent anwenden, multiplizieren Sie die Bytezahl mit dem Komprimierungsfaktor 0,1.
```
7.67 MB * 0.1 = 0.77 MB
```
Erhöhen Sie die Schätzung für den Aufwand im DBMS und die Ganzzahlspalten in der Raster-Blocktabelle. Der Wert aus Schritt 7 stellt eine Schätzung des erforderlichen absoluten Speicherplatzes für in der Raster-Blocktabelle gespeicherte Pixeldaten dar. Die Pixels sind entsprechend der beim Erstellen des Raster-Objekts ausgewählten Kachelgröße in Blöcke aufgeteilt. Die Pixelblöcke werden in den Datenblöcken der Datenbank gespeichert. Die Raster-Blöcke passen in diese aufgrund gewisser Unterschiede in der Komprimierung nicht perfekt hinein. In jedem Fall entsteht eine bestimmte Menge nicht verwendeten Blockspeicherplatzes. Zudem werden in der Raster-Blocktabelle vier Ganzzahlspalten gespeichert, sowie die Pixel-BLOB-Spalte, mit der jeder Block eindeutig gekennzeichnet wird. Durch die Ganzzahlspalten wird der Aufwand beim Speichern ebenfalls erhöht. Erhöhen Sie die Schätzung in Schritt 7 um mindestens 10 Prozent für den DBMS-Aufwand und die Ganzzahlspalten der Raster-Blocktabelle.

Komprimierungstyp	Komprimierungsfaktor
LZ77	0,5
JPEG 75 %	0,15
JPEG 50 %	0,1
JPEG 2000 80/100	0,36
JPEG 2000 60/100	0,15
JPEG 2000 55/100	0,11
JPEG 2000 50/100	0,07
JPEG 2000 45/100	0,06

Zuweisen des Speicherplatzes für das DBMS

Die Art, in der Sie den Speicherplatz für das DBMS erstellen, hängt davon ab, wie dieser verwaltet werden muss. In manchen DBMS können Sie die Datendateien einer Datenbank verschieben, daher können Sie alle Raster-Tabellen und Indizes an einem Ort speichern. Wenn die Daten nicht übertragen werden müssen, erstellen Sie den Speicherplatz entsprechend der Größe: viel Speicherplatz für die Blocktabelle und deren Index und weniger Speicherplatz für die anderen Raster-Tabellen und deren Indizes.

Manche DBMS ermöglichen die automatische Vergrößerung des DBMS-Speicherplatzes. Sie sollten den Speicherplatz jedoch im Voraus zuweisen, um sicherzustellen, dass beim Laden keine Probleme auftreten. Das Sie den Aufwand für die Schätzung der Speicherplatzanforderungen für die Daten bereits betrieben haben, können Sie auch den entsprechenden Speicherplatz reservieren.

Erstellen des Speicherplatzes für das DBMS Oracle

Erstellen Sie den Tablespace für die Nicht-Raster-Blöcke.

create tablespace earth
datafile 'd:\oradata\earth.dbf'
size 500M
extent management local 
uniform size 1M;

Erstellen Sie den Tablespace für die Raster-Blöcke.

create tablespace earth_blocks
datafile 'e:\oradata\earth_blocks.dbf'
size 50000M
extent management local
segment space management manual
uniform size 100M;

Erstellen des Speicherplatzes für das DBMS SQl Server

Erstellen Sie die SQL Server-Datenbank so groß, dass das gesamte Raster-Objekt gespeichert werden kann.

Erstellen des Speicherplatzes für das DBMS DB2

Erstellen Sie einen Tablespace, in dem alle Nicht-Raster-Blockdaten gespeichert werden.
```
create tablespace earth managed by database using (file 'd:\earth.dat' 500000);
```

Erstellen Sie einen Tablespace, in dem alle Raster-Blocktabellendaten gespeichert werden.

create long tablespace earth_blocks managed by database
using (file 'e:\earth_blocks.dat' 50000000);

Erstellen des Speicherplatzes für das Informix-DBMS

Erstellen Sie den dbspace, in dem alle Nicht-Raster-Blocktabellen gespeichert werden.
```
onspaces -c -d earth -p d:\earth.dbs -o 0 -s 5000
```
Erstellen Sie die dbspaces, in dem die Raster-Blocktabelle gespeichert wird.
```
onspaces -c -d earth_blocks -p e:\earth_blocks.dbs -o 0 -s 50000000
```

Konfigurieren der DBTUNE-Schlüsselwörter

Die Tabelle SDE.DBTUNE enthält die Speicherparameter, anhand derer ArcSDE Tabellen und Indizes in der Datenbank erstellt. Die Speicherparameter werden nach Schlüsselwort angeordnet. Durch Angabe eines DBTUNE-Schlüsselwortes während der Erstellung eines Geodatabase-Objekts, z. B. eines Rasters, legen Sie fest, wie die Tabellen und Indizes des Geodatabase-Objekts erstellt werden und in welcher Speichereinheit der Datenbank sie enthalten sein sollen.

Für jede Kombination aus Tabelle und Index des Rasters ist ein DBTUNE-Speicherparameter vorhanden. Sie bearbeiten die Datei "SDEHOME/etc/dbtune.sde", indem Sie ein neues Schlüsselwort, gefolgt von der Angabe der einzelnen Speicherparameter, anhängen. Beispiele dafür werden unten aufgeführt. Anschließend aktualisieren Sie mit dem Importvorgang sdedbtune die Tabelle SDE.DBTUNE.

Je nach DBMS können die Speicherparameter voneinander abweichen. Die elf DBTUNE-Speicherparameter in Oracle sind unten aufgeführt, viele davon stehen jedoch auch in anderen DBMS zur Verfügung.

Der Speicherparameter für die Business-Tabelle lautet B_STORAGE, und wenn die Business-Tabelle eine bei ArcSDE registrierte Spalte für die Zeilen-ID enthält, lautet der entsprechende Speicherparameter B_INDEX_ROWID. Die Business-Tabelle für ein Raster-Dataset enthält eine einzelne Zeile und ist daher sehr klein. Die Business-Tabelle für einen Raster-Katalog ist meist klein und enthält für jedes Raster-Dataset eine Zeile.
Im Folgenden finden Sie Beispiele für die Speicherparameter B_STORAGE und B_INDEX_ROWID:
```
B_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
B_INDEX_ROWID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
```
Die Speicherung der Raster-Tabelle wird vom Parameter RAS_STORAGE gesteuert, während die Speicherung des Indexes "raster_id" in dieser Tabelle vom Parameter RAS_INDEX_ID gesteuert wird. Die Raster-Tabelle für ein Raster-Dataset enthält eine einzelne Zeile und ist daher sehr klein. Die Raster-Tabelle für einen Raster-Katalog ist meist klein und enthält für jedes Raster-Dataset nur eine Zeile.
Im Folgenden finden Sie Beispiele für die Speicherparameter RAS_STORAGE und RAS_INDEX_ID:
```
RAS_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
RAS_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
```
Die Raster-Bandtabelle wird entsprechend dem Speicherparameter BND_STORAGE gespeichert. BND_INDEX_ID steuert die Speicherung des Indexes "rasterband_id", und der Speicherparameter BND_INDEX_COMPOSITE steuert die Speicherung des zusammengesetzten Indexes für die Spalten "sequence_nbr" und "raster_id". Die Raster-Bandtabelle ist meist klein und nur geringfügig größer als das Raster oder die Business-Tabelle des Raster-Objekts. Darin ist für jedes Raster-Band ein Datensatz gespeichert. Bei einem Raster-Katalog, in dem 1.000 Raster-Datasets mit drei Bändern gespeichert sind, enthält die Raster-Bandtabelle 3.000 Datensätze.
Im Folgenden finden Sie Beispiele für die Speicherparameter BND_STORAGE, BND_INDEX_COMPOSITE und BND_INDEX_ID:
```
BND_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
BND_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
BND_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
```
Der Speicherparameter AUX_STORAGE steuert die Speicherung des Raster-Zusatztabelle, während der Speicherparameter AUX_INDEX_COMPOSITE die Speicherung des zusammengesetzten Indexes der Tabelle steuert. Die Anzahl der Datensätze in der Raster-Zusatztabelle schwankt je nach optional gespeicherten Raster-Banddaten. Aus Gründen der Effizienz wird die NoData-Bit-Maskierung für jedes Raster-Band gespeichert, jedoch nur, wenn die Bit-Maskierung kleiner als 10 MB ist. Anderenfalls wird sie nicht gespeichert, und ArcSDE muss die NoData-Bit-Maskierung von den Pixelblöcken abrufen, die in der Raster-Blocktabelle gespeichert sind. Außerdem werden darin die Raster-Statistiken (sofern diese berechnet wurden) und die Colormap (sofern diese vorhanden ist) gespeichert. Es ist möglich, dass die Raster-Zusatztabelle für ein bestimmtes Raster-Objekt leer ist oder mehr Datensätze als die Raster-Bandtabelle enthält. Sie weist meist etwa die gleiche Größe auf wie die Raster-Bandtabelle.
Im Folgenden finden Sie Beispiele für die Speicherparameter AUX_STORAGE und AUX_INDEX_COMPOSITE:
```
AUX_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
AUX_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
```
BLK_STORAGE steuert die Speicherung der Raster-Blocktabelle, die von den Tabellen und Indizes des Raster-Objekts die größte ist. In der Raster-Blocktabelle werden die Pixeldaten entsprechend der beim Erstellen des Raster-Objekts festgelegten Kachelgröße gespeichert. BLK_INDEX_COMPOSITE steuert die Speicherung des zusammengesetzten Indexes der Raster-Blocktabelle, in dem die Indizes der vier Ganzzahlspalten "rasterband_id", "row_nbr", "col_nbr" und "rrd_factor" integriert sind. Die Raster-Blocktabelle ist etwa 150-mal größer als ihr Index. Da die Raster-Blocktabelle jedoch sehr groß werden kann, sollte der zugehörige Index in demselben Tablespace wie die Raster-Blocktabelle selbst gespeichert werden.
Im Folgenden finden Sie Beispiele für die Speicherparameter BLK_STORAGE und BLK_INDEX_COMPOSITE:
```
BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH_BLOCKS STORAGE
     (INITIAL 500M MINEXTENTS 10) LOB( BLOCK_DATA) STORE AS (ENABLE STORAGE 
      IN ROW CHUNK 8K RETENTION CACHE)"
BLK_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE 
     EARTH_BLOCKS"
```

Die Footprints des Raster-Datasets und des Raster-Katalogs werden in der räumlichen Spalte gespeichert. Wenn die räumliche Spalte als binärer ArcSDE-Typ erstellt wird, müssen Sie auch die folgenden DBTUNE-Speicherparameter konfigurieren:

S_STORAGE – Die räumliche Indextabelle
S_INDEX_ALL – Der Coverage-Index, der alle Spalten der räumlichen Indextabelle auflistet
S_INDEX_SP_FID – Der Index der Spalte "fid" in der räumlichen Indextabelle

Beispiele für die Darstellung des DBTUNE-Schlüsselworts in der Datei DBTUNE für die einzelnen DBMS finden Sie unten. Das doppelte Nummernzeichen (##) kennzeichnet den Beginn des DBTUNE-Schlüsselworts EARTH, während durch END dessen Ende gekennzeichnet wird.

Beispiel für DBTUNE-Schlüsselwörter in SQL Server

##EARTH_15M
B_CLUSTER_ROWID 0 
B_CLUSTER_SHAPE 1
B_CLUSTER_RASTER 0 
B_INDEX_ROWID "WITH FILLFACTOR = 100"
B_INDEX_SHAPE "WITH FILLFACTOR = 100"
B_INDEX_RASTER "WITH FILLFACTOR = 100"
B_STORAGE ""
B_TEXT_IN_ROW 256
RAS_STORAGE ""
RAS_CLUSTER_ID 1
RAS_INDEX_ID "WITH FILLFACTOR = 100"
BND_STORAGE "" 
BND_CLUSTER_ID 0
BND_INDEX_ID "WITH FILLFACTOR = 100"
BND_CLUSTER_COMPOSITE 0
BND_INDEX_COMPOSITE "WITH FILLFACTOR = 100"
AUX_STORAGE ""
AUX_CLUSTER_COMPOSITE 1
AUX_INDEX_COMPOSITE "WITH FILLFACTOR = 100" 
BLK_STORAGE "" 
BLK_CLUSTER_COMPOSITE 1
BLK_INDEX_COMPOSITE "WITH FILLFACTOR = 100" 
END

Beispiel für DBTUNE-Schlüsselwörter in Oracle

##EARTH_15M 
RAS_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" 
RAS_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
BND_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
BND_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
BND_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
AUX_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" 
AUX_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" 
BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH_BLOCKS STORAGE 
       (INITIAL 500M MINEXTENTS 10) LOB( BLOCK_DATA) STORE AS (ENABLE 
        STORAGE IN ROW CHUNK 8K RETENTION CACHE)"
BLK_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH_BLOCKS" 
END

Beispiel für DBTUNE-Schlüsselwörter in DB2

##EARTH_15M 
AUX_STORAGE "IN EARTH INDEX IN EARTH" 
BLK_STORAGE "IN EARTH INDEX IN EARTH LONG IN EARTH_BLOCKS" 
BND_STORAGE "IN EARTH INDEX IN EARTH" 
RAS_STORAGE "IN EARTH INDEX IN EARTH"
END

Beispiel für DBTUNE-Schlüsselwörter in Informix

##EARTH_15M 
RAS_STORAGE "EXTENT SIZE 16 NEXT SIZE 16 LOCK MODE ROW IN EARTH" 
RAS_INDEX_ID "FILLFACTOR 90 IN EARTH"
BND_STORAGE EXTENT SIZE 16 NEXT SIZE 16 LOCK MODE ROW IN EARTH"
BND_INDEX_COMPOSITE "FILLFACTOR 90 IN EARTH" 
BND_INDEX_ID "FILLFACTOR 90 IN EARTH" 
AUX_STORAGE "EXTENT SIZE 16 NEXT SIZE 16 LOCK MODE ROW IN EARTH" 
AUX_INDEX_COMPOSITE "FILLFACTOR 90 IN EARTH" 
BLK_STORAGE "EXTENT SIZE 1000 NEXT SIZE 1000 LOCK MODE ROW IN EARTH_BLOCKS" 
BLK_INDEX_COMPOSITE "FILLFACTOR 90 IN EARTH"
END

Vorbereiten der Quelldaten

Machen Sie die Quelldateien des Raster-Datasets verfügbar, indem Sie diese auf Festplattenlaufwerken bereitstellen, auf die mit ArcCatalog oder ArcObjects-Skripten zum Laden der Daten in die Geodatabase zugegriffen werden kann.

CD oder DVD

Wenn sich die Raster-Datasets auf CD oder DVD befinden, kopieren Sie diese auf eine schnelle Festplatte. Lokale Festplatten sind Netzlaufwerken vorzuziehen. Das direkte Laden von Dateien von CD oder DVD wird nicht empfohlen, da die Zugriffszeit wesentlich länger als bei Festplatten ist.

Bandsilo

Wenn Sie die Dateien von einem Bandsilo laden, werden die zu ladenden Raster-Dataset-Dateien im Online-Cache bereitgestellt, bevor Sie mit dem Laden beginnen.

Organisieren der Quelldaten

Bilddateien sollten für den entsprechenden Ladevorgang zusammen in getrennten Ordnern gruppiert werden. Dadurch kann das Ladewerkzeug alle Dateien in einem Ordner öffnen und diese als Stapel laden, sodass nicht jede Datei einzeln geladen werden muss. Sie können beispielsweise mehrere Raster-Datasets in ein einzelnes Raster-Dataset mosaikieren, jede Raster-Dataset-Eingabe in ein einzelnes, eigenständiges Raster-Dataset laden, Raster-Datasets in einem Raster-Katalog gruppieren oder einen Raster-Katalog mit mehreren mosaikierten Raster-Datasets erstellen. Die Betriebssysteme weisen unterschiedliche Beschränkungen hinsichtlich der Anzahl geöffneter Dateien auf. Wenn Sie diese Grenze erreichen, müssen Sie daher zusätzliche Ordner erstellen und einen weiteren Ladeprozess starten.

Anwenden einer Projektion auf die Quelldaten

Zum Projizieren von Raster-Daten stehen zwei grundlegende Workflows zur Verfügung. Sie können die Projektion durch Erstellen einer weiteren Kopie der Quell-Bilddatei oder beim Einfügen der Quell-Bilddatei in die Geodatabase anwenden.

Tests haben ergeben, dass in mehr als der Hälfte der Fälle der beste Workflow darin besteht, die Projektion auf eine Kopie der Quelldatei des Raster-Datasets anzuwenden und die projizierte Raster-Dataset-Quelle in die Geodatabase einzufügen. Wenn Sie die Quelldatei des Raster-Datasets während des Ladens projizieren, erzielen sie möglicherweise einen geringfügig schnelleren Vorgang als beim Erstellen einer projizierten Zwischenversion der Quelldatei. Wenn Sie jedoch zum parallelen Einfügen zahlreicher Raster-Dataset-Quellen mehrere Prozesse verwenden, ist es empfehlenswert, die projizierten Raster-Dataset-Quelldateien auf dem Client bereitzustellen und anschließend auf den Server zu laden, da zum Projizieren der Raster-Daten eine längere Zeit erforderlich ist. Wenn viele Prozesse zum Erstellen projizierter Quelldateien von Raster-Datasets und einige Prozesse zum Einfügen der projizierten Dateien in die Geodatabase vorhanden sind, maximieren Sie letztlich die Ressourcen von Client- und Servercomputern, anstatt einen Server mit geringer Auslastung zu betreiben, auf dem kurze Aktivitätszeiten gelegentlich zu einer Überlastung der Serverressourcen führen können.

Erstellen des Raster-Objekts und Laden der Raster-Daten

Wenn Sie nicht lediglich mehrere eigenständige Raster-Datasets speichern, wird empfohlen, einen Raster-Katalog oder ein Raster-Dataset zu erstellen, der bzw. das die zu ladenden Raster-Datasets aufnimmt. Sie müssen sich jedoch stets der Eigenschaften des zu ladenden Raster-Datasets sowie der Eigenschaften nach dem Laden bewusst sein.

Diese Eigenschaften haben Sie möglicherweise ermittelt, als Sie den Speicherplatzbedarf geschätzt oder den Speicherplatz zugewiesen haben. Zudem haben Sie möglicherweise die Datei "dbtune" bearbeitet, um ein Schlüsselwort zu erstellen, mit dem alle Speicherparameter angegeben werden. Anderenfalls müssen Sie diese Eigenschaften jetzt ermitteln.

Informationen zu Eigenschaften von Raster-Datasets

Vier Raster-Geodatabase-Einstellungen müssen in Betracht gezogen werden: Pyramiden, Raster-Statistiken, Komprimierung und Kachelgröße.

Die Pyramidenerstellung beeinflusst die Darstellungs-Performance.

Weitere Informationen zu Raster-Pyramiden

Pyramiden können für ein Raster-Dataset erstellt werden, da Raster-Daten in das Raster-Dataset mosaikiert werden. Sie können auch erstellt werden, wenn der Ladevorgang abgeschlossen ist. Das Erstellen der Pyramiden nach Abschluss der Mosaikierung ist die schnellste Methode. ArcGIS ermöglicht das partielle Erstellen von Pyramiden, wobei nur der Teil der Pyramide erstellt wird, der während eines Mosaikierungsvorgangs von den Quelldaten überlappt wird. Dies erleichtert das Aktualisieren eines mosaikierten Raster-Datasets, da beim Hinzufügen eines neuen Raster-Datasets keine Pyramide für das gesamte Raster-Dataset neu erstellt werden muss. Wenn Sie die Daten jedoch am Ursprung des Raster-Datasets aktualisieren (Pyramiden-Referenzpunkt), muss die Pyramide für das gesamte Raster-Dataset neu erstellt werden.

Der Ursprung des Raster-Datasets liegt in der Koordinate des Raster-Datasets, die sich ganz links oben befindet. Das Erstellen der Pyramide beginnt bei dieser Koordinate und verläuft dann nach rechts und unten. Für das Mosaikieren von Daten links vom oder über dem Ursprung des Raster-Datasets muss dieser Punkt von ArcSDE so verschoben werden, dass er als Koordinate ganz links oben erhalten bleibt. Für das Verschieben des bisherigen Ursprungs des Raster-Datasets muss ArcSDE die Pyramide neu erstellen. Das erneute Erstellen der Pyramide kann einen aufwändigen Vorgang darstellen, insbesondere, wenn das Raster-Dataset aufgrund der Anzahl von Raster-Dataset-Quelldateien (oder anderer Raster-Datasets) angewachsen ist, die bereits darin mosaikiert wurden.

Da das erneute Erstellen der Pyramide einen zeitaufwändigen Vorgang darstellt, sollten Sie die linke obere Raster-Koordinate des Raster-Datasets durch eine Analyse der Quelldaten identifizieren und diese beim Erstellen des Raster-Datasets eingeben. ArcSDE ermöglicht das Festlegen eines Pyramiden-Referenzpunktes, wenn das Raster-Objekt erstellt wird, so müssen Sie nicht die linke obere Koordinate des ersten eingefügten Raster-Datasets verwenden. Daher können Sie das Verschieben des Ursprungs des Raster-Datasets vermeiden, indem Sie beim Erstellen des Raster-Datasets einen Pyramiden-Referenzpunkt festlegen.

Statistiken sind für Raster-Datasets notwendig, wenn bestimmte Geoverarbeitungsvorgänge oder Tasks in ArcMap oder ArcCatalog durchgeführt werden sollen, wie z. B. das Anwenden einer Kontraststreckung oder die Klassifizierung von Daten.

Weitere Informationen zu Raster-Statistiken

Die Komprimierung wird durch den Typ der Raster-Daten sowie die geplante Verwendung bestimmt.

Weitere Informationen zur Raster-Komprimierung

In ArcSDE können Raster-Datasets beim Speichern in mehrere Kacheln aufgeteilt werden. Jede Kachel wird in der Raster-Speichertabelle als Binärdaten gespeichert. Wenn es sich um ein Multiband-Raster-Dataset handelt, werden Pixel aus lagegleichen Raster-Blöcken in unterschiedlichen Bändern in eigenen Zeilen in der Tabelle gespeichert.

Das Kacheln der Raster-Datasets führt zu einer verbesserten Leistung. Wenn Sie z. B. an einen kleinen Bereich mit nur vier Kacheln heranzoomen, muss ArcSDE nur vier Zeilen in der Raster-Blocktabelle abrufen. Ohne Aufteilung des Rasters in Kacheln muss ArcSDE das gesamte Raster-Dataset abrufen.

Die Größe der Kacheln bemisst sich nach der Anzahl der Zeilen und Spalten, aus denen die einzelnen Kacheln erstellt werden. Die Kachelgröße von 128 mal 128 entspricht daher eigentlich 128 Pixel mal 128 Pixel. Große Kacheln führen zu umfangreichen BLOB-Feldern bei weniger Zeilen in der Tabelle, und kleinere Kacheln führen zu kleineren BLOB-Feldern bei mehr Zeilen in der Tabelle. Die Kachelgröße ist in der Standardeinstellung auf 128 Pixel mal 128 Pixel festgelegt. Wenn es sich bei den zu ladenden Daten nicht um Dreiband-Farbbilder handelt, können Änderungen der Kachelgröße zu einem anderen Speicherplatzbedarf führen, da die Kacheln möglicherweise besser in die Datenbankblöcke passen. Um die bestmögliche Größe zu ermitteln, müssen Sie Benchmark-Tests mit repräsentativen Rastern durchführen. Im Allgemeinen sind die Komprimierungsraten bei größeren Kacheln höher, wodurch in der Datenbank kleinere Dateien gespeichert werden.

Sie können Raster-Objekte mit einem Geoverarbeitungswerkzeug (zum Beispiel in ArcCatalog), mit sderaster oder mit ArcObjects erstellen. Mit Geoverarbeitungswerkzeugen erstellte Raster-Objekte sind leer: Sie weisen Eigenschaften auf, enthalten jedoch keine Pixeldaten. Zudem sind sie für Geodatabases geeignet. Informationen zum Erstellen eines Raster-Datasets finden Sie unter Erstellen eines Raster-Datasets in einer ArcSDE-Geodatabase. Informationen zum Erstellen eines Raster-Katalogs finden Sie unter Erstellen eines Raster-Katalogs in einer ArcSDE-Geodatabase.

Mit sderaster erstellte Raster-Objekte enthalten stets Pixeldaten. Sie sind für Geodatabases nicht geeignet, enthalten keine Footprint-Spalte, und zum Mosaikieren müssen die World-Files perfekt ausgerichtet sein. Informationen zum Erstellen von Rastern mit ArcObjects finden Sie im Esri Developer Network in den Beispielen unter Code Exchange für Raster-Daten, die Sie ändern und verwenden können. Sie können beispielsweise das Beispiel zum Erstellen eines Geodatabase-Raster-Datasets ("Create Geodatabase Raster Dataset") kopieren und ändern, um ein neues, eigenständiges Raster-Dataset zu erstellen. Die Beispiele zum Mosaikieren von Rastern in einem Verzeichnis und Unterverzeichnis in ein ArcSDE-Raster ("Mosaic Rasters In A Directory and Subdirectories To An ArcSDE Raster") liefern Beispielcode zum Mosaikieren aller Raster-Dataset-Quellen in einem Verzeichnis oder Ordner in ein angegebenes, eigenständiges Raster-Dataset. Ein Raster-Katalog kann anhand des Beispiels zum Erstellen eines Geodatabase-Raster-Katalogs ("Create Geodatabase Raster Catalog") erstellt werden. Sie können dieses Beispiel mit dem Beispiel zum Laden von Raster-Datasets in einem Workspace in einen GDB-Raster-Katalog ("Loading Raster Datasets In A Workspace To A GDB Raster Catalog") kombinieren, mit dem Raster-Dataset-Quelldateien in einen Raster-Katalog eingefügt werden.

Zwar muss zur Verwendung der ArcObjects-Software eine Person an Ihrem Standort den Beispielcode ändern und ausführen können, doch ergeben sich die folgenden Vorteile:

Referenzierung eines Verzeichnisses mit vielen Raster-Dataset-Quelldateien statt Eingabe der einzelnen Raster-Dataset-Quelldateien
Hinzufügen von Steuerungsabläufen zur verbesserten Behandlung von Ausnahmen, z. B. einer beschädigten Quell-Bilddatei.

Zum Laden von Raster-Daten in eine Geodatabase stehen verschiedene Optionen zur Verfügung: "Raster-Datasets importieren" (Geodatabase-Kontextmenü), das Werkzeug "Raster kopieren" (Geoverarbeitungswerkzeuge) und "Daten laden" (Kontextmenü für Datasets in ArcCatalog). Weitere Informationen zum Laden von Raster-Daten in eine Geodatabase finden Sie unter Importieren von Raster-Datasets.

Informationen zum Laden von Raster-Daten mit sderaster finden Sie unter Laden von Rastern in ArcSDE mit sderaster.

Berechnen von Statistiken

Durch Berechnen von Statistiken für DBMS und Raster können die Darstellungs-Performance und das Erscheinungsbild des Rasters verbessert werden.

Sie müssen nicht in jedem Fall DBMS-Statistiken berechnen. Alle unterstützten ArcSDE-DBMS verwenden jedoch die kostenbasierte Optimierung. Für die kostenbasierte Optimierung werden Statistiken verwendet, die zuvor von den DBMS-Objekten erfasst wurden, um den besten Ausführungsplan zu ermitteln. SQL Server erfasst beim Laden der Daten automatisch Statistiken, doch für alle anderen DBMS müssen Sie DBMS-Statistiken zumindest für die Blocktabelle generieren.

Gehen Sie wie folgt vor, um die DBMS-Statistiken in ArcCatalog zu berechnen:

Klicken Sie mit der rechten Maustaste auf das Raster-Objekt, und klicken Sie dann auf 2Analysieren".
Stellen Sie im Dialogfeld "Komponenten analysieren" sicher, dass die Komponente "Raster-Tabelle" aktiviert ist.
Klicken Sie auf "OK".

Sie können Statistiken mit dem Befehl "sdetable update_dbms_stats" generieren, wie im folgenden Beispiel gezeigt:

c:\>sdetable -o update_dbms_stats -t earth -m estimate -u mark -p mark -i 9000

Im folgenden Oracle-Beispiel werden die Statistiken für die Blocktabelle schnell generiert:

SQL> select rastercolumn_id from sde.raster_columns
			where table_name = 'EARTH';

RASTERCOLUMN_ID
-----------------------
                      1

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(NULL, 'SDE)BLK_1; NULL, 1);

Eine Raster-Statistik kann für die Raster-Datasets erstellt und in der ArcSDE AUX-Tabelle gespeichert werden. In der Raster-Statistik werden die minimalen und maximalen Pixelwerte sowie der Mittelwert und die Standardabweichung erfasst. Das Generieren der Raster-Statistik auf der Grundebene der Pyramide kann bei sehr großen Raster-Datasets mit beträchtlichem Zeitaufwand verbunden sein.

Eine Raster-Statistik ist für Daten erforderlich, die statistisch gestreckt werden müssen, bevor die im Raster gefangenen Objekte vom menschlichen Auge erfasst werden können.

Weitere Informationen zur Generierung von Raster-Statistiken finden Sie unter Raster-Dataset-Statistik.

Anzeigen der Raster-Daten

Die Raster-Daten sollten mit der Anwendung angezeigt werden, die für das Projekt verwendet wird, für das das Raster entworfen wurde, z. B. ArcMap, ArcCatalog, ArcGlobe oder ArcScene. Wenn die Pyramide erstellt wurde und die DBMS-Statistiken auf dem neuesten Stand sind, wird das Raster normalerweise schnell angezeigt.

Wenn bis zur Anzeige eine längere Zeit vergeht, liegt dies meist an nicht aktuellen oder nicht vorhandenen DBMS-Statistiken. Das Vorhandensein der DBMS-Statistiken für die Blocktabelle ist besonders wichtig. Im vorherigen Abschnitt Berechnen von Statistiken finden Sie Anweisungen zum Erstellen von DBMS-Statistiken.

Durch die Einführung der partiellen Pyramidenerstellung ist es nun möglich, ein Raster-Dataset während eines umfangreichen Mosaikierungsvorgangs anzuzeigen. Wenn Sie jedoch das Raster-Dataset während des Mosaikierungsvorgangs anzeigen, stellt es kein Problem dar, wenn das Raster-Dataset vorübergehend nicht sichtbar ist und bei geringer Auflösung wieder angezeigt wird. Dieses Verhalten resultiert aus der partiellen Pyramidenerstellung, da die aktualisierten oberen Ebenen der Pyramide gelöscht und neu eingefügt werden.

Laden großer Raster-Datasets in ArcSDE