Mejores mediciones de distancia en la proyección de Web Mercator

10

Estoy trabajando con una pila ESRI, almacenando mis capas en una geodatabase sql-spaceial-enabled-SDE (tipo de geometría, Web Mercator-3857).

Estoy creando una aplicación de mapeo web, por lo que, por defecto, los mosaicos también están en web mercator, 3857.

A través de procesos almacenados, uso STDistance para consultar distancias desde la ubicación de un usuario (Coordenadas también en web mercator) a las diversas capas.

El problema es que, debido a la distorsión de web mercator, mis cálculos de distancia están cada vez más lejos, cuanto más lejos del ecuador se hacen.

He pensado en almacenar mis capas en el tipo sql-space-geography (en lugar de geometry), pero:

  • Me imagino que mis consultas de distancia tomarán mucho más tiempo (la distancia se calcula en la superficie esférica)
  • tendré que reimportar muchos datos
  • Los servicios de ArcGIS no serán tan rápidos como necesitarán proyectar sobre la marcha

Si voy a los mapas de Google y hago un cálculo de distancia, la distancia devuelta es mucho más precisa, incluso en las regiones del norte / sur, por lo que supongo que Google debe estar corrigiendo la distorsión causada por la proyección web del vendedor.

Mi pregunta entonces: ¿Hay un valor de factor simple que se pueda aplicar a los cálculos de distancia realizados en la proyección web mercator para obtener la distancia "correcta"?

coordinate-system distance Blomster
fuente

Respuestas:

12

Para distancias cortas, puede multiplicar la distancia calculada con cos(lat), ya que la escala de la proyección de mercator es proporcional a la secante de la latitud (secante es 1/cos). Ver también http://en.wikipedia.org/wiki/Mercator_projection#Mathematics_of_the_projection

Anexo gracias a @ jeremiah-england : mientras que la corrección anterior sería correcta cuando se trata de proyecciones verdaderas de Mercator, el Web Mercator (EPSG: 3857) no es un Mercator. EPSG lo llama un "Pseudo-Mercator". El problema es que usa WGS84, un modelo elíptico, y lo proyecta usando cálculos esféricos de mercator (que Google usó porque son más rápidos). Si escala sus distancias 1/cos(phi)con la web Mercator, tendrá un 0.6% de descuento en el ecuador. Vea la presentación de Noel Zinn en Web Mercator para más detalles.

De acuerdo con la presentación mencionada anteriormente, el siguiente método podría usarse para calcular distancias más precisas desde las coordenadas web de mercator. Dado dx- diferencia de coordenadas horizontales (dirección WE), y dy- diferencia de coordenadas verticales (dirección SN):

e = 0.081819191
adjustedX = dx * cos(lat) / sqrt(1 - e^2 * sin(lat)^2)
adjustedY = dy * cos(lat) * (1 - e^2) / pow(1 - e^2 * sin(lat)^2, 3/2)
adjustedDistance = hypot(adjustedX, adjustedY)

La relación entre este ajuste y cos(lat)es mayor en la dirección SN, desde 0.9933el ecuador hasta 1.0034los polos. La relación de dirección WE comienza 1en el ecuador y crece hasta 1.0034los polos.

Tenga en cuenta que esta corrección todavía funciona razonablemente bien solo para distancias cortas, donde se puede suponer la geometría plana de la superficie de la Tierra.

mkadunc
fuente
1
Y para distancias más largas, puede usar la latitud media de los dos puntos finales: lo cos((l1 + l2)/2)que le dará la distancia de rumbo constante / línea de rumbo, en lugar de una distancia de gran círculo.
MerseyViking
eso solo cambia el esferoide, pero no brinda la misma precisión que una proyección local.
falcacibar
1
@falcibar - no veo cómo la elección de la latitud media cambia el esferoide
mkadunc
@ MerseyViking: gracias, olvidé mencionar que la mejor latitud para usar para el cálculo sería la media de los dos puntos comparados.
mkadunc
1
+1 por la respuesta. @ Mersey: ¿Por qué funciona la corrección de latitud media? Después de todo, las distorsiones en el Mercator pueden volverse arbitrariamente grandes y las salidas de los loxodromos desde las geodésicas también pueden ser grandes. Parece que se pueden cometer algunos errores potencialmente enormes para los cuales una corrección simple no sería confiable.
whuber
6

Consideraría su segunda opción de almacenar sus datos en el GEOGRAPHYformato nuevamente si está buscando resultados precisos en datos globales.

