Migliori misurazioni della distanza nella proiezione di Web Mercator

10

Sto lavorando con uno stack ESRI, archiviando i miei layer in un geodatabase sql-spatial-enabled-SDE (tipo di geometria, Web Mercator-3857).

Sto costruendo un'applicazione di web mapping, quindi per impostazione predefinita, le tessere sono anche in web mercator, 3857.

Tramite processi memorizzati, utilizzo STDistance per eseguire query sulle distanze dalla posizione di un utente (coordinate anche nel web mercator) ai vari livelli.

Il problema è che, a causa della distorsione del web mercator, i miei calcoli della distanza sono sempre più distanti, più sono lontani dall'equatore.

Ho pensato di archiviare i miei layer nel tipo sql-space-geography (piuttosto che in geometria), ma:

  • Immagino che le mie query sulla distanza richiederanno molto più tempo (calcoli della distanza sulla superficie sferica)
  • dovrò reimportare molti dati
  • i servizi arcgis non saranno così veloci come dovranno proiettare al volo

Se vado su Google Maps e faccio un calcolo della distanza, la distanza restituita è molto più accurata, anche nelle regioni del Nord / Sud, quindi presumo che Google debba correggere la distorsione causata dalla proiezione del web mercator.

La mia domanda quindi: esiste un semplice valore di fattore che può essere applicato ai calcoli di distanza eseguiti nella proiezione del web mercator per ottenere la distanza "corretta"?

coordinate-system  distance 
— Blomster
fonte

Risposte:

12

Per brevi distanze, è possibile moltiplicare la distanza calcolata per cos(lat), poiché la scala della proiezione del mercatore è proporzionale alla secante della latitudine (secante è 1/cos). Vedi anche http://en.wikipedia.org/wiki/Mercator_projection#Mathematics_of_the_projection

Addendum grazie a @ jeremiah-inghilterra : mentre la correzione di cui sopra sarebbe corretta quando si tratta di vere proiezioni di Mercatore, il Web Mercator (EPSG: 3857) non è un mercatore. EPSG lo chiama "Pseudo-Mercatore". Il problema è che usa WGS84, un modello ellittico, e lo proietta usando calcoli sferici del mercatore (che Google ha usato perché sono più veloci). Se scala le distanze 1/cos(phi)con il web Mercator, otterrete uno sconto di circa lo 0,6% all'equatore. Vedi la presentazione di Noel Zinn su Web Mercator per maggiori dettagli.

Secondo la presentazione di cui sopra, il seguente metodo potrebbe essere utilizzato per calcolare distanze più precise dalle coordinate del web mercator. Dato dx- differenza di coordinate orizzontale (direzione WE) e dy- differenza di coordinate verticale (direzione 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)

Il rapporto tra questa regolazione ed cos(lat)è maggiore nella direzione SN, che va 0.9933dall'equatore ai 1.0034poli. Il rapporto di direzione WE inizia con 1l'equatore e cresce fino 1.0034ai poli.

Si noti che questa correzione funziona ancora ragionevolmente bene solo per brevi distanze, dove si può assumere la geometria planare della superficie terrestre.

— mkadunc
fonte
1
E per distanze più lunghe, puoi usare la latitudine media dei due punti finali: cos((l1 + l2)/2)che ti darà la linea del rombo / la distanza costante del percorso, piuttosto che una distanza del grande cerchio.
— MerseyViking,
ciò cambia solo lo sferoide, ma non fornisce la stessa precisione di una proiezione locale.
— Falcacibar,
1
@falcibar - non vedo come la scelta della latitudine media cambi lo sferoide
— mkadunc,
@MerseyViking: grazie, ho dimenticato di dire che la migliore latitudine da utilizzare per il calcolo sarebbe la media dei due punti confrontati.
— mkadunc,
1
+1 per la risposta. @Mersey: Perché la correzione della latitudine media funziona? Dopotutto, le distorsioni nel Mercatore possono diventare arbitrariamente grandi e anche le deviazioni dei loxodromi dalla geodetica possono essere grandi. Sembra che ci siano alcuni errori potenzialmente enormi che potrebbero essere fatti per i quali una semplice correzione sarebbe inaffidabile.
— whuber
6

