Más

No se puede seleccionar geometría de Oracle DB usando SQL


Estoy tratando de seleccionar el campo de geometría de una clase de entidad de ArcSDE en una base de datos de Oracle 11g (dentro de un script de Python a través de PyODBC). Esta es mi consulta:

SELECCIONAR FORMA DE USR.FEAT_CLASS

Esto me esta dando errorORA-24359: OCIDefineObject no invocado para un tipo de objeto o referenciay obtengo lo mismo para cualquier otra clase de entidad. Si selecciono otro campo que no es de geometría, la consulta funciona bien, así que sé que no es un problema con el script o la cadena de conexión. ¿Alquien más se ha encontrado con este problema?

ACTUALIZAR: Tengo ArcGIS 9.3.1 instalado localmente pero no lo estoy usando aquí, así que no creo que eso esté jugando un papel. No estoy seguro de qué versión de ArcSDE está instalada ya que no tengo acceso regular al servidor, pero creo que también es la 9.3.1. La secuencia de comandos de Python utiliza PyODBC para comunicarse directamente con el servidor de Oracle.


El hecho de que Oracle admita la creación de objetos personalizados en la base de datos no significa que todos los clientes podrán leer sus valores. En este caso, su cliente PyODBC no sabe cómo desempaquetar el tipo de columna SDE.ST_GEOMETRY, por lo que no le ha dicho a Oracle cómo manejará la geometría, y Oracle está generando el error diciendo que no se le ha dicho cómo pasar. ST_GEOMETRY al controlador PyODBC.

Hay varias opciones abiertas para ti. Lo más fácil es solicitar algo que el cliente ODBC debería poder manejar, como una columna CLOB o BLOB:

SELECCIONE sde.ST_AsText (forma) DE usr.feat_class

-o-

SELECCIONE sde.ST_AsBinary (forma) DE usr.feat_class

ArcGIS 9.3.1 es lo suficientemente antiguo como para dejar de recibir soporte (estado de soporte "Retirado", a partir de enero de 2014). Es muy posible que se encuentre con errores en la implementación de SDE.ST_GEOMETRY que se han solucionado desde la instalación. Como mínimo, debe asegurarse de que el paquete de servicio de terminal (SP2) y varios parches posteriores al SP2 se hayan aplicado a la instalación del escritorio local, a los archivos binarios del servidor de aplicaciones (si están presentes) y a las bibliotecas de soporte del oyente que permiten Consultas espaciales SQL * Plus utilizando SDE.ST_GEOMETRY.


ARCGIS - ST_GEOMETRY de ORACLE a SQL Server

Tengo una geodatabase ESRI almacenada en un sistema Oracle. Aquí es donde se generan los datos y se considera el sistema de origen. Necesito poder ejecutar un trabajo que extraiga e importe los datos en una base de datos de SQL Server (también aprovechando ESRI sde). Sé que tendré un problema para llevar el tipo ST_Geometry a SQL Server, pero no he podido encontrar ninguna documentación sobre todo lo necesario para realizar con éxito estas tareas. Por ejemplo, ¿de qué forma debo extraer los datos de Oracle? Y lo que se requiere para importar la función. Tengo entendido que la nueva fila debe registrarse de diversas formas.

El tipo de datos para Oracle Shape: [SDE.ST_GEOMETRY]

Tipo de datos en SQL Server: [geometría]

He podido convertir con éxito ST_Geometry de Oracle a un formato de texto bien conocido varchar. Hice esto usando sde.ST_ASText (). Esto requirió la configuración de procesos externos en Oracle.

Mi declaración de selección se ve de la siguiente manera:

SELECCIONE COL1, COL2, COL3, sde.ST_ASTEXT (SHAPE) COMO FORMA DE LA TABLA

Ahora el problema que tengo es convertir esto en un tipo de GEOMETRÍA DE SERVIDOR SQL. Estoy usando un procedimiento almacenado que me gustaría recorrer las columnas, agregar a una instrucción de selección y aplicar la función STGeomFromText () que se incluye en SQL SERVER.


Pensamiento vishful & # 8230

