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

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"?

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.

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

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

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.

OpenLayers tiene un método de utilidad para calcular la distancia entre dos puntos EPSG: 4326 (WGS84) en un elipsoide. Como OpenLayers es de código abierto, puedes ver cómo se implementa aquí: https://github.com/openlayers/openlayers/blob/release-2.12/lib/OpenLayers/Util.js#L750

Para aquellos que usan OpenLayers y el control Measure, solo habilite geodésico en las opciones literales para usar este cálculo.