Come georeferenziare correttamente una piastrella web mercator usando gdal?

16

Come esempio prenderò la seguente piastrella http://a.tile.openstreetmap.org/3/4/2.png e la salverò come "4_2.png".

Le coordinate WGS84 di questo piastrelle possono essere calcolati o leggere lì cliccando piastrella corrispondente:

0 66.51326044311185 45 40.97989806962013 (West North East South)

Come georeferenziare correttamente il riquadro (usando gdal per generare un geotiff o un altro formato georeferenziato) in modo che:

Non è necessario allungare la bitmap (= i pixel nel geotiff sono esattamente gli stessi della bitmap originale)
L'immagine risultante verrà aperta nel posto giusto in un visualizzatore / editor GIS (come ad esempio in TatukGIS Free Viewer )?

(Modificato il 19 settembre 2011 per chiarire la mia domanda e includere le mie conclusioni)

La mia conclusione:

Prima ho pensato che la terza idea (vedi sotto) fosse quella giusta. Ho aperto il geotiff in un GIS Viewer e ho confrontato le coordinate visualizzate con quello che mi aspettavo. Il geotiff della seconda idea sembra essere spostato di 2 pixel verso nord. Ecco perché ho considerato l'idea 3 (o 4) come quella giusta.
Ma se provi con una tessera a un livello di zoom molto più alto, il geotiff dell'idea 3 viene spostato definitivamente verso sud. È stato sciocco confrontare le coordinate su un riquadro del livello di zoom 3. I confini del paese a tale livello di zoom sono semplificati in modo che il confronto non dia buoni risultati.

Dan S. aveva ragione, l'immagine della piastrella è già in EPSG: 3857. La seconda idea è quindi quella giusta (e dà buoni risultati anche a livelli di zoom elevati)

Prima idea: EPSG: 4326
Il codice EPSG per le coordinate WGS84 è EPSG: 4326 . Quindi uso semplicemente le coordinate WGS84 per georefence la piastrella come geotif usando gdal_translate :

gdal_translate -of Gtiff -co tfw=yes -a_ullr 0 66.51326044311185 45 40.97989806962013 -a_srs EPSG:4326 4_2.png t4326.tif

La mappa risultante viene visualizzata nel posto giusto ma temo che la proiezione non sia corretta e che ci possa essere uno spostamento nel mezzo della piastrella. Dopo aver provato a lungo per verificarlo riproiettando la mappa con gdalwarp, ho scaricato una versione demo di Global Mapper e questo sembra essere il caso (i bordi sono come nell'idea 3 ma uno spostamento all'interno della tessera). L'immagine dovrebbe essere allungata per poter usare EPSG: 4326 coordinate.

Seconda idea: EPSG: 3857
Questa tessera utilizza una proiezione "web mercator" (alias google map projection), che ora ha un codice EPSG: EPSG: 3857 (alias EPSG: 900913). Semplicemente converto le coordinate usando gdaltransform :

gdaltransform -s_srs EPSG:4326 -t_srs EPSG:3857
0 66.51326044311185
0 10018754.1713946 0
45 40.97989806962013
5009377.08569731 5009377.08569731 0

Le mie coordinate in metri sono:

0 10018754.1713946 5009377.08569731 5009377.08569731 (West North East South)

Ora posso usare gdal_translate per generare un geotiff:

gdal_translate -of Gtiff -co tfw=yes -a_ullr 0 10018754.1713946 5009377.08569731 5009377.08569731 -a_srs EPSG:3857 4_2.png t3857.tif

~~La mia impressione è che ciò non sia corretto perché i bordi delle mappe sono spostati verso nord.~~ Sembra essere l'idea giusta.

Terza idea: da EPSG: 3857 a EPSG: 4055
Ho letto che "web mercator" usa le coordinate WGS84 ma le considero come se fossero coordinate sferiche. A causa della differenza tra una latitudine geodetica e una geocentrica (Vedi Wikipedia sulla latitudine ), i valori di latitudine non saranno gli stessi su un ellissoide o su una sfera. Ho scoperto che EPSG: 4055 è il codice per coordinate sferiche su una sfera basata su WGS84.

Conversione delle coordinate in EPSG: 4055:

gdaltransform -s_srs EPSG:4326 -t_srs EPSG:4055
0 66.51326044311185
0 66.3722684317026 -17964.0621483233
45 40.97989806962013
45 40.7894557844857 -9152.84527519904

Le coordinate sferiche corrispondenti sono quindi:

0 66.3722684317026 45 40.7894557844857 (West North East South)

Quindi faccio come se quelle coordinate fossero ancora sull'ellissoide (EPSG: 4326) e le converto in web mercator:

gdaltransform -s_srs EPSG:4326 -t_srs EPSG:3857
0 66.3722684317026
0 9979483.26733298 0
45 40.7894557844857
5009377.08569731 4981335.86590183 0

Le coordinate risultanti differiscono da quella di idea2:

0 9979483.26733298 5009377.08569731 4981335.86590183 (West North East South)

Ora devo solo scrivere le coordinate nella mappa:

gdal_translate -of Gtiff -co tfw=yes -a_ullr 0 9979483.26733298 5009377.08569731 4981335.86590183 -a_srs EPSG:3857 4_2.png t3857_through_4055.tif