Hemos intentado optimizar la forma en que almacenamos y procesamos datos espaciales en Oracle. Normalmente, crearíamos nuestras tablas espaciales como FeatureClasses de ArcCatalog y crearíamos tablas antiguas simples de Oracle para nuestros datos de negocios / atributos que se unirían con los datos espaciales en las FeatureClasses a través de un campo clave compartido para crear una vista espacial SDE. Esto funciona bien, pero hay algunos inconvenientes en este enfoque.

  • SDE crea campos innecesarios en la tabla FeatureClass en Oracle, como la anotación de cad de campo que simplemente no necesita estar allí.
  • Crear FeatureClasses manualmente desde ArcCatalog es un proceso que no se puede automatizar como parte del proceso de construcción. Idealmente, nos gusta ejecutar un comando de nuestros scripts de compilación que borrará todo nuestro modelo de la base de datos y ejecutará otro comando para recrear todo el modelo para comenzar con una pizarra limpia para probar cada compilación. Estos scripts también se utilizarán durante el proceso de implementación cuando la base de datos deba volver a crearse en otro entorno.
  • FeatureClasses deberá editarse a través de ArcObjects (versionado / no versionado) o ArcMap (versionado) que necesitaría una licencia ESRI en cualquier máquina cliente que desee editar los datos espaciales. En un entorno web, esto significaría una licencia ESRI en el servidor web.

Queríamos que nuestra configuración intentara solucionar algunos de los inconvenientes anteriores. Entonces, escribimos scripts SQL que

  1. Crea la tabla espacial
  2. Inserte metadatos sobre la tabla espacial en la tabla de metadatos de geometría de Oracle USER_SDO_GEOM_METADATA
  3. Crea un índice espacial en la mesa
  4. Registre la tabla espacial de Oracle con ArcSDE como FeatureClass utilizando el comando & # 8216sdelayer -0 register & # 8217

Aquí hay algunos scripts SQL de muestra para realizar los primeros tres pasos con Oracle

El comando sde de muestra para registrar la tabla como una FeatureClass de varios polígonos con ArcSDE especificando los límites

sdelayer -o registro -l CLIENTES, CUST_GEO_LOCATION -e a + M -C CLIENTE_ID -i sde: oracle11g -s SERVER_NAME -u XXX -p YYY @ orcl -t SDO_GEOMETRY -P Alto -x -180, -90,11132000

Como puede ver en los comandos de arriba, la tabla espacial está registrada con Oracle para tener un SRID (id de referencia espacial) de 8307 que denota los sistemas de coordenadas geográficas WGS 84. Oracle mantiene su propia tabla CS_SRS donde mantiene una lista de sistemas de referencia espacial compatibles con Oracle. Se espera que el SRID especificado al agregar los metadatos de geometría con Oracle esté presente en la tabla CS_SRS; de lo contrario, Oracle insertará los metadatos en sus tablas. Los límites especificados al registrar la tabla espacial como FeatureClass con ArcSDE también reflejan el WGS 84 GCS.

Hasta ahora tan bueno. La solución anterior funciona a las mil maravillas. Ahora que los mapas base de ArcGIS Online se han trasladado al sistema de proyección Web Mercator utilizado por Google y Bing, también queríamos mantener nuestros datos en Web Mercator para que el servidor GIS no tenga que reproyectar los datos al renderizar mapas y también así que podríamos ofrecer datos espaciales como GeoJSON / ArcJSON desde nuestros servicios web personalizados para que los consuman los clientes web. Aquí es donde comenzaron los problemas. Oracle no tiene un SRID para el sistema de proyección web mercator. Revisamos la tabla CS_SRS para verificar que se mantuviera con una identificación diferente pero sin suerte. Hasta donde yo sé, el proceso de registrar un nuevo SRID con Oracle no está documentado en ninguna parte. Aparentemente, no es tan simple como agregar una entrada en la tabla CS_SRS que intentamos sin éxito.

