Wie Sie Ihre Daten organisieren und beim Server registrieren, wirkt sich darauf aus, ob die Daten bei der Veröffentlichung gepackt und auf den Server kopiert werden müssen.
Bevor Sie dieses Thema lesen, ist es wichtig, dass Sie über grundlegende Kenntnisse dazu verfügen, wie ArcGIS Server Daten speichert und darauf zugreift. Weitere Informationen hierzu finden Sie unter den folgenden Links:
- Bereitstellen der Daten für ArcGIS Server
- Automatisches Kopieren von Daten auf den Server beim Veröffentlichen
Wie Sie bereits wissen, können Raster-Datasets und Mosaik-Datasets viele verschiedene Dateien umfassen. Dieses Thema soll Ihnen bei der Organisation dieser Daten helfen, damit Sie bei der Veröffentlichung die gewünschten Ergebnisse erzielen.
Ein wichtiger Punkt, den es zu beachten gilt, ist der Folgende: Wenn der Pfad zu den Daten im Datenspeicher registriert ist, nimmt ArcGIS Server an, dass sich alle Daten dort befinden. Dies stellt in der Regel kein Problem dar, wenn der registrierte Speicherort für den Server freigegeben ist, kann jedoch zu Schwierigkeiten führen, wenn der Speicherort doppelt vorhanden ist. In diesem Fall sollten Sie sicherstellen, dass Sie nicht nur an einem Speicherort Änderungen vorgenommen haben. Beispiel: Wenn Sie Pyramiden für ein Raster-Dataset am lokalen Speicherort berechnen, diese jedoch nicht an den duplizierten Speicherort auf dem Server kopieren, werden die Pyramiden beim Veröffentlichungsvorgang nicht kopiert, da der Server annimmt, dass alle Datendateien dupliziert werden. Bei Mosaik-Datasets ist die Sachlage etwas komplizierter, da mehr Dateien beteiligt sind.
Ein komplizierender Umstand ist der Speicherort der Quelldaten für das Mosaik-Dataset. Nehmen wir der Einfachheit halber an, dass es sich bei den Quelldaten um eine Sammlung von Raster-Datasets handelt – einschließlich Pyramiden-, Statistik- und Metadatendateien. Alle diese Daten können sich an einem Speicherort befinden, auf den das Mosaik-Dataset Lesezugriff hat.
Der nächste Komplexitätsfaktor ist das Mosaik-Dataset. Nehmen wir zur Verdeutlichung an, dass es in einer File-Geodatabase gespeichert ist. Wenn Sie Übersichten erstellen, werden diese in einem Ordner neben der Geodatabase gespeichert. Dieser Ordner hat den gleichen Namen wie die Geodatabase mit der Erweiterung .Overviews. Wenn Sie LIDAR-Daten hinzugefügt oder einen Cache für ein Raster-Element generiert haben, ist neben der Geodatabase ein weiterer Ordner mit demselben Namen wie die Geodatabase und der Dateierweiterung .Cache gespeichert. Die Speicherorte für Übersichten und Caches werden standardmäßig neben der Geodatabase gespeichert, Sie können diese jedoch wahlweise an einem anderen Ort speichern – wodurch sich die Komplexität der Datenorganisation weiter erhöht.
Beim Veröffentlichen sollten Sie sicherstellen, dass der Server Zugriff auf alle Inhalte hat, die vom Mosaik-Dataset verwaltet werden. Daher müssen Sie den Datenspeicher festlegen und das Mosaik-Dataset ordnungsgemäß vorbereiten. In jedem der folgenden Szenarien wird diese Problematik speziell für die Verwendung von Mosaik-Datasets näher erläutert, da ein Mosaik-Dataset Daten referenziert, die sich an einem anderen Ort befinden können (solange sie gelesen werden können).
Szenario 1: Alle Daten befinden sich an einem freigegebenen Speicherort
Hierbei handelt es sich wahrscheinlich um die beste Datenorganisationsstruktur. In diesem Szenario werden alle Daten an einem Speicherort gespeichert, der für Sie und den Server freigegeben ist. Sie müssen diesen Speicherort beim Server registrieren und im Katalogfenster (oder ArcCatalog) eine Verbindung zu diesem Speicherort herstellen, um die Daten an diesem Speicherort als Image-Service freizugeben. Dies stellt auch eine schnelle Veröffentlichungsmethode dar, da keine Daten verschoben werden.
Szenario 2: Alle Daten sind doppelt vorhanden
In diesem Szenario werden die Daten an zwei Speicherorten gespeichert: an einem Speicherort, auf den der Server zugreift, und an einem Speicherort, zu dem Sie im Katalogfenster eine Verbindung herstellen. Dieses Setup wird häufig verwendet, wenn sich der Server in einer Cloud oder auf einem Linux-Betriebssystem befindet.
Sie müssen sicherstellen, dass die Daten vollkommen identisch sind. Wenn Sie beispielsweise das Mosaik-Dataset ändern, indem Sie ein neues Bild hinzufügen oder die Footprints ändern, müssen Sie sicherstellen, dass die Kopie aktualisiert wird, auf die der Server zugreift. Zudem müssen Sie sicherstellen, dass die Pfade zu den Daten entsprechend geändert werden. Ein Mosaik-Dataset enthält hartcodierte Pfade zu allen seinen Inhalten. Wenn der Speicherort für Ihre Inhalte D:\MyData und für die Daten auf dem Server \\Blue\ServerData ist, müssen Sie sicherstellen, dass die Pfade im Mosaik-Dataset für den Speicherort \\Blue\ServerData aktualisiert werden. Sie können diese Pfade aktualisieren, bevor oder nachdem das Mosaik-Dataset (und die zugehörigen Dateien) am Serverspeicherort dupliziert werden. Weitere Informationen finden Sie unter Reparieren der Pfade in einem Mosaik-Dataset.
Stellen Sie vor der Veröffentlichung sicher, dass Sie den lokalen Speicherort und den Serverspeicherort als doppelt vorhandene Speicherorte registrieren und dass die Daten dupliziert werden und die Pfade korrekt sind. Dann können Sie das Mosaik-Dataset veröffentlichen, indem Sie auf den Speicherort auf dem lokalen Computer verweisen. Dem Server ist bekannt, dass der Speicherort doppelt vorhanden ist, und er verschiebt daher keine Daten. Wie beim Szenario 1 bewirkt dies ebenfalls eine schnelle Veröffentlichung.
Szenario 3: Es ist kein registrierter Datenspeicherort vorhanden
Wie das Szenario 1 ist dies ebenfalls ein unkompliziertes Szenario, da Sie sich keine Gedanken darüber machen müssen, wo sich Ihre Daten befinden und ob der Server darauf zugreifen kann oder ob die Daten die korrekte Version aufweisen. In diesem Szenario werden alle Daten gepackt und auf den Server verschoben, wenn sie veröffentlicht werden. Dies funktioniert für kleine Sammlungen von Daten hervorragend, wird jedoch aufgrund der Zeit, die das Packen und Verschieben der Daten in Anspruch nehmen kann, nicht für mittelgroße bis große Sammlungen empfohlen. Sie können sich für diese Option entscheiden, wenn Sie keinen Zugriff auf den vom Server verwendeten Speicherort haben oder Sie ein kleines Raster-Dataset veröffentlichen. Es ist jedoch nicht effizient, Daten im Gigabytebereich oder noch größere Datenmengen auf diese Weise zu verschieben.
Szenario 4: Nur die Quelldaten befinden sich an einem registrierten Speicherort
In diesem Szenario stimmt der Speicherort der Quelldaten nicht mit dem Speicherort des Mosaik-Datasets überein. Der Speicherort der Quelldaten kann freigegeben oder dupliziert sein.
Beispiel 1: Freigegebene Quelldaten
Der Speicherort der Quelldaten ist unter \\yellow\RasterData freigegeben. Sie erstellen auf dem lokalen Computer ein Mosaik-Dataset und fügen die Daten aus \\yellow\RasterData hinzu. Wenn Sie dann das Mosaik-Dataset veröffentlichen, werden bei dem Vorgang das Mosaik-Dataset und die zugehörigen Dateien (z. B. der Inhalt des Ordners *.Overviews) gepackt und auf den Server verschoben und die hartcodierten Dateipfade aktualisiert (bzw. es wird sichergestellt, dass die relativen Speicherorte gleich bleiben). Dieser Vorgang kann viel Zeit in Anspruch nehmen, wenn zahlreiche Übersichten vorhanden sind.
Beispiel 2: Duplizierte Quelldaten
Die Quelldaten sind doppelt vorhanden – auf dem Server befinden sie sich unter P:\SourceData\RasterData und auf dem lokalen Computer unter D:\RasterData.
Bei diesem Beispiel müssen Sie sicherstellen, dass das Mosaik-Dataset nicht in D:\RasterData erstellt wird, da der Server annimmt, dass diese beiden Speicherorte doppelt vorhanden sind und bei der Veröffentlichung nicht prüft, ob sich das Mosaik-Dataset unter P:\SourcData\RasterData befindet.
Erstellen Sie das Mosaik-Dataset an einem eindeutigen Speicherort wie D:\Collections. Wenn Sie dann das Mosaik-Dataset veröffentlichen, werden bei dem Vorgang das Mosaik-Dataset und die zugehörigen Dateien (z. B. der Inhalt des Ordners *.Overviews) gepackt und auf den Server verschoben und die hartcodierten Dateipfade aktualisiert (bzw. es wird sichergestellt, dass die relativen Speicherorte gleich bleiben).