Usé OGR2OGR para importar datos de puntos SRID 4326 en el servidor MSSQL. No me di cuenta de que el valor predeterminado es crear una columna de geometría en lugar de detectar los datos como 4326 y crear una columna de geografía. Sé el código para evitar esto, así que no hay problema.
Los datos tal como están en una columna de geometría se muestran muy bien en QGIS. Entonces, ¿realmente necesito poner los datos en una columna de geografía?
¡Gracias!
Respuestas:
Si no necesita medir distancias sobre el esferoide, entonces la geometría se adapta bien. El manual de PostGIS contiene información comprensible sobre este http://postgis.net/docs/manual-2.0/using_postgis_dbmanagement.html#PostGIS_Geography y es válido también para MSSQL.
Hice esto por accidente hace unos meses, aunque era con líneas y era una clase de características muy grande (creo que era del orden de 10 millones de características). Tampoco recuerdo si fue SQL Server 2008 o 2012.
Una cosa que noté en ArcMap fue que todo era muy, muy lento. Lo perfilé. Encontró la consulta que estaba causando la lentitud y la introdujo en SSMS y determinó que era el método de filtro el culpable (iirc, ArcMap usa Filter con un sobre para capturar OID). ¡SQL Server traía de vuelta cada fila de la tabla!
Cuando cambié a geografía, Filter estaba devolviendo el número correcto de características para la geometría dada.
No recuerdo que otros métodos se hayan comportado mal, pero no dejé los datos del 4326 en geometría SQL el tiempo suficiente como para descubrirlo.
Si el tamaño de su mesa no es muy grande, esto podría no importar. Pero es algo a tener en cuenta para mesas más grandes. Tampoco importaría si QGIS no usa Filter.