No hay nada que le impida tener dos campos espaciales en una tabla: uno en Mercator como GEOMETRYtipo y otro en WGS84 como GEOGRAPHYtipo (al menos no en SQL Server, no estoy seguro acerca de ArcSDE).

Debería poder crear una secuencia de comandos de geoprocesamiento simple que llene ambos campos con sus datos originales. Si hay edición y actualizaciones frecuentes en curso, entonces esta puede no ser una opción.

Una vez que tenga los dos campos, puede continuar usando su Mercator para una visualización rápida y convertir los puntos ingresados ​​por el usuario a Lat / Lon para distancias.

Esto tiene dos ventajas principales:

  • También puede obtener áreas y longitudes de características más precisas en función de las consultas de los usuarios
  • no necesita preocuparse por olvidarse de agregar un código personalizado para cada consulta que se ocupa de mediciones

Las velocidades de consulta serán más complejas, pero pueden pasar desapercibidas para un usuario. Es posible que desee probar con una clase de entidad antes de decidirse por una solución. También deberá convertir los puntos ingresados ​​por el usuario desde Mercator (lo cual debería ser trivial y podría hacerse en el navegador).

Incluso con el tipo de geografía, aunque todavía hay un margen de error:

La tolerancia al error para los métodos de geografía puede ser tan grande como 1.0e-7 * extensiones

De MSDN

geographika
fuente
Desafortunadamente, SDE solo permitirá una columna espacial: help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//… - No he intentado crear una vista y registrarla con SDE, pero eso podría Ser un enfoque posible.
Allan Adair
@Allan: es bueno saberlo. ¡Otro aspecto positivo para usar SDE entonces! Una tabla con solo la geometría 4326 y una unión de vuelta a la tabla original + vista espacial debería lograr el mismo propósito
geographika
3

Una sugerencia alternativa de ESRI es utilizar un "servicio de geometría", que consiste en enviar las geometrías a un servidor ArcGIS y que se devuelva el resultado. Si no espera ningún problema de cuello de botella al usar un servicio web, este puede ser un enfoque muy efectivo. He usado el mismo enfoque en una aplicación Silverlight.

Aquí hay una entrada de blog original de ESRI: http://blogs.esri.com/Dev/blogs/arcgisserver/archive/2010/03/05/Measuring-distances-and-areas-when-your-map-uses-the -Mercator-projection.aspx

En el blog hay un ejemplo de JavaScript simplificado, y también hay una aplicación de ejemplo completa aquí: http://serverapps.esri.com/javascript_examples/compare_measurements.htm

Allan Adair
fuente
0

Como lo hace Google Earth, podría transformar la geometría a la proyección de zona WGS84 local, o una proyección WGS84 mejorada como SIRGAS en América del Sur.

Puede buscar en http://www.spatialreference.org las coordenadas de casi todas las proyecciones "zonificadas", y puede hacer una tabla, etc., para transformarlas depende de la zona.

Imaginamos una mesa de zonas

|   minx     |    miny    |    maxx    |   maxy     |  srid  |
+------------+------------+------------+------------+--------+
|234567.34314|234567.34334|234567.34334|234567.34334|  1234  |

Todos los valores minx, miny, maxx, maxy almacenados en Spherical Mercator (Web Mercator). entonces usaré postgis como ejemplo.

SELECT ST_Distance(
         ST_Transform( -- transform/reproject
            ST_SetSRID(geom_line, 3857) -- geom_line with forced srid assignation to web mercator
            , ( -- here we get the first SRID from the spatial position of geom_line
                 SELECT  srid
                 FROM    zones
                 WHERE   ST_Contains(
                           ST_MakeBox2d(ST_Point(minx,miny),ST_Point(maxx,maxy))
                           , geom_line
                         )
                 LIMIT 1
            ))

Espero que esto sea útil, que tengas un buen día.

falcacibar
fuente
No puedo estar seguro, pero según el uso que hizo Blomster de "STDistance" en su pregunta, parece que no está usando PostGIS. Si Blomster está utilizando SQL Server, no hay funcionalidad ST_Transform.
Allan Adair
Doy el proceso y la mejor manera en que podría resolverlo, él podría encargarse del resto, y podría usar una reproyección de software, pero es realmente una pena que un SQL Server no se ocupe de las proyecciones.
falcacibar
tal vez CLR habilitado y la biblioteca .net nettopologysuite podría ayudar?
falcacibar