ArcSDE - usar tipos de geometria nativa para migração posterior do SDE?

Antecedentes: Temos um aplicativo Web de relatório não espacial com um back-end do SQL Server. Gostaríamos de adicionar um componente espacial a esta aplicação: servir alguns mapas de base, servir pontos e polígonos para visualização e edição, criar relatórios para polígonos selecionados.

Para esse fim, o plano é usar o ArcSDE com o SQL Server e usar o ArcServer para fornecer camadas de base e geometrias vetoriais. (algo como WMS / WFS-T)

Problema: Podemos, em algum momento, decidir que queremos nos afastar de um software proprietário caro e usar uma alternativa FOSS (por exemplo, GeoServer ou TinyOWS se / quando suportar o SQL Server). Se possível, eu gostaria de evitar a criação irrevogável do aplicativo em torno da tecnologia ESRI.

Meu entendimento do SDE é que ele pode usar formatos espaciais específicos da ESRI ou formatos espaciais nativos do sistema de banco de dados em que está instalado. (Presumo que exista alguma penalidade de desempenho ao usar os formatos nativos.)

Minhas perguntas: Se configurássemos o SDE nesse banco de dados do SQL Server usando formatos espaciais nativos do SQL Server, poderíamos configurar, por exemplo, GeoServer, para rodar nas tabelas que o SDE estava gerenciando? O que seria necessário para remover a SDE e usar outra coisa? (Além disso, uma meta-pergunta: esta é uma pergunta razoável a ser feita? Existe alguma coisa importante que me falta?)

Uma resposta parcial: eu não sou um usuário do Geoserver, mas criei um aplicativo Web não-Esri orientado para o espaço (ASP.NET) usando a geometria nativa armazenada em uma classe de recurso SDE real (SQL Server 2008). Desde que não seja versionado (ou seja, versionado e você aceite o atraso existente para que suas edições sejam movidas para a base), isso não deve ser problema. Meu aplicativo era dirigido espacialmente, não continha mapa, mas as funções espaciais eram muito usadas nas instruções SELECT e nos procedimentos armazenados.

Eu descobri que o ArcGIS pode ser buggy com implementações nativas e / ou Esri ST_GEOMETRY e geralmente resulta em apontar o dedo do fornecedor. Veja esta pergunta: Como permitir mais vértices de polilinha para um ST_GEOMETRY no Oracle / SDE? (versão curta: Oracle: "É assim que a Esri precisa lidar com isso." Esri: "Isso é um bug - aguarde até a Oracle consertar.")

Não é um motivo para não usar geometria nativa, mas algo a ter em atenção caso você seja o primeiro a encontrar um bug (eu também sugiro ter versões SDE_BINARY de seus conjuntos de dados em um ambiente de teste / dev para que você possa confirmar ou governar comportamento estranho nos dois tipos de dados de armazenamento).

Você mencionou a edição neste db espacial planejado. É aqui que você não fornece dados suficientes para obter uma resposta completa.
Se houver alguma peculiaridade esri (tipos de dados) sobre as tabelas editadas, você está planejando alguns mares agitados.
Será um desafio suficiente configurar tabelas espaciais (terceiros), contornar permissões de usuários, permissões de visualizador, bloqueios, sem suporte a versões, editar esses dados sem versão em arcgis, ... Existem muitas outras pontes, obstáculos e até abismos para superar.
Portanto, quanto mais simples o modelo, menos problemas para a realização.
Dito isto, a resposta curta é sim.
Um dos problemas com esta estrada é que, assim que a decisão de percorrer a estrada é tomada.
Existem muitos veículos para descer a estrada.
Tomar a decisão pelo veículo certo geralmente é realizado por meses, se não anos, jogando areia.

EDITAR
Se você editar polígonos e não usar algumas técnicas e ferramentas bastante sofisticadas, desejará aplicar regras de topologia para ajudar no controle de qualidade (talvez outra pilha de software como raio). Se você dividir um polígono, deseja que ambos obtenham os mesmos atributos, ou não, quando um vértice é movido, ele se encaixa em outro, se não houver uma tira. e assim por diante. se você não usa esri, está sozinho (ou no db espacial) para aplicar algumas funcionalidades básicas do gis. você apenas precisa saber o que deseja e como fazê-lo (ou que pode ser feito).

Armazenamos dados sde no tipo de geometria nativa do SQL Server 2008 e eu não faria isso de outra maneira. Isso permite flexibilidade máxima com consultas espaciais no banco de dados. O Geoserver acabou de fazer melhorias significativas no suporte aos tipos de dados do servidor SQL, mas como não o utilizamos, não posso fornecer muita informação a esse respeito. Um ponto a ser observado é que a criação de um banco de dados sde com a pós-instalação padrão cria uma estrutura de tabela para o sde. Seria sensato olhar para essa estrutura. Se eu estivesse removendo o sde em favor das soluções Foss, não desejaria todas as tabelas de sistema sde desnecessárias. Portanto, eu reconstruiria um banco de dados limpo e moveria as tabelas para o novo ambiente. Essa seria uma oportunidade para tentar o postgis no lugar do SQL server, pois o geoserver possui um histórico de desenvolvimento com o postgis. Eu não

Espero que ajude!