Web Mercator döşemesini gdal kullanarak doğru bir şekilde nasıl başvurulur?


16

Örnek olarak şu döşemeyi http://a.tile.openstreetmap.org/3/4/2.png alacağım ve "4_2.png" olarak kaydedeceğim.

Bu döşemenin WGS84 koordinatları , ilgili döşemeyi tıklatarak hesaplanabilir veya orada okunabilir :

0 66.51326044311185 45 40.97989806962013 (West North East South)

Döşemenin doğru bir şekilde coğrafi olarak nasıl referanslandırılması (bir geotiff veya başka bir coğrafi referanslı format oluşturmak için gdal kullanarak):

  • Bitmap'in uzatılmasına gerek yoktur (= geotiff'deki pikseller orijinal bitmap'dekiyle tamamen aynıdır)
  • Ortaya çıkan görüntü bir CBS görüntüleyici / editöründe doğru yerde açılacaktır (örneğin TatukGIS Free Viewer'da olduğu gibi )?

(Sorumu netleştirmek ve sonuçlarımı dahil etmek için 19 Eylül 2011'de düzenlendi)


Benim sonucum:

İlk olarak üçüncü fikrin (aşağıya bakınız) doğru olduğunu düşünüyorum. Geotiff'i bir CBS Görüntüleyicisi'nde açtım ve görüntülenen koordinatları beklediğim ile karşılaştırdım. İkinci fikrin coğrafi konumu 2 piksel kuzeye doğru kaymış gibi görünüyor. Bu yüzden 3. fikri (veya 4) doğru fikir olarak gördüm.
Ancak, daha yüksek bir zum seviyesinde bir karo ile denerseniz, fikir 3'ün geotiff'i kesinlikle güneye doğru kaydırılır. Zoom seviyesi 3 döşemesindeki koordinatları karşılaştırmak aptalcaydı.

Dan S. haklıydı, fayans görüntüsü zaten EPSG'de: 3857. İkinci fikir o zaman doğru olanıdır (ve yüksek zoom seviyelerinde de iyi sonuç verir)


İlk fikir: EPSG: 4326
WGS84 koordinatları için EPSG kodu EPSG: 4326'dır . Ben sadece kullanarak geotif olarak karo georefence için WGS84 koordinatları kullanmak Yani 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

Ortaya çıkan harita doğru yerde görüntülenir, ancak projeksiyonun doğru olmadığından ve karonun ortasında bir değişiklik olabileceğinden korkuyorum. Gdalwarp ile haritayı yeniden projelendirerek uzun bir süre denedikten sonra, Global Mapper'ın demo sürümünü indirdim ve bu durum böyle görünüyor (fikir 3'te olduğu gibi sınırları döşer, ancak karo içinde bir değişiklik). EPSG: 4326 koordinatlarını kullanabilmek için görüntünün gerilmesi gerekir.


İkinci fikir: EPSG: 3857
Bu kutucuk , artık bir EPSG kodu olan bir "web mercator" projeksiyonu (takma ad google harita projeksiyonu) kullanıyor: EPSG: 3857 (takma EPSG: 900913). Sadece gdaltransform kullanarak koordinatları dönüştürmek :

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

Metre cinsinden koordinatlarım:

0 10018754.1713946 5009377.08569731 5009377.08569731 (West North East South)

Şimdi kullanabilirsiniz gdal_translate bir GeoTIFF oluşturmak için:

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

Benim izlenimim bunun doğru olmadığı için haritaların sınırları kuzeye doğru kaymış. Doğru fikir gibi görünüyor.


Üçüncü fikir: EPSG: 3857 - EPSG: 4055
"Web mercator" ın WGS84 koordinatlarını kullandığını okudum ama bunları küresel koordinatların olduğu sanki sanıyorum. Bir jeodezik ve bir jeosantrik enlem arasındaki farktan dolayı (Enlem hakkında Wikipedia'ya bakın ), enlem değerleri elipsoid veya küre üzerinde aynı olmayacaktır. EPSG: 4055'in WGS84 tabanlı bir küre üzerindeki küresel koordinatların kodu olduğunu buldum .

Koordinatları EPSG: 4055'e dönüştürme:

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

Karşılık gelen küresel koordinatlar şu şekilde olur:

0 66.3722684317026 45 40.7894557844857 (West North East South)

Sonra hala elipsoid (EPSG: 4326) üzerinde nerede koordinatları yapmak ve bunları web mercator dönüştürmek:

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

Ortaya çıkan koordinatlar idea2 ile olanlardan farklıdır:

0 9979483.26733298 5009377.08569731 4981335.86590183 (West North East South)

Şimdi sadece koordinatları haritaya yazmam gerekiyor:

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

Bu üçüncü fikir en iyi sonuçları veriyor gibi görünüyor. Ama doğru olup olmadığından emin değilim. Fikir 3 doğruysa, bu işlemi bir adımda yapmak için bir EPSG kodu var mı?


Dördüncü fikir: EPSG: 3857 - towgs84 = 0,0,0,0,0,0,0

gdal (ve görünüşte epsg de) EPSG: 3857'yi şöyle tanımlar:

+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

oysa spatialreference.org böyle:

+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

Eğer spatialreference.org tanımını kullanırsam bir adımda doğru koordinatları elde ettim ("Doğru" koordinatlarsa yine de bilmiyorum ama en azından fikir 3'teki isimler bunlar):

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 tanımlarında neden böyle bir fark var?

Yanıtlar:


11

Döşeme görüntüsü zaten EPSG: 3857'de. Neden sadece referans olarak bir dünya dosyası oluşturmuyorsunuz?

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

Zoom 1'de N. America'yı kapsayan karo için aşağıdaki dünya dosyası içeriğine bakacaksınız:

78271.517
0
0
-78271.517
-19998372.6
19998372.6

Bu sayılar nereden geldi:

  • Çizgi 1: dünya koordinatlarındaki bir görüntü pikselinin genişliği = 20037508.342789244 metre / 256 piksel.
  • Satır 2 ve 3: dönüş, yani yok.
  • Çizgi 4: Dünya koordinatlarında bir görüntü pikselinin yüksekliği. Satır 1 ile aynıdır ancak negatiftir, çünkü resim dosyalarında koordinat sisteminde y'nin artması 'aşağı' ya karşılık gelir, y'nin artması 'yukarı' ya karşılık gelir.
  • Çizgi 5: Sol üst pikselin merkezinin dünya koordinatlarındaki X koordinatı. Bu, karolar tarafından alakart bir bağlantı ile bildirildiği gibi -20037508.342789244 ve merkeze getirmek için bir pikselin 1 / 2'si.
  • Satır 6: Aynen, sol üst tarafın yalnızca Y koordinatı.

GDAL, worldfile'nizi almalıdır (png için .pgw); hala komut satırında EPSG: 3857'yi söylemelisiniz.

(Not: bunu test etmek için zaman yoktu, bu yüzden hepsi manşet kapalı ... ama umarım yine de ilk denemede düzeltin!;)


Teşekkürler ve geç cevap verdiğim için üzgünüm. Ama aslında bu, gdaltransform'un gerçekten sadece görüntüyü coğrafi olarak referanslamak için kullanıldığı ikinci fikrimle aynı şeye yol açacağını düşünüyorum.
İsim

EPSG: 3857'de zaten kiremit görüntüsü konusunda haklıydınız. Çözüm aslında EPSG: 3857 kullanmaktı. Yanlış sonuçları kontrol etmek için kullandım.
Ad

0

Web üzerinde kullanılan global karo üretimi için gerekli işlevler. Aşağıdakiler için koordinat dönüşümleri uygulayan sınıflar içerir:

  • Google Haritalar, Yahoo Maps, Microsoft Bing Maps uyumlu döşemeler için GlobalMercator ( EPSG: 900913 = EPSG: 3785 tabanlı )

  • OpenLayers Temel Haritası ve Google Earth uyumlu karolar için GlobalGeodetic (EPSG: 4326 tabanlı)

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


Teşekkür ederim ama soruma cevap vermiyor. Fayans üretmek istemiyorum. Fayansların doğru coğrafi referansının ne olduğunu / olacağını bilmek istiyorum.
İsim

Ben "Doğru ise, bir adımda bu işlemi yapmak için bir EPSG kodu var mı?" Cevap EPSG: 900913
Mapperz

EPSG: 900913, EPSG: 3857 (veya EPSG: 3785 gibi) gibi çalışmadı ve işlemi bir adımda yapmaya izin vermiyor, yine de EPSG: 4055'i geçmeniz gerekiyor. Üstelik orijinal sorumda EPSG: 900913'ü EPSG: 3857 için bir takma ad olarak daha önce de belirtmiştim.
İsim

0

Dördüncü fikirlerdeki ikincil sorum hakkında: EPSG: 3857'nin tanımlarında, gdal'daki tanım ile spatialreference.org'daki neden böyle bir fark var :

Temel fark, gdal'ın "+ nadgrids = @null" ve uzamsal referans "+ towgs84 = 0,0,0,0,0,0,0" kullanmasıdır. Göre belgelerde veya PROJ.4 biçiminde iki parametre veri dönüşümler için kullanılır. Proj4 listserver'da Mikael Rittri'den ilginç bir yorum buldum :

"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" kullanımı doğru görünmüyor ya da en azından belirli koşullar altında.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.