~~Questa terza idea sembra dare i migliori risultati.~~ Ma non sono sicuro che sia corretto. Se l'idea 3 è corretta, esiste un codice EPSG per eseguire questa operazione in un solo passaggio?

Quarta idea: EPSG: 3857 attraverso towgs84 = 0,0,0,0,0,0,0,0

gdal (e apparentemente anche epsg) definisce EPSG: 3857 in questo modo:

+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs

considerando che spatialreference.org in questo modo:

+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=6378137 +b=6378137 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

Se uso la definizione di spatialreference.org, ho ottenuto le coordinate ~~corrette~~ in un solo passaggio (beh, non lo so se sono le coordinate "corrette" ma almeno sono le stesse come nell'idea 3):

gdaltransform -s_srs EPSG:4326 -t_srs "+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=6378137 +b=6378137 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs"
0 66.51326044311185
0 9979483.26733298 -17964.0621483233
45 40.97989806962013
5009377.08569731 4981335.86590183 -9152.84527519904

Perché c'è una tale differenza nelle definizioni di EPSG: 3857?

— Nome
fonte

11

L'immagine della piastrella è già in EPSG: 3857. Perché non creare semplicemente un file mondiale per fare riferimento a esso?

http://en.wikipedia.org/wiki/World_file

Per la tessera che copre N. America allo zoom 1, dovresti guardare i seguenti contenuti del file mondiale:

78271.517
0
0
-78271.517
-19998372.6
19998372.6

Da dove provengono quei numeri:

Linea 1: larghezza di un pixel dell'immagine in coordinate mondiali = 20037508.342789244 metri / 256 pixel.
Riga 2 e 3: rotazione, quindi n / a.
Linea 4: altezza di un pixel dell'immagine in coordinate mondiali. Come la riga 1 ma negativa, perché nei file di immagine l'aumento di y corrisponde a "giù" mentre nel sistema di coordinate, l'aumento di y corrisponde a "su".
Linea 5: coordinata X in coordinate mondiali del centro del pixel in alto a sinistra. Questo è -20037508.342789244, come riportato dal link a la carte delle tessere, più 1/2 di un pixel per portarlo al centro.
Linea 6: Idem, solo coordinate Y in alto a sinistra.

GDAL dovrebbe raccogliere il tuo file del mondo (.pgw per il png); dovrai ancora dirlo EPSG: 3857 dalla riga di comando.

(Nota: non ho avuto il tempo di testarlo, quindi è tutto fuori dal polsino ... ma spero che sia corretto al primo tentativo comunque!;)

— Dan S.
fonte

Grazie e scusa per la risposta tardiva. Ma in realtà penso che questo porterebbe alla stessa cosa della mia seconda idea, in cui gdaltransform è davvero usato solo per georeferenziare l'immagine.

— Nome

Avevi ragione sull'immagine della piastrella già presente in EPSG: 3857. La soluzione era in realtà semplicemente usare EPSG: 3857. È il modo in cui controllavo i risultati che erano sbagliati.

— Nome

0

Funzioni necessarie per la generazione di riquadri globali utilizzati sul Web. Contiene classi che implementano conversioni coordinate per:

GlobalMercator (basato su EPSG: 900913 = EPSG: 3785 ) per Google Maps, Yahoo Maps, tessere compatibili con Microsoft Bing Maps
GlobalGeodetic (basato su EPSG: 4326) per OpenLayers Base Map e riquadri compatibili con Google Earth

http://svn.osgeo.org/gdal/sandbox/klokan/gdal2tiles.py

— Mapperz
fonte

Grazie ma non risponde alla mia domanda. Non voglio generare tessere. Voglio sapere qual è / sarebbe la corretta georeferenziazione delle tessere.

— Nome

Ho fatto "Se è corretto, esiste un codice EPSG per eseguire questa operazione in un solo passaggio?" Risposta EPSG: 900913

— Mapperz

Non hai fatto: EPSG: 900913 funziona come EPSG: 3857 (o come EPSG: 3785) e non consente di eseguire l'operazione in un solo passaggio, è comunque necessario superare EPSG: 4055. Inoltre avevo già menzionato EPSG: 900913 come alias per EPSG: 3857 nella mia domanda originale.

— Nome

0

Informazioni sulla mia domanda secondaria nella quarta idea: perché esiste una tale differenza nelle definizioni di EPSG: 3857 tra la definizione in gdal e su spatialreference.org :

La differenza principale è che gdal usa "+ nadgrids = @ null" e riferimento spaziale "+ towgs84 = 0,0,0,0,0,0,0". Secondo la documentazione o il formato PROJ.4 entrambi i parametri vengono utilizzati per le trasformazioni di riferimento. Ho trovato un commento interessante di Mikael Rittri sull'elenco server Proj4 :

"The +to definition you suggest is not correct for WGS84 Web Mercator, though.
This is because the datum shift you use, 

   +towgs84=0,0,0,0,0,0,0

is not the same as unmodified lat/long, or "without any datum shift" as you say.
It means "no datum shift" only if the +from and +to definitions use the same ellipsoid,
and in your case the +from definition uses the WGS84 ellipsoid, while the +to definition
uses a sphere instead.  

So, you have to use a trick: use 

   +nadgrids=@null 

instead."

L'uso di "+ towgs84 = 0,0,0,0,0,0,0" non sembra essere corretto o almeno solo in determinate condizioni.

— Nome
fonte