Entonces, para solucionar este problema, registramos nuestra tabla espacial con la tabla de metadatos de geometría de Oracle sin un SRID. Entonces, Oracle piensa que el SRID para la tabla espacial es NULL. Esto se convierte en un problema cuando intentamos insertar geometrías con ESRI & # 8217s SRID 102113 en la tabla espacial. Oracle no nos permite insertar geometrías en la tabla espacial cuyo valor no sea NULL para que coincida con la entrada en sus tablas de metadatos de geometría. Entonces, nos vemos obligados a insertar geometrías con un SRID NULL en la tabla. Pero ArcSDE necesita saber que la tabla espacial está en el sistema de proyección de Web Mercator. Para hacer esto, registramos la tabla espacial usando el & # 8216sdelayer -o registro & # 8217 especificando el archivo de proyección & # 8220WGS 1984 Web Mercator (Auxiliary Sphere) .prj & # 8221 de ESRI. Vea la muestra a continuación

sdelayer -o registrar -l CLIENTES, UBICACIÓN_GEO_CUST -e a + M -C ID_ CLIENTE -i sde: oracle11g -s NOMBRE_SERVICIO -u XXX -p YYY @ orcl -t SDO_GEOMETRY -P Alto -G archivo = & # 8221C: TEMP WGS 1984 Web Mercator (esfera auxiliar) .prj & # 8221

La declaración de inserción para las tablas de metadatos de geometría de Oracle se ve así

INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO)

