Utilicé OGR2OGR para importar datos de puntos SRID 4326 a MSSQL Server. No me di cuenta de que por defecto crea una columna de geometría en lugar de detectar los datos como 4326 y crear una columna de geografía. Conozco el código para evitar esto, así que no hay problema.
Los datos, tal y como están en una columna de geometría, aparecen perfectamente en QGIS. Entonces, ¿necesito realmente poner los datos en una columna de geografía?
Gracias.
Lo hice por accidente hace unos meses, aunque fue con líneas y era una featureclass muy grande (creo que era del orden de 10 millones de features). Tampoco recuerdo si era SQL Server 2008 o 2012.
Una cosa que noté en ArcMap fue que todo era muy, muy lento. Hice un perfil. Encontré la consulta que estaba causando la lentitud y lo puso en SSMS y determinó que era el método de filtro que era el culpable (iirc, ArcMap utiliza filtro con un sobre para agarrar OIDs). ¡SQL Server estaba devolviendo cada una de las filas de la tabla!
Cuando cambié a geografía, Filter devolvía el número correcto de características para la geometría dada.
No recuerdo que otros métodos se comporten mal, pero no dejé los datos de 4326 en geometría SQL el tiempo suficiente para averiguarlo.
Si el tamaño de su mesa no es muy grande, esto podría no importar. Pero es algo a tener en cuenta para las tablas más grandes. Tampoco importaría si QGIS no utiliza Filter .
Si no es necesario medir distancias sobre el esferoide, la geometría se adapta bien. El manual de PostGIS contiene información comprensible sobre esto http://postgis.net/docs/manual-2.0/using_postgis_dbmanagement.html#PostGIS_Geography y es válido también para MSSQL.
I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
