例として、次のタイルhttp://a.tile.openstreetmap.org/3/4/2.pngを取得し、「4_2.png」として保存します。
このタイルのWGS84座標を計算するか、読み取ることができますが、対応するタイルをクリックして:
0 66.51326044311185 45 40.97989806962013 (West North East South)
タイルを正しくジオリファレンスする方法(gdalを使用してジオティフまたは別のジオリファレンス形式を生成する):
- ビットマップを引き伸ばす必要はありません(=ジオティフのピクセルは元のビットマップのピクセルとまったく同じです)
- 結果の画像は、GISビューア/エディタの適切な場所で開かれますか(TatukGIS Free Viewerなど)?
(2011年9月19日に編集して、質問を明確にし、結論を含めました)
私の結論:
私は最初に、3番目のアイデア(以下を参照)が正しいものであると考えました。GISビューアーでジオティフを開き、表示された座標を予想と比較しました。2番目のアイデアのジオティフは、2ピクセル北にシフトしているようです。だからこそ、私はアイデア3(または4)を正しいものと考えました。
しかし、はるかに高いズームレベルでタイルを試してみると、アイデア3からのジオティフは決定的に南にシフトします。ズームレベル3のタイル上の座標を比較するのはばかげていました。そのようなズームレベルでの国境は、比較が良い結果をもたらさないように単純化されています。
Dan S.は正しかった、タイル画像はすでにEPSG:3857にあります。2番目のアイデアは正しいアイデアです(高ズームレベルでも良い結果が得られます)
最初のアイデア:EPSG:4326
WGS84座標のEPSGコードはEPSG:4326です。そのため、単にgdal_translateを使用してWGS84座標を使用して、タイルをgeotifとしてジオリファレンスします。
gdal_translate -of Gtiff -co tfw=yes -a_ullr 0 66.51326044311185 45 40.97989806962013 -a_srs EPSG:4326 4_2.png t4326.tif
結果のマップは適切な場所に表示されますが、投影が正しくなく、タイルの中央にシフトがある可能性があります。gdalwarpを使用してマップを再投影して確認するために長い時間を試した後、Global Mapperのデモバージョンをダウンロードしました。EPSG:4326座標を使用できるように、画像をストレッチする必要があります。
2番目のアイデア:EPSG:3857
このタイルは、「web mercator」プロジェクション(エイリアスgoogleマッププロジェクション)を使用します。EPSG コードはEPSG:3857(エイリアスEPSG:900913)になりました。私は単に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
私のメートル単位の座標は次のとおりです。
0 10018754.1713946 5009377.08569731 5009377.08569731 (West North East South)
これで、gdal_translateを使用してジオティフを生成できます。
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
私の印象では、地図の境界線は北に向かって移動しているため、これは正しくありません。それは正しい考えのようです。
3番目のアイデア:EPSG:3857からEPSG:4055
「web mercator」はWGS84座標を使用しますが、球座標の場合と同じように考えていることを読みました。測地緯度と地心緯度の違い(緯度についてはWikipediaを参照)のため、楕円体または球体では緯度の値は同じではありません。EPSG:4055は、WGS84に基づく球上の球座標のコードであることがわかりました。
座標を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
対応する球面座標は次のとおりです。
0 66.3722684317026 45 40.7894557844857 (West North East South)
次に、それらがまだ楕円体(EPSG:4326)上にあるかのように座標を作成し、Webメルカトルに変換します。
gdaltransform -s_srs EPSG:4326 -t_srs EPSG:3857
0 66.3722684317026
0 9979483.26733298 0
45 40.7894557844857
5009377.08569731 4981335.86590183 0
結果の座標はidea2の座標と異なります。
0 9979483.26733298 5009377.08569731 4981335.86590183 (West North East South)
次に、座標をマップに書き込むだけです。
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
この3番目のアイデアが最良の結果をもたらすようです。しかし、それが正しいかどうかはわかりません。アイデア3が正しい場合、この操作を1ステップで実行するEPSGコードはありますか?
4番目のアイデア:EPSG:3857〜towgs84 = 0,0,0,0,0,0,0
gdal(そして明らかにepsgも)はEPSG:3857を次のように定義しています:
+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
一方、spatialreference.orgは次のようになります。
+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
spatialreference.orgの定義を使用すると、1つのステップで正しい座標が得られます(それらが「正しい」座標である場合でも、少なくともアイデア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
EPSG:3857の定義にこのような違いがあるのはなぜですか?