Als Beispiel nehme ich die folgende Kachel http://a.tile.openstreetmap.org/3/4/2.png und speichere sie als "4_2.png".
Die WGS84-Koordinaten dieser Kachel können berechnet oder gelesen werden, indem Sie auf die entsprechende Kachel klicken:
0 66.51326044311185 45 40.97989806962013 (West North East South)So wird die Kachel korrekt georeferenziert (mithilfe von gdal wird ein Geotiff oder ein anderes georeferenziertes Format erstellt), sodass:
- Die Bitmap muss nicht gestreckt werden (= die Pixel im Geotiff sind genau die gleichen wie in der ursprünglichen Bitmap)
- Das resultierende Bild wird an der richtigen Stelle in einem GIS-Viewer / Editor geöffnet (wie zum Beispiel in TatukGIS Free Viewer ).
(Bearbeitet am 19. September 2011, um meine Frage klarer zu machen und meine Schlussfolgerungen zu berücksichtigen.)
Meine Schlussfolgerung:
Ich dachte zuerst, dass die dritte Idee (siehe unten) die richtige war. Ich habe den Geotiff in einem GIS-Viewer geöffnet und die angezeigten Koordinaten mit den erwarteten verglichen. Der Geotiff aus der zweiten Idee scheint um 2 Pixel nach Norden verschoben zu sein. Deshalb hielt ich Idee 3 (oder 4) für die richtige.
Wenn Sie jedoch eine Kachel mit einer viel höheren Zoomstufe verwenden, wird der Geotiff aus Idee 3 definitiv nach Süden verschoben. Es war albern, Koordinaten auf einer Kachel der Zoomstufe 3 zu vergleichen. Die Ländergrenzen bei dieser Zoomstufe sind vereinfacht, so dass der Vergleich keine guten Ergebnisse liefert.
Dan S. hatte recht, das Kachelbild ist bereits in EPSG: 3857. Die zweite Idee ist dann die richtige (und liefert auch bei hohen Zoomstufen gute Ergebnisse)
Erste Idee: EPSG: 4326
Der EPSG-Code für WGS84-Koordinaten lautet EPSG: 4326 . Daher benutze ich einfach die WGS84-Koordinaten, um die Kachel mit gdal_translate als Geotif zu georeferenzieren :
gdal_translate -of Gtiff -co tfw=yes -a_ullr 0 66.51326044311185 45 40.97989806962013 -a_srs EPSG:4326 4_2.png t4326.tifDie resultierende Karte wird an der richtigen Stelle angezeigt, aber ich befürchte, dass die Projektion nicht korrekt ist und es zu einer Verschiebung in der Mitte der Kachel kommen könnte. Nachdem ich lange versucht hatte, dies zu überprüfen, indem ich die Karte mit gdalwarp neu projizierte, lud ich eine Demoversion von Global Mapper herunter. Dies scheint der Fall zu sein (gleiche Rahmen wie in Idee 3, aber eine Verschiebung innerhalb der Kachel). Das Bild sollte gestreckt sein, um die EPSG: 4326-Koordinaten verwenden zu können.
Zweite Idee: EPSG: 3857
Diese Kachel verwendet eine "Web Mercator" -Projektion (alias Google Map-Projektion), die jetzt einen EPSG-Code hat: EPSG: 3857 (alias EPSG: 900913). Ich konvertiere einfach die Koordinaten mit gdaltransform :
gdaltransform -s_srs EPSG:4326 -t_srs EPSG:3857
0 66.51326044311185
0 10018754.1713946 0
45 40.97989806962013
5009377.08569731 5009377.08569731 0Meine Koordinaten in Metern sind:
0 10018754.1713946 5009377.08569731 5009377.08569731 (West North East South)Jetzt kann ich mit gdal_translate einen Geotiff erzeugen:
gdal_translate -of Gtiff -co tfw=yes -a_ullr 0 10018754.1713946 5009377.08569731 5009377.08569731 -a_srs EPSG:3857 4_2.png t3857.tifMein Eindruck ist, dass dies nicht korrekt ist, da die Grenzen der Karten nach Norden verschoben sind. Es scheint die richtige Idee zu sein.
Dritte Idee: EPSG: 3857 bis EPSG: 4055
Ich habe gelesen, dass "web mercator" WGS84-Koordinaten verwendet, sie aber so betrachtet, als ob sie sphärische Koordinaten wären. Aufgrund des Unterschieds zwischen einem geodätischen und einem geozentrischen Breitengrad (siehe Wikipedia zum Breitengrad ) sind die Breitengradwerte auf einem Ellipsoid oder einer Kugel nicht gleich. Ich fand, dass EPSG: 4055 der Code für Kugelkoordinaten auf einer Kugel ist, die auf WGS84 basiert.
Umrechnung der Koordinaten 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.84527519904Die entsprechenden Kugelkoordinaten sind dann:
0 66.3722684317026 45 40.7894557844857 (West North East South)Dann mache ich so, als ob diese Koordinaten noch auf dem Ellipsoid wären (EPSG: 4326) und konvertiere sie 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 0Die resultierenden Koordinaten unterscheiden sich von denen von idea2:
0 9979483.26733298 5009377.08569731 4981335.86590183 (West North East South)Jetzt muss ich nur noch die Koordinaten in die Karte schreiben:
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.tifDiese dritte Idee scheint die besten Ergebnisse zu liefern. Aber ich bin nicht sicher, ob es richtig ist. Wenn Idee 3 korrekt ist, gibt es einen EPSG-Code, um diesen Vorgang in einem Schritt durchzuführen?
Vierte Idee: EPSG: 3857 bis towgs84 = 0,0,0,0,0,0,0
gdal (und anscheinend auch epsg) definiert EPSG: 3857 so:
+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_defswährend spatialreference.org so aussieht:
+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_defsWenn ich die Definition von Spatialreference.org verwende, habe ich in einem Schritt die richtigen Koordinaten erhalten.
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.84527519904Warum unterscheiden sich die Definitionen von EPSG: 3857 so stark?