VALORES (& # 8216 CLIENTES & # 8217, & # 8216CUST_GEO_LOCATION & # 8217,

SDO_DIM_ARRAY

(SDO_DIM_ELEMENT (& # 8216X & # 8217, -20037700, 20037700, 0.1),

SDO_DIM_ELEMENT (& # 8216Y & # 8217, -20037700, 20037700, 0.1)))

Esto es feo, pero funciona. Pudimos ver y editar los datos en ArcMap sin problemas.

Aquí hay algunas cosas más descubiertas en el camino.

  • Oracle convierte todos los nombres de las tablas y los nombres de los campos en mayúsculas de forma predeterminada, incluso cuando especifica los nombres en minúsculas en las declaraciones SQL. Podemos forzar a Oracle a usar alfabetos en minúsculas en los nombres de la tabla / campo especificando los nombres de la tabla / campo en las declaraciones SQL encerrándolos entre comillas.
  • Si usa la técnica anterior para usar nombres de tabla / campo en minúsculas para las tablas espaciales, no podrá registrar los metadatos de geometría de la tabla con Oracle. Esto se debe a que Oracle espera que el nombre de la tabla espacial / campo esté en mayúsculas para insertarlo en la tabla de metadatos de geometría. Esto es una locura y no puedo imaginar que este requisito sea intencional.
  • La sintaxis SQL espacial de Oracle es fea. Muy feo. Definitivamente pueden aprender de la dulce sintaxis SQL en MS SQL SERVER 2008.
  • La versión gratuita de Oracle llamada Oracle XE admite los tipos de datos espaciales. Es decir, en Oracle XE podemos almacenar columnas cuyo tipo de datos sea MDSYS.SDO_GEOMETRY. Oracle XE también nos permite realizar algunas operaciones espaciales en estas columnas espaciales, pero no todas las operaciones espaciales que están disponibles en la edición empresarial de Oracle. Las características espaciales que están disponibles en la edición XE no están documentadas en ninguna parte que yo sepa. Las extensiones espaciales de Oracle aportan más funciones espaciales a la edición empresarial de Oracle, como compatibilidad con ráster, etc.
  • MDSYS.Oracle ST_GEOMETRY es diferente de ESRI ST_GEOMETRY y es un envoltorio de MDSYS.SDO_GEOMETRY

Si conoce una mejor manera de hacer las cosas con Oracle y SDE para la proyección de mercator web, hágamelo saber, soy todo oídos. Espero que esta publicación le salve a alguna otra pobre alma un poco de dolor y sufrimiento.


Eso debería funcionar. ¿Está seguro de que su base de datos tiene Oracle Spatial u Oracle Locator instalado?

Las bases de datos proporcionadas en AWS normalmente no lo hacen.

Verifique la versión de su base de datos. Para Oracle 12c en adelante, todo el paquete SDO_GEOM está disponible para los usuarios del localizador de Oracle. Por lo tanto, debería funcionar. Sin embargo, en 12c es posible que deba desinstalar la parte espacial como se menciona aquí: https://docs.oracle.com/database/121/SPATL/sdo_locator.htm#SPATL1433

En caso de que esto le suceda a alguien con Oracle espacial o localizador o cualquier cosa necesaria instalada correctamente en MDSYS, y todavía no funciona, puede intentar otorgar privilegios EXECUTE de MDSYS a su usuario mientras leo.


Maestro de geodatos

La siguiente es una información & # 8220general & # 8221 sobre Oracle Spatial para brindarle al lector una breve descripción general y enlaces a recursos de lectura útiles:

1. la diferencia entre Oracle Locator y Oracle Spatial:

Localizador de Oracle: una función de Oracle Database (ediciones Standard y Enterprise), proporciona la funcionalidad de ubicación central que necesitan la mayoría de las aplicaciones de los clientes y las soluciones de los socios. (Locator no es una solución para aplicaciones GIS complejas). Los desarrolladores pueden ampliar las aplicaciones existentes basadas en Oracle, ya que con Locator pueden incorporar fácilmente información de ubicación directamente en sus aplicaciones y servicios. Esto es posible porque los datos de ubicación están completamente integrados en el propio servidor de Oracle. Los datos geográficos y de ubicación se manipulan utilizando la misma semántica aplicada a los tipos CHAR, DATE o INTEGER que son familiares para todos los usuarios de SQL.

Oracle espacial: una opción para Oracle Database Enterprise Edition, aumenta Locator y proporciona una base sólida para aplicaciones GIS complejas que requieren más análisis espacial y procesamiento en Oracle Database. Incluye funciones espaciales (incluidos cálculos de área, zona de influencia, centroide), compatibilidad con sistemas de coordenadas avanzados, sistema de referencia lineal y funciones agregadas. Las nuevas e importantes capacidades de esta versión abordan los desafiantes requisitos críticos para el negocio del sector público, la defensa, la logística, la exploración de energía y los dominios de geografía empresarial.

2. para comprobar si el componente espacial de Oracle está & # 8220 instalado & # 8221 y & # 8220 válido & # 8221 en su base de datos, utilice la siguiente consulta: SELECCIONE COMP_NAME, VERSION, STATUS FROM DBA_REGISTRY


2.4 Vistas de metadatos de geometría

Los metadatos de geometría que describen las dimensiones, los límites inferior y superior y la tolerancia en cada dimensión se almacenan en una tabla global propiedad de MDSYS (que los usuarios nunca deben actualizar directamente). Cada usuario espacial tiene las siguientes vistas disponibles en el esquema asociado con ese usuario:

USER_SDO_GEOM_METADATA contiene información de metadatos para todas las tablas espaciales propiedad del usuario (esquema). Esta es la única vista que puede actualizar, y es en la que los usuarios espaciales deben insertar metadatos relacionados con tablas espaciales.

ALL_SDO_GEOM_METADATA contiene información de metadatos para todas las tablas espaciales en las que el usuario tiene permiso SELECT.

Los usuarios espaciales son responsables de completar estas vistas. Para cada columna espacial, debe insertar una fila adecuada en la vista USER_SDO_GEOM_METADATA. Oracle Spatial garantiza que la vista ALL_SDO_GEOM_METADATA también se actualice para reflejar las filas que inserta en USER_SDO_GEOM_METADATA.

Cada vista de metadatos tiene la siguiente definición:

Además, la vista ALL_SDO_GEOM_METADATA tiene una columna OWNER que identifica el esquema que posee la tabla especificada en TABLE_NAME.

2.4.1 TABLE_NAME

La columna TABLE_NAME contiene el nombre de una tabla de características, como COLA_MARKETS, que tiene una columna de tipo SDO_GEOMETRY.

El nombre de la tabla se almacena en las vistas de metadatos espaciales en todos los caracteres en mayúsculas.

El nombre de la tabla no puede contener espacios o letras entre mayúsculas y minúsculas en una cadena entre comillas cuando se inserta en la vista USER_SDO_GEOM_METADATA, y no puede estar en una cadena entre comillas cuando se usa en una consulta (a menos que esté en mayúsculas).

La tabla de características espaciales no puede ser una tabla organizada por índices si planea crear un índice espacial en la columna espacial.

2.4.2 COLUMN_NAME

La columna COLUMN_NAME contiene el nombre de la columna de tipo SDO_GEOMETRY. Para la tabla COLA_MARKETS, esta columna se llama SHAPE.

El nombre de la columna se almacena en las vistas de metadatos espaciales en todos los caracteres en mayúsculas.

El nombre de la columna no puede contener espacios o letras entre mayúsculas y minúsculas en una cadena entre comillas cuando se inserta en la vista USER_SDO_GEOM_METADATA, y no puede estar entre comillas cuando se usa en una consulta (a menos que esté en mayúsculas).

2.4.3 DIMINFO

La columna DIMINFO es una matriz de longitud variable de un tipo de objeto, ordenada por dimensión, y tiene una entrada para cada dimensión. El tipo SDO_DIM_ARRAY se define de la siguiente manera:

El tipo SDO_DIM_ELEMENT se define como:

La instancia SDO_DIM_ARRAY es de tamaño norte Si hay norte dimensiones. Es decir, DIMINFO contiene 2 instancias SDO_DIM_ELEMENT para geometrías bidimensionales, 3 instancias para geometrías tridimensionales y 4 instancias para geometrías tetradimensionales. Cada instancia de SDO_DIM_ELEMENT en la matriz debe tener valores válidos (no nulos) para los atributos SDO_LB, SDO_UB y SDO_TOLERANCE.

Para obtener una explicación de la tolerancia y cómo determinar el valor de SDO_TOLERANCE apropiado, consulte la Sección 1.5.5, especialmente la Sección 1.5.5.1.

Spatial asume que la matriz de longitud variable está ordenada por dimensión. La matriz de longitud variable DIMINFO debe ordenarse por dimensión de la misma manera que se ordenan las ordenadas para los puntos en la matriz de longitud variable SDO_ORDINATES. Por ejemplo, si la matriz de longitud variable SDO_ORDINATES contiene norte, Ynorte>, entonces la primera entrada DIMINFO debe definir la dimensión X y la segunda entrada DIMINFO debe definir la dimensión Y.

El ejemplo 2-1 de la sección 2.1 muestra el uso de los tipos SDO_GEOMETRY y SDO_DIM_ARRAY. Este ejemplo demuestra cómo se representan los objetos geométricos (áreas de mercado hipotéticas para colas) y cómo la tabla de características COLA_MARKETS y la vista USER_SDO_GEOM_METADATA se completan con los datos de esos objetos.

2.4.4 SRID

La columna SRID debe contener cualquiera de los siguientes: el valor SRID para el sistema de coordenadas para todas las geometrías de la columna, o NULL si no se debe asociar ningún sistema de coordenadas específico con las geometrías. (Para obtener información sobre los sistemas de coordenadas, consulte el Capítulo 6.)


Lista de funciones SQL

Haga clic en los enlaces a continuación para ir a las funciones que puede usar con el tipo ST_Geometry en Oracle, PostgreSQL y SQLite.

Al usar funciones ST_Geometry en Oracle, debe calificar las funciones y operadores con sde. Por ejemplo, ST_Buffer sería sde.ST_Buffer. Añadiendo sde. indica al software que la función está almacenada en el esquema del usuario sde. Para PostgreSQL, la calificación es opcional, pero es una buena práctica incluir el calificador. No incluya la calificación cuando use las funciones con SQLite, ya que no hay un esquema sde en las bases de datos SQLite.

Para tipos espaciales distintos de ST_Geometry, como el tipo de geometría PostGIS o el tipo de Oracle SDO_Geometry, consulte la documentación de PostGIS u Oracle Spatial, respectivamente, para obtener información sobre las funciones utilizadas por cada uno de estos. La documentación de PostGIS se puede encontrar en www.postgis.org. La documentación de Oracle se puede encontrar en el Centro de ayuda de Oracle.

Las funciones SQL de ST_Geometry se pueden agrupar en función de su uso.

Funciones de constructor

Las funciones de constructor toman un tipo de geometría o una descripción de texto de la geometría y crean una geometría. La siguiente tabla enumera las funciones del constructor e indica qué implementaciones de ST_Geometry son compatibles con cada una.


2.1 Ejemplo simple: insertar, indexar y consultar datos espaciales

Esta sección presenta un ejemplo simple de cómo crear una tabla espacial, insertar datos, crear el índice espacial y realizar consultas espaciales. Se refiere a conceptos que se explicaron en el Capítulo 1 y que se explicarán en otras secciones de este capítulo.

El escenario es un fabricante de refrescos que ha identificado áreas geográficas de interés comercial para varios productos (colas). Las colas pueden ser las producidas por la empresa o por sus competidores, o alguna combinación. Cada área de interés podría representar cualquier criterio definido por el usuario: por ejemplo, un área donde esa cola tiene la participación mayoritaria del mercado, o donde la cola está bajo presión competitiva, o donde se cree que la cola tiene un potencial de crecimiento significativo. Cada área puede ser un vecindario en una ciudad o una parte de un estado, provincia o país.

La figura 2-1 muestra las áreas de interés de cuatro colas.

Figura 2-1 Áreas de interés para el ejemplo simple

El ejemplo 2-1 realiza las siguientes operaciones:

Crea una tabla (COLA_MARKETS) para contener los datos espaciales

Inserta filas para cuatro áreas de interés (cola_a, cola_b, cola_c, cola_d)

Actualiza la vista USER_SDO_GEOM_METADATA para reflejar la información dimensional de las áreas.

Crea un índice espacial (COLA_SPATIAL_IDX)

Realiza algunas consultas espaciales.

Muchos conceptos y técnicas del ejemplo 2-1 se explican en detalle en otras secciones de este capítulo.

Ejemplo 2-1 Ejemplo simple: insertar, indexar y consultar datos espaciales


Creación de clases de entidad en Oracle con almacenamiento ST_Geometry

A partir de ArcGIS 9.3, cuando instala por primera vez el componente ArcSDE, el esquema ST_Geometry es el tipo de almacenamiento predeterminado. La configuración predeterminada para el almacenamiento de ArcSDE se define en la tabla DBTUNE mediante los parámetros GEOMETRY_STORAGE.

Si desea almacenar la mayoría de los datos de su clase de entidad en el formato ST_Geometry, deje el parámetro GEOMETRY_STORAGE de la palabra clave DEFAULTS configurado en ST_GEOMETRY.

Si inicialmente creó su geodatabase antes de ArcGIS 9.3, debe modificar la configuración de la tabla DBTUNE para crear clases de entidad con columnas ST_GEOMETRY de forma predeterminada estableciendo el parámetro GEOMETRY_STORAGE bajo la palabra clave DEFAULTS en ST_GEOMETRY.

También debe modificar el parámetro ST_GEOM_LOB_STORAGE en la lista de palabras clave DEFAULTS. Sin embargo, cuando se agrega a la palabra clave DEFAULTS, el nombre del segmento LOB no debe incluirse en la definición de este parámetro. Si se incluye, a menos que modifique el valor del nombre, la creación de la clase de entidad fallará cuando se cree una segunda clase de entidad, porque cada nombre de segmento de LOB debe ser único para un esquema determinado. El siguiente ejemplo de parámetro ST_GEOM_LOB_STORAGE no contiene nombres de objeto, lo que evita colisiones de nombres dentro del mismo esquema:

NOTA: Utilice el comando de administración sdedbtune para modificar la configuración de DBTUNE. Para obtener detalles sobre el uso del comando sdedbtune, consulte la Referencia de comandos de administración de ArcSDE.

ArcSDE para Oracle admite varios esquemas de almacenamiento de geometría diferentes & # 8212 estos esquemas diferentes se pueden usar todos juntos en la misma base de datos. Si bien solo puede haber un esquema de geometría predeterminado, se pueden crear tablas individuales utilizando diferentes esquemas de geometría.

Si desea almacenar solo algunas de sus clases de entidad con almacenamiento de tipo espacial, puede especificar la palabra clave ST_GEOMETRY cuando cree la clase de entidad. Si hace esto, esa clase de entidad en particular se creará con una columna ST_Geometry. En el archivo dbtune, la palabra clave ST_GEOMETRY aparece de la siguiente manera:

Entre los ejemplos de valores válidos para el parámetro ST_GEOM_LOB_STORAGE se incluyen los siguientes:

NOTA: Como se mencionó anteriormente en esta sección, si define los nombres de los espacios de tabla de índice LOB y LOB, debe modificar estos valores antes de la creación de cada clase de entidad. Si no lo hace, las creaciones de clases de entidad subsiguientes fallarán porque cada nombre de segmento debe ser único.

Para obtener más ejemplos y más información sobre la creación y el mantenimiento de segmentos LOB de Oracle, busque "segmento LOB" en el sitio de soporte de ESRI. Existen varios artículos de la base de conocimientos sobre el tema.


Pensamiento vishful & # 8230

Hemos intentado optimizar la forma en que almacenamos y procesamos datos espaciales en Oracle. Normalmente, crearíamos nuestras tablas espaciales como FeatureClasses de ArcCatalog y crearíamos tablas antiguas simples de Oracle para nuestros datos de negocios / atributos que se unirían con los datos espaciales en las FeatureClasses a través de un campo clave compartido para crear una vista espacial SDE. Esto funciona bien, pero hay algunos inconvenientes en este enfoque.

  • SDE crea campos innecesarios en la tabla FeatureClass en Oracle, como la anotación de cad de campo que simplemente no necesita estar allí.
  • Crear FeatureClasses manualmente desde ArcCatalog es un proceso que no se puede automatizar como parte del proceso de construcción. Idealmente, nos gusta ejecutar un comando de nuestros scripts de compilación que borrará todo nuestro modelo de la base de datos y ejecutará otro comando para recrear todo el modelo para comenzar con una pizarra limpia para probar cada compilación. Estos scripts también se utilizarán durante el proceso de implementación cuando la base de datos deba volver a crearse en otro entorno.
  • FeatureClasses deberá editarse a través de ArcObjects (versionado / no versionado) o ArcMap (versionado) que necesitaría una licencia ESRI en cualquier máquina cliente que desee editar los datos espaciales. En un entorno web, esto significaría una licencia ESRI en el servidor web.

Queríamos que nuestra configuración intentara solucionar algunos de los inconvenientes anteriores. Entonces, escribimos scripts SQL que

  1. Crea la tabla espacial
  2. Inserte metadatos sobre la tabla espacial en la tabla de metadatos de geometría de Oracle USER_SDO_GEOM_METADATA
  3. Crea un índice espacial en la mesa
  4. Registre la tabla espacial de Oracle con ArcSDE como FeatureClass utilizando el comando & # 8216sdelayer -0 register & # 8217

Aquí hay algunos scripts SQL de muestra para realizar los primeros tres pasos con Oracle

El comando sde de muestra para registrar la tabla como una FeatureClass de varios polígonos con ArcSDE especificando los límites

sdelayer -o registrar -l CLIENTES, CUST_GEO_LOCATION -e a + M -C CLIENTE_ID -i sde: oracle11g -s SERVER_NAME -u XXX -p YYY @ orcl -t SDO_GEOMETRY -P Alto -x -180, -90,11132000

Como puede ver en los comandos de arriba, la tabla espacial está registrada con Oracle para tener un SRID (id de referencia espacial) de 8307 que denota los sistemas de coordenadas geográficas WGS 84. Oracle mantiene su propia tabla CS_SRS donde mantiene una lista de sistemas de referencia espacial compatibles con Oracle. Se espera que el SRID especificado al agregar los metadatos de geometría con Oracle esté presente en la tabla CS_SRS; de lo contrario, Oracle insertará los metadatos en sus tablas. Los límites especificados al registrar la tabla espacial como FeatureClass con ArcSDE también reflejan el WGS 84 GCS.

Hasta ahora tan bueno. La solución anterior funciona a las mil maravillas. Ahora que los mapas base de ArcGIS Online se han trasladado al sistema de proyección Web Mercator utilizado por Google y Bing, también queríamos mantener nuestros datos en Web Mercator para que el servidor GIS no tenga que reproyectar los datos al renderizar mapas y también así que podríamos ofrecer datos espaciales como GeoJSON / ArcJSON desde nuestros servicios web personalizados para que los consuman los clientes web. Aquí es donde comenzaron los problemas. Oracle no tiene un SRID para el sistema de proyección web mercator. Revisamos la tabla CS_SRS para verificar que se mantuviera con una identificación diferente pero sin suerte. Hasta donde yo sé, el proceso de registrar un nuevo SRID con Oracle no está documentado en ninguna parte. Aparentemente, no es tan simple como agregar una entrada en la tabla CS_SRS que intentamos sin éxito.

Entonces, para solucionar este problema, registramos nuestra tabla espacial con la tabla de metadatos de geometría de Oracle sin un SRID. Entonces, Oracle piensa que el SRID para la tabla espacial es NULL. Esto se convierte en un problema cuando intentamos insertar geometrías con ESRI & # 8217s SRID 102113 en la tabla espacial. Oracle no nos permite insertar geometrías en la tabla espacial cuyo valor no sea NULL para que coincida con la entrada en sus tablas de metadatos de geometría. Entonces, nos vemos obligados a insertar geometrías con un SRID NULL en la tabla. Pero ArcSDE necesita saber que la tabla espacial está en el sistema de proyección de Web Mercator. Para hacer esto, registramos la tabla espacial usando el & # 8216sdelayer -o registro & # 8217 especificando el archivo de proyección & # 8220WGS 1984 Web Mercator (Auxiliary Sphere) .prj & # 8221 de ESRI. Vea la muestra a continuación

sdelayer -o registrar -l CLIENTES, UBICACIÓN_GEO_CUST -e a + M -C ID_ CLIENTE -i sde: oracle11g -s NOMBRE_SERVICIO -u XXX -p YYY @ orcl -t SDO_GEOMETRY -P Alto -G archivo = & # 8221C: TEMP WGS 1984 Web Mercator (esfera auxiliar) .prj & # 8221

La declaración de inserción para las tablas de metadatos de geometría de Oracle se ve así

INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO)

VALORES (& # 8216 CLIENTES & # 8217, & # 8216CUST_GEO_LOCATION & # 8217,

SDO_DIM_ARRAY

(SDO_DIM_ELEMENT (& # 8216X & # 8217, -20037700, 20037700, 0.1),

SDO_DIM_ELEMENT (& # 8216Y & # 8217, -20037700, 20037700, 0.1)))

Esto es feo, pero funciona. Pudimos ver y editar los datos en ArcMap sin problemas.

Aquí hay algunas cosas más descubiertas en el camino.

  • Oracle convierte todos los nombres de las tablas y los nombres de los campos en mayúsculas de forma predeterminada, incluso cuando usted especifica los nombres en minúsculas en las declaraciones SQL. Podemos forzar a Oracle a usar alfabetos en minúsculas en los nombres de la tabla / campo especificando los nombres de la tabla / campo en las declaraciones SQL encerrándolos entre comillas.
  • Si usa la técnica anterior para usar nombres de tabla / campo en minúsculas para las tablas espaciales, no podrá registrar los metadatos de geometría de la tabla con Oracle. Esto se debe a que Oracle espera que el nombre de la tabla espacial / campo esté en mayúsculas para insertarlo en la tabla de metadatos de geometría. Esto es una locura y no puedo imaginar que este requisito sea intencional.
  • La sintaxis SQL espacial de Oracle es fea. Muy feo. Definitivamente pueden aprender de la dulce sintaxis SQL en MS SQL SERVER 2008.
  • La versión gratuita de Oracle llamada Oracle XE admite los tipos de datos espaciales. Es decir, en Oracle XE podemos almacenar columnas cuyo tipo de datos sea MDSYS.SDO_GEOMETRY. Oracle XE también nos permite realizar algunas operaciones espaciales en estas columnas espaciales, pero no todas las operaciones espaciales que están disponibles en la edición empresarial de Oracle. Las características espaciales que están disponibles en la edición XE no están documentadas en ninguna parte que yo sepa. Las extensiones espaciales de Oracle aportan más funciones espaciales a la edición empresarial de Oracle, como compatibilidad con ráster, etc.
  • MDSYS.Oracle ST_GEOMETRY es diferente de ESRI ST_GEOMETRY y es un envoltorio de MDSYS.SDO_GEOMETRY

Si conoce una mejor manera de hacer las cosas con Oracle y SDE para la proyección de mercator web, hágamelo saber, soy todo oídos. Espero que esta publicación le salve a alguna otra pobre alma un poco de dolor y sufrimiento.