Wie verwendet ArcSDE Oracle Spatial?

ArcSDE unterstützt Oracle Spatial oder Oracle Locator zum Speichern und Verwalten von Geometrie in einer Oracle-Datenbank. Um es zu verwenden, müssen Sie SDO_GEOMETRY für den Parameter GEOMETRY_STORAGE von einem der Konfigurationsschlüsselwörter angeben. Wenn Sie die meiste Zeit Oracle Spatial-Geometriespeicherung verwenden möchten, geben Sie SDO_GEOMETRY für den Parameter GEOMETRY_STORAGE im Konfigurationsschlüsselwort DEFAULTS an. Wenn Sie es für nur einige Datasets verwenden möchten, verwenden Sie das Schlüsselwort SDO_GEOMETRY, wenn Sie jedes einzelne Dataset erstellen.

Verwenden von Oracle Spatial in ArcGIS

Wenn Sie die ArcSDE-Komponente erstmals installieren, ist ST_Geometry der Standard-Geometriespeichertyp. Die Standardeinstellungen für die ArcSDE-Speicherung werden in der DBTUNE-Tabelle durch die GEOMETRY_STORAGE-Parameter definiert.

Wenn Sie nur einige der Feature-Classes mit dem Oracle Spatial-Typ speichern möchten, können Sie beim Erstellen der Feature-Class das Schlüsselwort SDO_GEOMETRY angeben. Wenn Sie dies tun, wird die jeweilige Feature-Class mit einer SDO_GEOMETRY-Spalte erstellt. In der dbtune-Datei wird das Schlüsselwort SDO_GEOMETRY wie folgt angezeigt:

##SDO_GEOMETRY
GEOMETRY_STORAGE    "SDO_GEOMETRY"
ATTRIBUTE_BINARY    "BLOB"
RASTER_STORAGE	    "SDO_GEORASTER"
SDO_COMMIT_INTERVAL  1000
UI_TEXT          "User Interface text description for SDO_GEOMETRY"

COMMENT        "Any general comment for SDO_GEOMETRY keyword"

END

Wenn Sie planen, den Speichertyp SDO_Geometry für die meisten der Feature-Classes zu verwenden, können Sie den Standard-ArcSDE-Geometriespeicher ändern, um den Oracle Spatial-Typ zu verwenden.

Um einen anderen Standard-Geometriespeicher anzugeben, verwenden Sie den administrativen sdedbtune-Befehl, um das DBTUNE-Schlüsselwort DEFAULTS zu ändern, und ändern den Parameter GEOMETRY_STORAGE von ST_GEOMETRY in SDO_GEOMETRY. Nachdem die Standardeinstellung für GEOMETRY_STORAGE in SDO_GEOMETRY geändert wurde, erstellt ArcSDE Feature-Classes standardmäßig mit SDO_GEOMETRY-Spalten.

HinweisHinweis:

Weitere Informationen zur Verwendung von "sdedbtune" finden Sie in der ArcSDE Administration Command Reference, die zusammen mit der ArcSDE-Komponente von ArcGIS Server Enterprise installiert wurde.

ArcSDE for Oracle unterstützt eine Reihe von anderen Geometriespeicherschemas – diese anderen Schemas können alle zusammen in der gleichen Datenbank verwendet werden. Während es nur ein Standard-Geometrieschema geben kann, können einzelne Tabellen mit verschiedenen Geometrieschemas erstellt werden.

Voraussetzungen zum Verwenden von vorhandenen Oracle Spatial-Tabellen mit ArcSDE

ArcSDE kann Tabellen, die SDO_GEOMETRY-Spalten enthalten, die extern von anderen Anwendungen erstellt wurden oder SQL verwenden (manchmal als Tabellen von Drittanbietern bezeichnet) erfolgreich verwenden, solange die Tabellen bestimmte Voraussetzungen erfüllen:

Interoperabilitätsüberlegungen

Eine allgemeine falsche Auffassung ist, dass Anwendungen einfach zusammenwirken können, da sie den gleichen zugrunde liegenden Geometrietyp unterstützen. Der Geometrietyp ist jedoch nur ein Aspekt der Geodatabase sowie anderer GIS-Datenbankschemas. Das allgemeine Verständnis von Regeln, Einschränkungen, Schema und Implementierung ist ebenfalls erforderlich. Einige Dinge, die Sie beachten sollten, wenn Sie Oracle Spatial mit ArcSDE und ArcSDE-Clients verwenden, sind Folgende:

ArcSDE und ArcGIS unterstützen nicht mehrere Geometriespalten in einer Tabelle.

