วิธีการระบุตำแหน่งของ Web Mercator ไทล์อย่างถูกต้องโดยใช้ gdal?

ตัวอย่างฉันจะใช้ไทล์ต่อไปนี้http://a.tile.openstreetmap.org/3/4/2.pngและบันทึกเป็น "4_2.png"

พิกัด WGS84 ของไทล์นี้สามารถคำนวณหรืออ่านได้ที่นั่นโดยคลิกที่ไทล์ที่สอดคล้องกัน:

0 66.51326044311185 45 40.97989806962013 (West North East South)

วิธีการระบุตำแหน่งทางภูมิศาสตร์ของกระเบื้องอย่างถูกต้อง (โดยใช้ gdal เพื่อสร้างรูปแบบ geotiff หรือรูปแบบทางภูมิศาสตร์อื่น ๆ ) เพื่อให้:

• ไม่จำเป็นต้องยืดบิตแมป (= พิกเซลใน geotiff ตรงกับในบิตแมปดั้งเดิม)
• ภาพที่ได้จะเปิดขึ้นในตำแหน่งที่ถูกต้องใน GIS viewer / editor (เช่นในTatukGIS Free Viewer )

(แก้ไขเมื่อวันที่ 19 กันยายน 2011 เพื่อทำให้คำถามของฉันชัดเจนขึ้นและรวมถึงข้อสรุปของฉัน)

บทสรุปของฉัน:

ฉันก่อนว่าแนวคิดที่สาม (ดูด้านล่าง) เป็นแนวคิดที่ถูกต้อง ฉันเปิด geotiff ใน GIS Viewer และเปรียบเทียบพิกัดที่แสดงกับสิ่งที่ฉันคาดไว้ geotiff จากแนวคิดที่สองดูเหมือนว่าจะถูกเลื่อน 2 พิกเซลไปทางทิศเหนือ นั่นคือเหตุผลที่ฉันถือว่าความคิดที่ 3 (หรือ 4) เป็นแนวคิดที่ถูกต้อง
แต่ถ้าคุณลองเรียงต่อกันที่ระดับการซูมที่สูงขึ้นมากพิกัดจากแนวคิด 3 จะเปลี่ยนไปทางทิศใต้อย่างแน่นอน มันเป็นเรื่องโง่ที่จะเปรียบเทียบพิกัดบนไทล์ของระดับการซูม 3 ขอบเขตของประเทศที่ระดับการซูมดังกล่าวนั้นง่ายขึ้นเพื่อให้การเปรียบเทียบไม่ให้ผลลัพธ์ที่ดี

แดนเอสนั้นถูกต้องภาพย่อยมีอยู่แล้วใน EPSG: 3857 แนวคิดที่สองคือแนวคิดที่ถูกต้อง (และให้ผลที่ดีในระดับการซูมสูงเช่นกัน)

ความคิดแรก: EPSG: 4326
รหัส EPSG พิกัด WGS84 เป็นEPSG: 4326 ดังนั้นฉันเพียงแค่ใช้พิกัด WGS84 เพื่อ georefence กระเบื้องเป็น geotif โดยใช้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

แผนที่ผลลัพธ์ปรากฏขึ้นในตำแหน่งที่ถูกต้อง แต่ฉันกลัวว่าการฉายภาพไม่ถูกต้องและอาจมีการเลื่อนกลางแผ่น หลังจากลองใช้เวลานานในการตรวจสอบว่าด้วยการปฏิเสธแผนที่ด้วย gdalwarp ฉันดาวน์โหลดGlobal Mapperรุ่นตัวอย่างและนี่น่าจะเป็นกรณี (เส้นขอบตามแนวคิด 3 แต่การเปลี่ยนแปลงภายในแผ่นกระเบื้อง) ภาพควรถูกสตริปเพื่อให้สามารถใช้ EPSG: 4326 พิกัดได้

แนวคิดที่สอง: EPSG: 3857 ไท
ล์นี้ใช้การฉาย "เว็บ 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เพื่อสร้าง 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

ความประทับใจของฉันคือสิ่งนี้ไม่ถูกต้องเพราะขอบของแผนที่ถูกเลื่อนไปทางทิศเหนือ ดูเหมือนจะเป็นความคิดที่ถูกต้อง

