Armazenando dados SRID: 4326 como geometria ou geografia?

Usei o OGR2OGR para importar dados de ponto SRID 4326 para o MSSQL Server. Não percebeu que o padrão é criar uma coluna de geometria em vez de detectar os dados como 4326 e criar uma coluna de geografia. Eu sei o código para contornar isso, então não há problema lá.

Os dados em uma coluna geométrica são exibidos no QGIS. Então, eu realmente preciso colocar os dados em uma coluna geográfica?

obrigado!

Se você não precisar medir distâncias sobre o esferóide, a geometria é adequada. O manual do PostGIS contém informações compreensíveis sobre este http://postgis.net/docs/manual-2.0/using_postgis_dbmanagement.html#PostGIS_Geography e é válido também para o MSSQL.

Fiz isso por acidente há alguns meses, embora tenha sido com linhas e tenha sido uma classe muito grande (acho que foi da ordem de 10 milhões de recursos). Também não me lembro se era o SQL Server 2008 ou 2012.

Uma coisa que notei no ArcMap foi que tudo estava muito, muito lento. Eu perfilei isso. Encontrou a consulta que estava causando a lentidão e a inseriu no SSMS e determinou que era o método Filter o culpado (iirc, o ArcMap usa o Filter com um envelope para obter OIDs). O SQL Server estava trazendo de volta todas as linhas da tabela!

Quando mudei para a geografia, o Filter estava retornando o número correto de recursos para a geometria especificada.

Não me lembro de outros métodos se comportando mal, mas não deixei os dados do 4326 na geometria SQL tempo suficiente para descobrir.

Se o tamanho da sua mesa não for muito grande, isso pode não importar. Mas é algo a ter em mente para tabelas maiores. Também não importa se o QGIS não usa Filter.