ArcSDE: ¿utiliza tipos de geometría nativos para una migración posterior fuera de SDE?

Antecedentes: tenemos una aplicación web de informes no espaciales con un servidor SQL Server. Nos gustaría agregar un componente espacial a esta aplicación: servir algunos mapas base, servir puntos y polígonos para ver y editar, crear informes para polígonos seleccionados.

Para ese fin, el plan es usar ArcSDE con SQL Server, y usar ArcServer para servir capas base y geometrías vectoriales. (algo así como WMS / WFS-T)

Problema: podemos, en algún momento, decidir que queremos alejarnos del costoso software propietario y usar una alternativa de FOSS (por ejemplo, GeoServer o TinyOWS si es compatible con SQL Server). Si es posible, me gustaría evitar construir la aplicación irrevocablemente en torno a la tecnología ESRI.

Entiendo que SDE es que puede usar formatos espaciales específicos de ESRI o formatos espaciales nativos del sistema de base de datos en el que está instalado. (Supongo que hay alguna penalización de rendimiento por usar los formatos nativos).

Mi (s) pregunta (s): Si configuráramos SDE en esta base de datos del servidor SQL utilizando formatos espaciales nativos de SQL Server, ¿podríamos configurar, digamos, GeoServer, para ejecutar contra las tablas que SDE estaba administrando? ¿Qué se necesitaría para extraer SDE y usar otra cosa? (Además, una meta-pregunta: ¿es esta una pregunta razonable que se debe hacer? ¿Hay algo importante que me estoy perdiendo?)

Una respuesta parcial: no soy un usuario de Geoserver, pero he creado una aplicación web espacial que no es Esri (ASP.NET) utilizando la geometría nativa almacenada en una clase de características SDE real (SQL Server 2008). Mientras no esté versionado (o esté versionado y acepte cualquier retraso que exista para que sus ediciones se muevan a la base), no debería ser un problema. Mi aplicación estaba dirigida espacialmente, no contenía ningún mapa, pero las funciones espaciales se usaban mucho en las instrucciones SELECT y los procedimientos almacenados.

He descubierto que ArcGIS puede tener errores con las implementaciones ST_GEOMETRY nativas y / o de Esri y, a menudo, provocará que el proveedor señale con el dedo. Vea esta pregunta: ¿Cómo permitir más vértices de polilínea para un ST_GEOMETRY en Oracle / SDE? (versión corta: Oracle: "Así son las cosas. Esri necesita lidiar con eso". Esri: "Eso es un error, espere hasta que Oracle lo arregle").

No es una razón para no usar geometría nativa, sino algo a tener en cuenta en caso de que sea el primero en toparse con un error (también sugiero tener versiones SDE_BINARY de sus conjuntos de datos en un entorno de prueba / desarrollo para que pueda confirmar o descartar) comportamiento extraño en ambos tipos de datos de almacenamiento).

Menciona la edición en esta base de datos espacial planificada. Ahí es donde no proporciona suficientes datos para una respuesta completa.
Si hay algunas peculiaridades de esri (tipos de datos) sobre las tablas editadas, entonces está planeando algunos mares agitados.
Será suficiente desafío configurar las tablas espaciales (terceros), evitar los permisos de los usuarios, los permisos del espectador, los bloqueos, no se admiten versiones, editar los datos no versionados en arcgis, ... Hay muchos otros puentes, obstáculos. , e incluso abismos para superar.
Por lo tanto, cuanto más simple sea el modelo, menores serán los problemas de realización.
Dicho esto, la respuesta corta es sí.
Uno de los problemas con este camino es que tan pronto como se toma la decisión de recorrer el camino.
Hay muchos vehículos para bajar por el camino.
Tomar la decisión por el vehículo correcto a menudo se logra a través de meses, si no años, de jugar sandbox.

EDITAR
Si edita polígonos y no utiliza algunas técnicas y herramientas bastante sofisticadas, desearía contar con reglas de topología para ayudar con el control de calidad (tal vez otra pila de software como el radio). Si divide un polígono, desea que ambos obtengan los mismos atributos, o no, cuando se mueve un vértice es que se ajuste a otro, si no es así, hay una astilla. Y así sucesivamente. si no usa esri, está solo (o el db espacial) para aplicar algunas funciones básicas de gis. solo tiene que saber lo que quiere y cómo hacerlo (o que se puede hacer).

Almacenamos datos sde en el tipo de geometría nativa de SQL Server 2008 y no lo haría de otra manera. Esto permite la máxima flexibilidad con consultas espaciales en la base de datos. Geoserver acaba de realizar mejoras significativas en el soporte para los tipos de datos del servidor SQL, pero no lo hemos utilizado, por lo que no puedo proporcionar mucha información al respecto. Una cosa a tener en cuenta es que la construcción de una base de datos sde con la instalación estándar posterior crea una estructura de tabla para sde. Sería prudente analizar esa estructura. Si estuviera eliminando sde a favor de las soluciones de Foss, no querría todas las tablas del sistema sde innecesarias. Por lo tanto, reconstruiría una base de datos limpia y movería las tablas al nuevo entorno. Esta sería una oportunidad para probar postgis en lugar de SQL Server ya que geoserver tiene un historial de desarrollo con postgis. Yo no

¡Espero que ayude!