Web Mercator Projection에서 더 나은 거리 측정


10

ESRI 스택을 사용하여 레이어를 sql-spatial-enabled-SDE-geodatabase (Geometry type, Web Mercator-3857)에 저장하고 있습니다.

웹 매핑 응용 프로그램을 작성 중이므로 기본적으로 타일은 웹 메르카토르 인 3857에도 있습니다.

저장된 procs를 통해 STDistance를 사용하여 사용자 위치 (웹 메르카토르의 좌표)에서 다양한 레이어까지의 거리를 쿼리합니다.

문제는 웹 메르카토르의 왜곡으로 인해 거리 계산이 점점 멀어지고 적도에서 멀어지기 시작한다는 것입니다.

레이어를 지오메트리가 아닌 sql-spatial-geography 형식으로 저장하려고 생각했지만 다음과 같습니다.

  • 거리 쿼리가 훨씬 더 오래 걸릴 것이라고 생각합니다 (구면의 거리 계산)
  • 많은 데이터를 다시 가져와야합니다.
  • arcgis 서비스는 즉석에서 투영해야 할만큼 빠르지 않습니다.

Google지도로 이동하여 거리 계산을 수행하면 Nortern / 남부 지역에서도 반환 거리가 훨씬 정확하므로 Google은 웹 메르카토르 투영으로 인한 왜곡을 수정해야한다고 가정합니다.

내 질문은 다음과 같습니다. "정확한"거리를 얻기 위해 웹 메르카토르 투영에서 수행 된 거리 계산에 적용 할 수있는 간단한 요인 값이 있습니까?

답변:


12

짧은 거리의 경우, cos(lat)메르카토르 투영의 스케일이 위도의 종점에 비례하기 때문에 계산 된 거리에을 곱할 수 있습니다 (섹터는 1/cos). http://en.wikipedia.org/wiki/Mercator_projection#Mathematics_of_the_projection 참조


@ jeremiah-england 덕분에 부록 : 진정한 Mercator 투영에 대해서는 위의 수정이 정확하지만 Web Mercator (EPSG : 3857)는 Mercator가 아닙니다. EPSG는이를 "의사-메이커 레이터"라고합니다. 문제는 타원형 모델 인 WGS84를 사용하고 구형 메르카토르 계산 (Google이 더 빠르기 때문에 사용했던)을 사용하여 투영한다는 것입니다. 1/cos(phi)웹 메르카토르로 거리를 조정 하면 적도에서 약 0.6 % 할인됩니다. 자세한 내용은 Noel Zinn의 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에서 극점에 이르기까지 SN 방향에서 더 큽니다 . WE 방향 비율은 1적도에서 시작 1.0034하여 극점에서 증가합니다 .

이 보정은 지구 표면의 평면 형상을 가정 할 수있는 단거리에 대해서만 여전히 합리적으로 잘 작동합니다.


1
더 먼 거리의 경우 두 끝점의 평균 위도를 사용할 수 있습니다. cos((l1 + l2)/2)원거리가 아닌 마름모 선 / 일정한 코스 거리를 제공합니다.
MerseyViking

스페 로이드 만 변경하지만 로컬 프로젝션과 같은 정밀도를 제공하지는 않습니다.
falcacibar

1
@falcibar-평균 위도를 선택하면 회전 타원체가 어떻게 변하는 지
모르겠습니다

@MerseyViking : 감사합니다. 계산에 사용하기에 가장 좋은 위도는 두 비교 포인트의 평균이라는 것을 언급하지 않았습니다.
mkadunc

1
답변은 +1입니다. @Mersey : 평균 위도 수정이 작동하는 이유는 무엇입니까? 결국, 메르카토르의 왜곡은 임의로 커질 수 있으며 측지학에서 엽소의 이탈도 클 수 있습니다. 간단한 수정을 신뢰할 수없는 잠재적 인 엄청난 오류가있는 것 같습니다.
whuber

6

GEOGRAPHY글로벌 데이터에 대한 정확한 결과를 찾고 있다면 데이터를 형식으로 다시 저장하는 두 번째 옵션을 고려하십시오 .

