Usando geometria em vez de tipos de dados geográficos no SQL Server Spatial?

Historicamente, trabalhei principalmente com coordenadas simples de latitude e longitude em um SQL Server. Eu os armazenei como um tipo de dados geográficos no SQL Server e os renderizei em uma variedade de exibições (principalmente no Google Maps).

Recentemente, comecei a trabalhar com conjuntos de dados de shapefile de várias fontes, e quase exclusivamente eles são geometria. Além disso, eles usam uma variedade de sistemas de referência de coordenadas.

É muito enlouquecedor trabalhar com isso.

• O USGS, para alguns de seus dados, usa um CRS muito raro e difícil de identificar .
• O condado de Los Angels diz que usa o Plano Estadual 5 (sem referência específica ao CRS) e, é claro, existem vários "planos estaduais 5" para escolher no QGIS.

Existem realmente algumas vantagens nesses sistemas de referência espacial em particular que não podem ser alcançadas com a WGS84, considerando que a VAST maioria das pessoas que visualiza e consome o deseja nesse formato?

Há uma boa resposta no Stack Overflow , que é mais ou menos assim:

O tipo de geografia é um pouco mais restritivo que a geometria. Ele não pode atravessar hemisférios diferentes e o anel externo deve ser desenhado no sentido anti-horário.

O restante pode ser encontrado no tipo de dados Geografia vs. tipo de dados Geometria no SQL Server .

Um artigo sobre geometria versus geografia no SQL do blog Trenches entra em mais detalhes:

Se você está procurando a maior diferença entre os dois tipos de dados, verá que é a funcionalidade. Um objeto Geometry é apenas um polígono plano 2D. Isso significa que não importa se você escolher um país no topo da terra (por exemplo, o Canadá, que é "curvado") ou um país próximo ao Equador (por exemplo, o Brasil, que é "plano").

Um objeto Geografia, por outro lado, é um polígono 3D (ou mesmo 4D), que tem a mesma curva que a forma da Terra. Isso significa que a diferença entre 2 pontos não é calculada em uma linha reta, mas é preciso considerar a curvatura da terra.

Outra diferença crucial é a capacidade de armazenar seus dados em sistemas de coordenadas padrão, como NAD_1983_StatePlane_California Zone 5 , e usar todos os recursos do banco de dados espacial, funções espaciais etc. geografia como seu tipo de dados, você só pode armazenar seus dados no WGS84.

Então, eu diria que, se você tiver a opção, vá com geometria, use EPSG: 102645/102245 (você terá que verificar qual é a 'zona do plano de estado 5 padrão do SoCal) e estará pronto para qualquer análise que você deseja realizar. Se você deseja compartilhar, exporte seus conjuntos de dados para o WGS84, se preferir esse compartilhamento.

Talvez verifique as propriedades do Projected Coordinate Systems, para ter uma visão de sua utilidade?

Existem 3 aspectos ou propriedades apresentados nos Sistemas de coordenadas projetadas que estabelecem sua utilidade e lógica. Qualquer projeção de espaço 3D em uma superfície 2D obviamente exibirá distorção versus realidade. Dependendo da sua aplicação, o uso de um sistema de coordenadas projetadas específico pode garantir uma representação mais precisa da realidade e, em algumas aplicações, a precisão da granulação fina é importante.

Três propriedades dos sistemas de coordenadas projetadas. Você pode ter perfeição em alguns, mas nunca perfeição em todos:

Equidistante - As distâncias (de um ponto específico) mostradas no mapa são verdadeiras à realidade.

Conforme - Quando ampliada, os ângulos mostrados no mapa são verdadeiros à realidade.

Área Igual - As áreas registradas no mapa são iguais às áreas dos objetos na realidade.

Na Califórnia, os escritórios dos agrimensores usam uma projeção cônica conforme Lambert e dividem o estado em zonas para minimizar distorções. O Plano Estadual 5 é uma dessas zonas.

http://www.conservation.ca.gov/cgs/information/geologic_mapping/state_plane