Lepsze pomiary odległości w internetowej projekcji Mercator

Pracuję ze stosem ESRI, przechowując moje warstwy w geobazie SDL z włączoną przestrzenią-SDE (geometria, Web Mercator-3857).

Tworzę aplikację do mapowania stron internetowych, więc domyślnie kafelki są również w mercatorze sieci, 3857.

Za pomocą przechowywanych procs używam STDistance do wyszukiwania odległości od lokalizacji użytkownika (współrzędne również w mercatorze sieciowym) do różnych warstw.

Problem polega na tym, że z powodu zniekształcenia merkatora wstęgi moje łydki dystansowe są coraz bardziej oddalone, im dalej od równika są wykonane.

Zastanawiałem się nad przechowywaniem moich warstw w typie geograficzno-przestrzennym sql (zamiast geometrii), ale:

• Wyobrażam sobie, że moje zapytania dotyczące odległości potrwają znacznie dłużej (odległość łydek na powierzchni kulistej)
• Będę musiał ponownie zaimportować dużo danych
• Usługi arcgis nie będą tak szybkie, jak będą musiały wyświetlać w locie

Jeśli przejdę do map Google i wykonam obliczenia odległości, zwrócona odległość jest znacznie dokładniejsza, nawet w regionach północnych / południowych, więc zakładam, że Google musi korygować zniekształcenia spowodowane projekcją mercatora internetowego.

Moje pytanie: czy istnieje prosta wartość współczynnika, którą można zastosować do łydek dystansowych wykonanych w projekcji merkatora internetowego, aby uzyskać „prawidłową” odległość?

W przypadku krótkich odległości można pomnożyć obliczoną odległość cos(lat), ponieważ skala rzutu mercatora jest proporcjonalna do siecznej szerokości geograficznej (sieczna jest 1/cos). Zobacz także http://en.wikipedia.org/wiki/Mercator_projection#Mathematics_of_the_projection

Dodatek dzięki @ jeremiah-england : chociaż powyższa korekta byłaby poprawna, jeśli chodzi o prawdziwe prognozy Mercatora, Web Mercator (EPSG: 3857) nie jest Mercatorem. EPSG nazywa to „pseudo-merkatorem”. Problem polega na tym, że wykorzystuje WGS84, model eliptyczny, i wyświetla go za pomocą obliczeń sferycznego merkatora (którego Google użył, ponieważ są szybsze). Jeśli przeskalujesz swoje odległości za 1/cos(phi)pomocą internetowego Mercatora, będziesz o około 0,6% zniżki na równiku. Więcej informacji można znaleźć w prezentacji Noela Zinna w Web Mercator .

Zgodnie z wyżej wspomnianą prezentacją można zastosować następującą metodę obliczania dokładniejszych odległości od współrzędnych merkatora sieci. Biorąc pod uwagę dx- pozioma różnica współrzędnych (kierunek WE), oraz dy- pionowa różnica współrzędnych (kierunek 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)

Stosunek między tą regulacją a cos(lat)jest większy w kierunku SN, od 0.9933równika do 1.0034biegunów. Współczynnik kierunku WE zaczyna się 1od równika i rośnie do 1.0034biegunów.

Zauważ, że ta korekcja nadal działa dość dobrze tylko na krótkich odległościach, gdzie można założyć płaską geometrię powierzchni Ziemi.

Rozważę drugą opcję GEOGRAPHYponownego przechowywania danych w formacie, jeśli szukasz dokładnych wyników dla danych globalnych.

Nic nie stoi na przeszkodzie, aby mieć dwa pola przestrzenne w tabeli - jedno w Mercator jako GEOMETRYtyp, a drugie w WGS84 jako GEOGRAPHYtyp (przynajmniej nie w SQL Server, nie jestem pewien co do ArcSDE).

Powinieneś być w stanie stworzyć prosty skrypt geoprzetwarzania, który zapełni oba pola twoimi oryginalnymi danymi. Jeśli trwa edycja i częste aktualizacje, może to nie być opcja.

Po uzyskaniu dwóch pól możesz kontynuować korzystanie z Mercatora do szybkiego wyświetlania i konwertować wprowadzone przez użytkownika punkty na Lat / Lon dla odległości.

Ma to dwie główne zalety:

• możesz również uzyskać dokładniejsze obszary i długości funkcji na podstawie zapytań użytkowników
• nie musisz się martwić zapomnieniem o dodaniu niestandardowego kodu do każdego zapytania dotyczącego pomiarów

Prędkości zapytania będą bardziej złożone, ale mogą być niezauważalne dla użytkownika. Przed podjęciem decyzji o rozwiązaniu warto przetestować jedną klasę funkcji. Będziesz także musiał przekonwertować wprowadzone przez użytkownika punkty z Mercatora (co powinno być trywialne i można to zrobić w przeglądarce).

Nawet przy typie geograficznym nadal istnieje margines błędu:

Tolerancja błędów dla metod geograficznych może wynosić nawet 1,0e-7 *

Z MSDN

Alternatywną sugestią ESRI jest skorzystanie z „usługi geometrii”, która polega na wysłaniu geometrii do ArcGIS Server i zwróceniu wyniku. Jeśli nie oczekujesz problemów z wąskim gardłem podczas korzystania z usługi internetowej, może to być bardzo skuteczne podejście. Użyłem tego samego podejścia w aplikacji Silverlight.

Oto oryginalny wpis na blogu ESRI: http://blogs.esri.com/Dev/blogs/arcgisserver/archive/2010/03/05/Measuring-distances-and-areas-when-your-map-uses-the -Mercator-projection.aspx

Na blogu znajduje się uproszczony przykład JavaScript, a także pełna przykładowa aplikacja tutaj: http://serverapps.esri.com/javascript_examples/compare_measurements.htm

Podobnie jak Google Earth, możesz przekształcić geometrię w lokalną projekcję strefy WGS84 lub ulepszoną projekcję WGS84, taką jak SIRGAS w Ameryce Południowej.

Możesz szukać na http://www.spatialreference.org współrzędnych prawie wszystkich „strefowych” rzutów i możesz zrobić tabelę itp., Aby przekształcić je w zależności od strefy.

Wyobrażamy sobie strefy stołu

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

wszystkie wartości minx, miny, maxx, maxy przechowywane w Spherical Mercator (Web Mercator). użyję postgis jako przykładu.

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

Mam nadzieję, że będzie to przydatne, miłego dnia.

OpenLayers mają użyteczną metodę obliczania odległości między dwoma punktami EPSG: 4326 (WGS84) na elipsoidzie. Ponieważ OpenLayers jest oprogramowaniem typu open source, możesz zobaczyć, jak jest zaimplementowany tutaj: https://github.com/openlayers/openlayers/blob/release-2.12/lib/OpenLayers/Util.js#L750

Dla tych, którzy używają OpenLayers i kontrolki Measure, po prostu włącz geodezyjną w opcjach literalnych, aby użyć tego obliczenia.