gdalを使用してWebメルカトルタイルを正しくジオリファレンスする方法は?


16

例として、次のタイル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の定義にこのような違いがあるのはなぜですか?

回答:


11

タイルイメージは既にEPSG:3857にあります。参照するワールドファイルを作成しないのはなぜですか?

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

ズーム1で北米をカバーするタイルの場合、次のワールドファイルのコンテンツを見ることになります。

78271.517
0
0
-78271.517
-19998372.6
19998372.6

それらの数字の由来:

  • 行1:世界座標での画像ピクセルの幅= 20037508.342789244メートル/ 256ピクセル。
  • 2行目と3行目:回転なので、該当なし。
  • 行4:世界座標での画像ピクセルの高さ。1行目と同じですが、イメージファイルではyの増加は「下」に対応し、座標系ではyの増加は「上」に対応するためです。
  • 行5:左上のピクセルの中心の世界座標におけるX座標。これは-20037508.342789244で、タイルアラカルトリンクで報告されているように、中央に移動するためにピクセルの1/2が加えられています。
  • 6行目:同上、左上のY座標のみ。

GDALは、ワールドファイル(PNGの場合は.pgw)を取得する必要があります。コマンドラインでEPSG:3857を指定する必要があります。

(注:これをテストする時間がなかったので、それはすべてカフから外れています...しかし、とにかく最初の試行でうまくいけば!)


回答が遅くなり、ありがとうございます。しかし実際には、これは私の2番目のアイデアと同じことになると思います。gdaltransformは画像のジオリファレンスにのみ使用されます。
名前

既にEPSG:3857でタイル画像が表示されていることについては正しいです。実際の解決策は、単にEPSG:3857を使用することでした。間違っていた結果を確認するために使用した方法です。
名前

0

Webで使用されるグローバルタイルの生成に必要な機能。以下の座標変換を実装するクラスが含まれています。

  • GlobalMercator(EPSG:900913 = EPSG:3785に基づく)、Googleマップ、Yahooマップ、Microsoft Bing Maps互換タイル用

  • OpenLayersベースマップおよびGoogle Earth互換タイル用のGlobalGeodetic(EPSG:4326に基づく)

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


ありがとうございますが、私の質問には答えません。タイルを生成したくありません。タイルの正しいジオリファレンスとは何ですか?
名前

「正しい場合、この操作を1ステップで実行するEPSGコードはありますか?」回答EPSG:900913
マッパーズ

しなかった:EPSG:900913はEPSG:3857(またはEPSG:3785)のように機能し、1ステップで操作を行うことを許可していませんが、EPSG:4055を調べる必要があります。さらに、元の質問でEPSG:3857のエイリアスとしてEPSG:900913について既に言及しました。
名前

0

4番目のアイデアの私の2番目の質問について:gdalの定義とspatialreference.orgの定義の間にEPSG:3857の定義にそのような違いがあるのはなぜですか

主な違いは、gdalが「+ nadgrids = @ null」と空間参照「+ towgs84 = 0,0,0,0,0,0,0」を使用することです。ドキュメントまたはPROJ.4形式によると両方のパラメーターがデータム変換に使用されます。Proj4リストサーバーでMikael Rittriから興味深いコメントを見つけました。

"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."

「+ towgs84 = 0,0,0,0,0,0,0」を使用するのは適切ではないようです。少なくとも特定の条件下でのみです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.