Considererei la tua seconda opzione per archiviare GEOGRAPHYnuovamente i tuoi dati nel formato se stai cercando risultati accurati sui dati globali.

Non c'è nulla che ti impedisca di avere due campi spaziali in una tabella: uno in Mercator come GEOMETRYtipo e uno in WGS84 come GEOGRAPHYtipo (almeno non in SQL Server, non sono sicuro di ArcSDE).

Dovresti essere in grado di creare un semplice script di geoprocessing che popolerà entrambi i campi con i tuoi dati originali. Se sono in corso modifiche e aggiornamenti frequenti, questa potrebbe non essere un'opzione.

Una volta che hai i due campi, puoi continuare a utilizzare Mercator per una visualizzazione rapida e convertire i punti inseriti dall'utente in Lat / Lon per le distanze.

Questo ha due vantaggi principali:

  • puoi anche ottenere aree e lunghezze più precise delle funzionalità in base alle query degli utenti
  • non devi preoccuparti di dimenticare di aggiungere un codice personalizzato per ogni query che si occupa delle misurazioni

La velocità della query sarà più complessa, ma potrebbe essere impercettibile per un utente. Potresti voler provare con una classe di funzionalità prima di decidere una soluzione. Dovrai anche convertire i punti inseriti dall'utente da Mercator (che dovrebbe essere banale e potrebbe essere fatto nel browser).

Anche con il tipo di geografia, anche se esiste ancora un margine di errore:

La tolleranza di errore per i metodi di geografia può essere estesa fino a 1,0e-7 *

Da MSDN

— geographika
fonte
Sfortunatamente SDE consentirà solo una colonna spaziale: help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//… - Non ho provato a creare una vista e registrarla con SDE, ma potrebbe essere un possibile approccio.
— Allan Adair,
@Allan - buono a sapersi. Un altro aspetto positivo dell'utilizzo di SDE allora! Una tabella con solo la geometria 4326 e un join alla tabella originale + vista spaziale dovrebbero raggiungere lo stesso scopo
— geographika,
3

Un suggerimento alternativo di ESRI è di utilizzare un "servizio di geometria", che prevede l'invio delle geometrie a un server ArcGIS e la restituzione del risultato. Se non ti aspetti problemi di collo di bottiglia utilizzando un servizio Web, questo può essere un approccio molto efficace. Ho usato lo stesso approccio in un'applicazione Silverlight.

Ecco un blog originale di ESRI: http://blogs.esri.com/Dev/blogs/arcgisserver/archive/2010/03/05/Measuring-distances-and-areas-when-your-map-uses-the -Mercator-projection.aspx

Nel blog c'è un esempio JavaScript semplificato e qui c'è anche un'applicazione di esempio completa: http://serverapps.esri.com/javascript_examples/compare_measurements.htm

— Allan Adair
fonte
0

Come fa google earth, potresti trasformare la geometria in una proiezione di zona WGS84 locale o una proiezione WGS84 migliorata come SIRGAS in Sud America.

Potresti cercare in http://www.spatialreference.org le coordinate di quasi tutte le proiezioni "zonificate", e potresti creare una tabella, ecc., Per trasformarle dipende dalla zona.

Immaginiamo una tabella di zone

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

tutti i valori minx, miny, maxx, maxy memorizzati in Spherical Mercator (Web Mercator). quindi userò i Postgis come esempio.

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

Spero sia utile, buona giornata.

— falcacibar
fonte
Non posso esserne certo, ma in base all'uso di "STDistance" di Blomster nella sua domanda sembra che non stia usando PostGIS. Se Blomster utilizza SQL Server non esiste alcuna funzionalità ST_Transform.
— Allan Adair,
Offro il processo e il modo migliore per risolverlo, potrebbe occuparsi del resto, in ogni caso potrebbe usare una riproiezione del software, ma è davvero un peccato che un SQL Server non gestisca le proiezioni.
— Falcacibar,
forse CLR abilitato e la libreria .net nettopologysuite potrebbe aiutare?
— Falcacibar,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.