테이블에 두 개의 공간 필드가있는 것을 막을 수있는 것은 없습니다. 하나는 Mercator에 하나는 GEOMETRY유형이고 다른 하나는 WGS84에 하나는 GEOGRAPHY유형입니다 (SQL Server에서는 적어도 ArcSDE에 대해서는 확실하지 않습니다).

두 필드를 모두 원래 데이터로 채우는 간단한 지오 프로세싱 스크립트를 만들 수 있어야합니다. 편집 및 빈번한 업데이트가 진행중인 경우 옵션이 아닐 수 있습니다.

두 개의 필드가 있으면 빠른 표시를 위해 메르카토르를 사용하여 계속할 수 있고, 거리를 위해 사용자가 입력 한 포인트를 위도 / 경도로 변환 할 수 있습니다.

여기에는 두 가지 주요 장점이 있습니다.

  • 또한 사용자 쿼리를 기반으로 더 정확한 영역 및 기능 길이를 얻을 수 있습니다
  • 측정을 다루는 각 쿼리마다 사용자 정의 코드를 추가하는 것을 잊어 버릴 염려가 없습니다.

쿼리 속도는 더 복잡하지만 사용자에게는 눈에 띄지 않을 수 있습니다. 솔루션을 결정하기 전에 하나의 기능 클래스로 테스트 할 수 있습니다. 또한 Mercator에서 사용자가 입력 한 포인트를 변환해야합니다 (사소하고 브라우저에서 수행 할 수 있음).

지리 유형을 사용하더라도 여전히 오류 여백이 있습니다.

지리 방법의 오류 허용 오차는 1.0e-7 * 범위만큼 클 수 있습니다.

에서 MSDN


불행히도 SDE는 하나의 공간 열만 허용합니다. help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//…- 뷰를 작성하여 SDE에 등록하려고 시도하지 않았지만 SDE에 등록하지 않았습니다. 가능한 접근 방법이 되십시오.
Allan Adair

@Allan-알아두면 좋습니다. SDE를 사용하는 것에 대한 또 다른 긍정적! 단지 4326 지오메트리 테이블과 원래의 테이블에 다시 참여할 + 같은 목적을 달성한다 공간적 뷰
geographika

3

ESRI의 다른 제안은 Geometry 서비스를 사용하는 것인데, Geometry 서비스를 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


0

Google 어스와 마찬가지로 지오메트리를 로컬 WGS84 영역 투영 또는 남미의 SIRGAS와 같은 향상된 WGS84 투영으로 변환 할 수 있습니다.

당신은에서 볼 수 있었다 http://www.spatialreference.org 거의 모든 "zonified"투사의 좌표를 위해, 그리고 당신은 그들이 영역에 따라 변환하는 등, 테이블을 만들 수 있습니다.

우리는 테이블 존을 상상

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

Spherical Mercator (Web Mercator)에 저장된 모든 minx, miny, maxx, maxy 값 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
            ))

이것이 도움이 되길 바랍니다. 좋은 하루 되세요.


확신 할 수는 없지만 Blomster의 질문에 "STDistance"를 사용한 결과 PostGIS를 사용하지 않는 것 같습니다. Blomster가 SQL Server를 사용하는 경우 ST_Transform 기능이 없습니다.
Allan Adair

프로세스와 내가 해결할 수있는 가장 좋은 방법을 제공하고 나머지를 처리 ​​할 수 ​​있으며 소프트웨어 재 투영을 사용할 수는 있지만 SQL Server가 프로젝션을 처리하지 않는 것이 유감입니다.
falcacibar

아마도 CLR을 활성화하고 .net 라이브러리 nettopologysuite가 도움이 될 수 있습니까?
falcacibar

0

OpenLayers에는 타원체에서 두 EPSG : 4326 (WGS84) 지점 사이의 거리를 계산하는 유틸리티 방법이 있습니다. OpenLayers는 오픈 소스이므로 여기에서 어떻게 구현되는지 확인할 수 있습니다 : https://github.com/openlayers/openlayers/blob/release-2.12/lib/OpenLayers/Util.js#L750

OpenLayers 및 Measure 컨트롤을 사용하는 사용자는이 계산을 사용하기 위해 리터럴 옵션에서 측지선을 활성화하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.