Auf Tabellen mit mehreren SDO_GEOMETRY-Spalten sollte über Sichten zugegriffen werden, die nur eine SDO_GEOMETRY-Spalte enthalten.

Um Daten in einer Oracle Spatial-Tabelle zu verwenden, die mehrere räumliche Spalten enthält, erstellen Sie mit SQL eine räumliche Sicht. Diese Sicht sollte nur eine räumliche Spalte enthalten. Registrieren Sie danach die räumliche Sicht mit "sdelayer –o register" bei ArcSDE.

Informationen dazu, wie Sie eine Sicht, die nur eine SDO_GEOMETRY-Spalte enthält, erstellen und registrieren, finden Sie im Knowledge Base-Artikel Create an Oracle view of an Oracle Spatial layer (containing multiple geometry columns) and register it with ArcSDE.

ArcSDE und ArcGIS unterstützen nur einen einzelnen Geometrietyp in einer SDO_GEOMETRY-Spalte.

Wenn eine einzelne SDO_GEOMETRY-Spalte in einer Tabelle mehrere Geometrietypen enthält (einige Datensätze sind z. B. Punkte und einige sind Polygone), kann die Tabelle nicht bei ArcSDE oder der Geodatabase registriert werden; die Feature-Class muss mit einem enthaltenen Geometrietyp registriert werden.

Oracle Spatial setzt nicht notwendigerweise Geometrietypeinschränkungen für eine SDO_GEOMETRY-Spalte durch. Ohne diese Umsetzung könnte eine Anwendung versuchen, eine einzelne Geometrietypeinschränkung aufrechtzuerhalten, aber eine andere Anwendung andere Geometrietypen einfügen. Ab Oracle9-i haben Sie die Option, bei Einfügungen in eine Tabelle mit einem räumlichen Indexerstellungsparameter den Geometrietyp einzuschränken. In früheren Oracle-Versionen ist eine andere Option, um Geometrietypeinschränkungen durchzusetzen, das Erstellen eines Triggers für Einfügungen und Aktualisierungen, der die SDO_GEOMETRY GTYPE-Eigenschaft überprüft.

Die Geometrieüberprüfung ist zwischen ArcSDE und SDO_GEOMETRY nicht identisch.

ArcSDE überprüft die Geometrie, wenn Geometrien eingefügt oder aktualisiert werden. In Oracle 10g erzwingt Oracle Spatial nicht automatisch eine Geometrieüberprüfung bei Einfügung oder Aktualisierung eines SDO_GEOMETRY-Werts, wenn Sie Geometrien mit anderen Methoden als ArcSDE-Clients, z. B. SQL, einfügen oder aktualisieren. In Oracle 11g validiert Oracle Spatial Geometrien bei Indexeinfügungen.

Probleme würden auftreten, wenn ungültige oder falsch gebildete Geometriewerte an ArcSDE-Client-Anwendungen übergeben werden. Um das Auftreten dieser potenziellen Probleme zu reduzieren, sollten Sie alle Geometrien überprüfen, die von einer anderen Methode als einer ArcSDE-Client-Anwendung erstellt oder geändert wurden.

Ältere VersionenÄltere Versionen:

In ArcSDE 9.1 werden SDO_GEOMETRY-Features nicht überprüft, wenn sie von der Datenbank abgerufen werden. Diese Änderung wurde vorgenommen, um die Abruf-Performance zu verbessern.

Ab ArcSDE 9.2 werden Shapes überprüft, wenn sie abgerufen werden, aber nur, wenn die räumliche Tabelle außerhalb von ArcSDE erstellt wurde und dann bei ArcSDE registriert wird. Wenn der Layer mit ArcGIS oder der ArcSDE-API erstellt wurde, werden die Shapes beim Abrufen nicht überprüft.

Für das Überprüfen von Geometrie sind zwei Werkzeuge verfügbar. Mit VALIDATE_GEOMETRY_WITH_CONTEXT von Oracle werden Geometrien mit den Shape-Validierungsregeln von Oracle überprüft, und "sdelayer –o feature_info" überprüft sie mit ArcSDE-Regeln. Der feature_info-Vorgang schließt als Teil seiner Ausgabe optional Informationen darüber ein, ob die Geometrie eines Shapes für ArcSDE gültig ist. Ausführliche Informationen zur Verwendung dieses Vorgangs finden Sie in der mit ArcSDE installierten ArcSDE Administration Command Reference.

