Более точные измерения расстояний в веб-проекции Меркатора

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

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

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

Проблема в том, что из-за искажения web mercator мои дистанционные кальки все больше отключаются, чем дальше от экватора они сделаны.

Я думал о хранении своих слоев в типе sql-пространственно-географии (а не геометрии), но:

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

Если я захожу на карты Google и вычисляю расстояние, возвращаемое расстояние будет гораздо более точным, даже в Северном / Южном регионах, поэтому я предполагаю, что Google должен исправить искажение, вызванное проекцией веб-меркатора.

Мой вопрос: есть ли простое значение коэффициента, которое можно применить к расчетам расстояний в проекции веб-меркатора, чтобы получить «правильное» расстояние?

Для коротких расстояний вы можете умножить рассчитанное расстояние на cos(lat), поскольку масштаб проекции меркатора пропорционален секущей широте (секущая - 1/cos). Также см. Http://en.wikipedia.org/wiki/Mercator_projection#Matmatics_of_the_projection

Приложение благодаря @ jeremiah-england : хотя вышеприведенная коррекция будет правильной, когда речь идет об истинных проекциях Меркатора, Web Mercator (EPSG: 3857) не является Меркатором. EPSG называет это «Псевдо-Меркатором». Проблема в том, что он использует WGS84, эллиптическую модель, и проецирует ее, используя сферические вычисления Меркатора (которые Google использовал, потому что они быстрее). Если вы масштабируете свои расстояния 1/cos(phi)с помощью веб-меркатора, вы получите примерно 0,6% скидки на экваторе. См . Презентацию Ноэля Зинна на Web Mercator для более подробной информации.

Согласно вышеупомянутому представлению, следующий метод может быть использован для вычисления более точных расстояний от координат веб-меркатора. Дано 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 для быстрого отображения и конвертировать введенные пользователем точки в широты и долготы для расстояний.

Это имеет два основных преимущества:

• Вы также можете получить более точные области и длины функций на основе пользовательских запросов
• Вам не нужно беспокоиться о том, чтобы забыть добавить собственный код для каждого запроса, который касается измерений

Скорость запросов будет более сложной, но она может быть незаметной для пользователя. Возможно, вы захотите проверить с одним классом объектов, прежде чем принять решение о решении. Вам также нужно будет конвертировать введенные пользователем точки из Mercator (что должно быть тривиально и может быть сделано в браузере).

Даже с типом географии, хотя все еще есть погрешность:

Погрешность для методов географии может достигать 1,0e-7 * экстентов

Из MSDN

Альтернативное предложение от ESRI состоит в том, чтобы использовать «Сервис геометрии», который включает в себя отправку геометрий на ArcGIS Server и получение результата. Если вы не ожидаете проблем с узким местом при использовании веб-службы, это может быть очень эффективным подходом. Я использовал тот же подход в приложении Silverlight.

Вот оригинальная запись в блоге ESRI: http://blogs.esri.com/Dev/blogs/arcgisserver/archive/2010/03/05/Measuring-distances-and-areas-when-your-map-uses-the -Mercator-projection.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 хранятся в Spherical Mercator (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, просто включите геодезические в опциях, чтобы использовать этот расчет.