แนวคิดที่สาม: EPSG: 3857 ถึง EPSG: 4055
ฉันอ่านว่า "web mercator" ใช้พิกัด WGS84 แต่ให้พิจารณาราวกับว่าพวกมันอยู่ที่ไหนที่พิกัดทรงกลม เนื่องจากความแตกต่างระหว่างละติจูดและลองจิจูดทางภูมิศาสตร์ (ดูวิกิพีเดียเกี่ยวกับละติจูด ) ค่าละติจูดจะไม่เหมือนกันในทรงรีหรือทรงกลม ฉันพบว่า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) และแปลงเป็นเว็บ 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

พิกัดที่ได้นั้นแตกต่างจากความคิด 2:

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 ถูกต้องมีรหัส EPSG เพื่อดำเนินการนี้ในขั้นตอนเดียวหรือไม่?

แนวคิดที่สี่: 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 ฉันได้รับพิกัดที่ถูกต้องในขั้นตอนเดียว (แต่ฉันก็ยังไม่ได้ถ้าพวกเขาเป็นพิกัด "ถูกต้อง" แต่อย่างน้อยพวกเขาก็เป็น sames ตามแนวคิด 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

ภาพย่อยมีอยู่แล้วใน EPSG: 3857 ทำไมไม่สร้างไฟล์โลกขึ้นเพื่ออ้างอิง?

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

สำหรับไทล์ที่ครอบคลุม N. America เมื่อซูม 1 คุณจะต้องดูเนื้อหา worldfile ต่อไปนี้:

78271.517
0
0
-78271.517
-19998372.6
19998372.6

ตัวเลขเหล่านั้นมาจากไหน:

• บรรทัดที่ 1: ความกว้างของพิกเซลภาพในพิกัดโลก = 20037508.342789244 เมตร / 256 พิกเซล
• บรรทัดที่ 2 และ 3: การหมุนดังนั้น n / a
• บรรทัดที่ 4: ความสูงของพิกเซลภาพในพิกัดโลก เหมือนกับบรรทัด 1 แต่เป็นลบเนื่องจากในไฟล์รูปภาพที่เพิ่มขึ้น y สอดคล้องกับ 'ลง' ขณะที่อยู่ในระบบพิกัดเพิ่มขึ้น y สอดคล้องกับ 'ขึ้น'
• บรรทัดที่ 5: X พิกัดในพิกัดโลกของจุดกึ่งกลางของพิกเซลซ้ายบน นี่คือ -20037508.342789244 ซึ่งได้รับการรายงานโดยกระเบื้องเชื่อมโยงรายการตามสั่งบวก 1/2 ของพิกเซลเพื่อนำมาไว้ที่กึ่งกลาง
• บรรทัดที่ 6: เหมือนกันพิกัด Y ของซ้ายบนเท่านั้น

GDAL ควรจะรับ worldfile ของคุณ (.pgw สำหรับ png); คุณจะต้องบอก EPSG: 3857 ในบรรทัดคำสั่ง

(หมายเหตุ: ไม่มีเวลาทดสอบสิ่งนี้ดังนั้นจึงเป็นผ้าพันแขน ... แต่หวังว่าจะถูกต้องในการลองครั้งแรก!

ฟังก์ชั่นที่จำเป็นสำหรับการสร้างไทล์โกลบอลที่ใช้บนเว็บ มันมีชั้นเรียนดำเนินการแปลงประสานงานสำหรับ:

• GlobalMercator (อิงจากEPSG: 900913 = EPSG: 3785 ) สำหรับ Google Maps, Yahoo Maps, Microsoft Bing Maps

• GlobalGeodetic (อิงจาก EPSG: 4326) สำหรับ OpenLayers Base Map และการทำงานร่วมกันของ Google Earth

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

เกี่ยวกับคำถามที่สองของฉันในแนวคิดที่สี่: เหตุใดจึงมีความแตกต่างในคำจำกัดความของ EPSG: 3857 ระหว่างคำจำกัดความใน gdal และspatialreference.org :

ความแตกต่างที่สำคัญคือ gdal ใช้ "+ nadgrids = @ null" และ spatialreference "+ towgs84 = 0,0,0,0,0,0,0,0" ตามเอกสารหรือรูปแบบ PROJ.4ทั้งสองพารามิเตอร์จะใช้สำหรับการแปลงตัวเลข ฉันพบความคิดเห็นที่น่าสนใจจาก Mikael Rittri บน listserver 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."

การใช้ "+ towgs84 = 0,0,0,0,0,0,0,0" ดูเหมือนจะไม่ถูกต้องหรืออย่างน้อยก็เพียงภายใต้เงื่อนไขเฉพาะ