Die ArcSDE-Geometrieüberprüfung ist nicht identisch mit der Oracle Spatial-Geometrieüberprüfung. Obwohl es wichtig ist, dass Geometrien Oracle Spatial-Validierung übergeben, garantiert eine erfolgreiche Überprüfung der Geometrien mit den Validierungsroutinen von Oracle nicht, dass die Geometrien von ArcSDE validiert werden.

Sie können einen Trigger für Einfügungen und Aktualisierungen erstellen, um die Funktion SDO_VALIDATE auszulösen, die die Überprüfung von SDO_GEOMETRY-Typen durchsetzt.

Die ArcSDE-C-API kann verwendet werden, um eine Anwendung zu schreiben, die Features abruft, auch wenn sie die ArcSDE-Shape-Validierung nicht bestehen. Es obliegt dann jedoch der Client-Anwendung, die Eignung der Geometrie oder Korrekturmöglichkeiten zu bestimmen.

Die meisten Anwendungen, die SDO_GEOMETRY-Objekte lesen, wären nicht in der Lage, von anderen Anwendungen erstellte SDO_ETYPE 0-Daten zu interpretieren.

Oracle Spatial ermöglicht es Anwendungen, anwendungsspezifische Daten in ein SDO_GEOMETRY-Objekt einzufügen. Anwendungen machen dies, indem sie ihre Daten unter Verwendung eines SDO_ETYPE-Werts von 0 einbetten. Dies ermöglicht Anwendungen große Flexibilität, um viele Typen von unkonventioneller Geometrie und anderen Daten zu speichern. Die Bedeutung der anwendungsspezifischen Daten ist jedoch nur für die Anwendung wichtig, die das spezielle SDO_GEOMETRY-Objekt generiert hat. Solche anwendungsspezifischen Daten können in einer interoperablen Umgebung nicht zuverlässig unterstützt werden. Anwendungen, die SDO_GEOMETRY-Objekte lesen, wären wahrscheinlich nicht in der Lage, von anderen Anwendungen erstellte SDO_ETYPE 0-Daten zu interpretieren. Anwendungen, die SDO_GEOMETRY-Objekte aktualisieren, könnten die SDO_ETYPE 0-Daten nicht bearbeiten oder beibehalten.

Beim Lesen von SDO_GEOMETRY-Objekten, die SDO_ETYPE 0-Elemente enthalten, ignoriert ArcSDE die SDO_ETYPE 0-Daten und übergibt nur die Simple-Feature-Geometrieelemente, die es unterstützt, an die Anwendung.

Beim Aktualisieren von SDO_GEOMETRY-Objekten, die SDO_ETYPE 0-Elemente enthalten, behält ArcSDE die SDO_ETYPE 0-Daten nicht bei. Daher sollten Anwendungen, die die Beibehaltung von SDO_ETYPE 0-Daten erfordern, verhindern, dass Benutzer UPDATE-Zugriff auf die Tabelle haben.

ArcSDE erfordert, dass alle SDO_GEOMETRY-Werte in einer Spalte das gleiche Koordinatenbezugssystem aufweisen.

Wenn der Koordinatenbezug nicht definiert ist, sollte der SRID-Wert NULL sein, wie im "Oracle Spatial User's Guide and Reference" beschrieben ist.

Vor Oracle9-i setzte Oracle Spatial nicht automatisch bei Einfügung oder Aktualisierung eines SDO_GEOMETRY-Werts eine Raumbezugs-ID-Validierung durch. Um die Validierung von SDO_GEOMETRY-Typen in diesen älteren Oracle-Instanzen zu erzwingen, können Sie einen Trigger für Einfügungen und Aktualisierungen erstellen, um die Funktion SDO_VALIDATE auszulösen. Oracle Spatial erfordert, dass die SRID in jeder Geometrie untereinander und mit der SRID in den räumlichen Metadaten übereinstimmt, auch wenn sie NULL ist.

Oracle Spatial und ArcSDE nehmen beide an, dass die erste und zweite Dimension von SDO_GEOMETRY X und Y sind.

Wenn ein SDO_GEOMETRY-Objekt über drei Dimensionen verfügt, interpretiert ArcSDE die dritte Dimension als Messwert, wenn der Dimensionsname (in den räumlichen Metadaten) mit dem Buchstaben "m" beginnt; andernfalls wird die dritte Dimension als Höhe angenommen. Sie können steuern, wie ArcSDE die dritte Dimension interpretiert, indem Sie mit dem Entitäts-Flag der Feature-Class festlegen, ob es sich um Höhen oder Messwerte handelt.

