Кращі вимірювання відстаней у проекції на веб-Меркатор

Я працюю зі стеком ESRI, зберігаючи мої шари в sql-просторово-включеній SDE-базі геоданих (тип Геометрія, Web Mercator-3857).

Я будую додаток для веб-картографування, тому за замовчуванням плитки також є у веб-маркері, 3857.

Через збережені програми, я використовую STDistance для запиту відстаней від місця розташування користувача (Координати також у веб-маркері) до різних шарів.

Проблема полягає в тому, що через спотворення веб-меридіатора мої калькуляції відстані все більше вимикаються, чим далі від екватора вони зроблені.

Я думав зберігати мої шари типу sql-просторово-географічного (а не геометрії), але:

• Я думаю, що мої запити на відстань займуть набагато більше часу (обчислення відстані на сферичній поверхні)
• мені потрібно буде знову імпортувати багато даних
• служби арггіс не будуть настільки швидкими, як їх потрібно буде проектувати на ходу

Якщо я переходжу до карт Google і виконую підрахунок відстані, то повертається відстань набагато точніше навіть у північних / південних регіонах, тому я припускаю, що Google повинен виправляти спотворення, спричинені проекцією веб-меркатора.

Тоді моє запитання: чи є просте значення коефіцієнта, яке можна застосувати до калькуляцій відстані, виконаних в прогнозуванні веб-Меркатора, щоб отримати "правильну" відстань?

На коротких відстанях ви можете помножити обчислену відстань на cos(lat), оскільки масштаб проекції Меркатора пропорційний сеансу широти (секанс 1/cos). Дивіться також http://en.wikipedia.org/wiki/Mercator_projection#Mathematics_of_the_projection

Додавання завдяки @ jeremiah-england : хоча вищезазначене виправлення було б правильним, коли мова йде про справжні прогнози Меркатора, Веб-Меркатор (EPSG: 3857) не є Меркатором. EPSG називає це "Псевдо-Меркатор". Проблема полягає в тому, що вона використовує WGS84, еліптичну модель, і проектує її за допомогою сферичних обчислень Меркатора (які Google використовував, оскільки вони швидші). Якщо ви масштабуєте відстані за 1/cos(phi)допомогою веб-Меркатора, то на екваторі ви будете приблизно на 0,6%. Докладніші відомості див. У презентації Ноеля Зінна у веб-маркері .

Згідно з вищезгаданою презентацією, наступний метод можна було б використати для обчислення більш точних відстаней від координат веб-меркаторів. Дано dx- різниця горизонтальних координат (напрямок WE) та dy- різниця вертикальних координат (напрямок 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)

Співвідношення між цим регулюванням і cos(lat)більшим у напрямку SN, починаючи від 0.9933екватора до 1.0034полюсів. Співвідношення напрямку WE починається з 1екватора і зростає до 1.0034полюсів.

Зауважимо, що ця корекція все ще працює досить добре лише на невеликих відстанях, де можна припустити площинну геометрію поверхні Землі.

Я б розглядав ваш другий варіант зберігання ваших даних у GEOGRAPHYформаті знову, якщо ви шукаєте точних результатів на глобальних даних.

Ніщо не заважає вам мати два просторових поля в таблиці - одне в Mercator як GEOMETRYтип і друге в WGS84 як GEOGRAPHYтип (принаймні, не на SQL Server, я не впевнений у ArcSDE).

Ви повинні мати змогу створити простий скрипт для геообробки, який заповнить обидва поля своїми вихідними даними. Якщо відбувається редагування та часті оновлення, це може бути не можливим.

Після того, як у вас є два поля, ви можете продовжувати використовувати Mercator для швидкого відображення та конвертувати введені користувачем точки в Lat / Lon на відстані.

Це має дві основні переваги:

• ви також можете отримати більш точні області та довжину функцій на основі запитів користувачів
• вам не потрібно турбуватися про те, що ви забули додати спеціальний код для кожного запиту, який стосується вимірювань

Швидкість запитів буде складнішою, але це може бути непомітно для користувача. Можливо, ви захочете протестувати з одним класом функцій, перш ніж приймати рішення про рішення. Вам також доведеться конвертувати введені користувачем точки з Mercator (що має бути тривіально, і це можна зробити в браузері).

Навіть з географічним типом, хоча все ще існує помилка:

Толерантність помилок до методів географії може бути такою ж, як 1,0e-7 * розширення

Від MSDN

Альтернативна пропозиція від ESRI полягає у використанні "служби геометрії", яка передбачає надсилання геометрій на сервер ArcGIS і повернення результату. Якщо ви не очікуєте проблем із вузькими місцями за допомогою веб-сервісу, це може бути дуже ефективним підходом. Я використовував той самий підхід у програмі Silverlight.

Ось оригінальний запис у блозі від ESRI: http://blogs.esri.com/Dev/blogs/arcgisserver/archive/2010/03/05/Measuring-distances-and-areas-when-your-map-uses-the -Меркатор-проекція.aspx

У блозі є спрощений приклад JavaScript, а також тут є повний приклад програми: http://serverapps.esri.com/javascript_examples/compare_measurements.htm

Як і в Google Earth, ви можете перетворити геометрію на локальну проекцію зони WGS84 або вдосконалену проекцію WGS84, як SIRGAS в Південній Америці.

Ви можете заглянути на http://www.spatialreference.org для координат майже всіх "збільшених" проекцій, і ви могли б скласти таблицю тощо, щоб перетворити їх залежно від зони.

Ми уявляємо таблиці зон

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

всі значення minx, miny, maxx, maxy, що зберігаються в сферичному Меркаторі (Web Mercator). тому я буду використовувати приклад postgis.

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
            ))

Сподіваюся, це стане в нагоді, приємного дня.

OpenLayers мають корисний метод обчислення відстані між двома точками EPSG: 4326 (WGS84) на еліпсоїді. Оскільки OpenLayers є відкритим кодом, ви можете побачити, як це реалізовано тут: https://github.com/openlayers/openlayers/blob/release-2.12/lib/OpenLayers/Util.js#L750

Для тих, хто використовує OpenLayers та контроль Measure, просто увімкніть геодезичні параметри в літералі для використання цього обчислення.