Oracle9-i Release 2 erweiterte das SDO_GTYPE-Element des Typs SDO_GEOMETRY, um die Kodierung, welche Dimension eine Messwertordinate enthält, zu ermöglichen. Die zweite Ziffer des vierstelligen SDO_GTYPE kann 0, 3 oder 4 sein. Wenn sie 3 oder 4 ist, gibt dies an, welche Dimension die Messwertordinate enthält. ArcSDE 9 und höhere Versionen lesen diese Kodierung. Andernfalls, wenn das SDO_GEOMETRY-Objekt über vier Dimensionen verfügt, wird der Messwert als letzter Ordinatenwert interpretiert.

In diesem Beispiel legt "sdelayer" den Entitätstyp einer Feature-Class fest, um Linestrings und Höhen zu speichern:

sdelayer –o add –e l3

In diesem Beispiel legt "sdelayer" den Entitätstyp einer Feature-Class fest, um Linestrings und Messwerte zu speichern:

sdelayer –o add –e lM 

Oracle Spatial (jedoch nicht Oracle Locator) stellt unter Verwendung von Messwerten Funktionen für die Berechnungen des linearen Bezugssystems (LRS) bereit.

Die Oracle Spatial LRS-Funktionen erfordern, dass alle Messwerte in einer Geometrie ohne NaN-Werte monoton aufsteigen oder absteigen. Oracle Spatial LRS schränkt auch Messwerte zu Linestrings ein.

ArcSDE ermöglicht Messwert- und LRS-Berechnungen für alle geometrischen Typen, mit Unterstützung von willkürlich geordneten Messwerten und NaN-Werten.

Wenn Sie beabsichtigen, Oracle Spatial LRS-Funktionen zu verwenden, vergewissern Sie sich, dass Sie die Anwendung und die Datenbank innerhalb der Oracle Spatial LRS-Einschränkungen entwerfen.

ArcSDE benötigt eine eindeutige Feature-Kennung in der räumlichen Tabelle, um räumliche Abfragen, Abfragen der Protokolldateien, Operationen für einzelne Zeilen und in Datenbanken mit mehreren Versionen durchzuführen.

Mit dem komprimierten ArcSDE-Binärschema kann die Geometriespalte diesem Zweck dienen, da sie ein Fremdschlüssel für die Feature-Tabelle ist und als eindeutiger Nicht-NULL-Ganzzahlwert definiert wird. SDO_GEOMETRY schließt keinen eindeutigen identifizierenden Wert ein, wenn also ArcSDE die Spalte SDO_GEOMETRY einer vorhandenen Tabelle hinzufügt, kann es auch eine eindeutige identifizierende Spalte hinzufügen. So eine Spalte ist die registrierte Zeilen-ID-Spalte. Diese Spalte hat oftmals den Namen OBJECTID, kann jedoch auch anders benannt werden. Oder eine vorhandene Spalte kann für die registrierte Zeilen-ID-Spalte verwendet werden, solange sie indiziert ist und eine Ganzzahl, UNIQUE und NOT NULL ist. Registrierte, von ArcSDE verwaltete Zeilen-ID-Spalten müssen NUMBER (38) UNIQUE NOT NULL sein.

Eine registrierte Zeilen-ID-Spalte kann mit dem administrativen sdetable-Befehl oder der ArcCatalog-Anwendung hinzugefügt werden. Für viele Anwendungen, z. B. ArcGIS, ist eine registrierte Zeilen-ID-Spalte in jeder Tabelle oder jeder Feature-Class erforderlich. Jede Anwendung hat eigene Anforderungen und Einschränkungen.

Änderungen von Oracle Spatial-Feature-Classes, die an Netzwerken, Topologien, Beziehungen oder Einschränkungen beteiligt sind, sollten auf ArcGIS-Anwendungen eingeschränkt werden.

ArcGIS kann Netzwerke und integrierte topologische Feature-Classes von Simple-Feature-Classes erstellen und beibehalten, die den Typ SDO_GEOMETRY verwenden. ArcGIS erzwingt Beziehungen und Einschränkungen in vielen verschiedenen Datenquellen. ArcGIS verwaltet die Beziehungen und behält die topologische Integrität der Daten bei; Änderungen an den zugrunde liegenden Features durch ArcGIS werden in diesen integrierten Netzwerken, Topologien und Beziehungen reflektiert.

Änderungen von Oracle Spatial-Feature-Classes, die an Netzwerken, Topologien, Beziehungen und Einschränkungen beteiligt sind, sollten auf ArcGIS-Anwendungen beschränkt werden. Andere Anwendungen können die Daten frei lesen, aber ihre Bearbeitungen werden nicht ordnungsgemäß in der Geodatabase reflektiert.

Verwandte Themen


3/6/2012