Як правильно встановити геореференцію плитки веб-меркатора за допомогою 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 для створення геотифів чи іншого формату геореференції), щоб:

• Растрову карту не потрібно розтягувати (= пікселі в геотифі точно такі ж, як у вихідній растровій карті)
• Отримане зображення буде відкрито в потрібному місці в ГІС-переглядачі / редакторі (як, наприклад, у TatukGIS Free Viewer )?

(Відредаговано 19 вересня 2011 р., Щоб зробити моє питання зрозумілішим та включити мої висновки)

Мій висновок:

Я спершу, хоча третя ідея (див. Нижче) була правильною. Я відкрив геотиф у GIS Viewer і порівняв відображені координати з тим, що очікував. Здається, геотиф з другої ідеї зміщений на 2 пікселі на північ. Тому я вважав ідею 3 (або 4) правильною.
Але якщо спробувати плитку на значно більшому рівні масштабування, геотиф із ідеї 3 остаточно зміщується на південь. Порівнювати координати на плитці масштабу 3 було нерозумно. Межі країни на такому рівні масштабування спрощені, щоб порівняння не дало хороших результатів.

Ден С. мав рацію, зображення плитки вже в EPSG: 3857. Тоді друга ідея - це правильна (і дає хороший результат і при високому рівні збільшення)

Перша ідея: EPSG: 4326
Код EPSG для координат WGS84 - це EPSG: 4326 . Тому я просто використовую координати WGS84, щоб геореферувати плитку як геотиф, використовуючи 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
Ця плитка використовує проекцію "web mercator" (псевдонім проекція google map), який тепер має код 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

Моє враження, що це неправильно, оскільки кордони карт зміщені на північ. Здається, це правильна ідея.

Третя ідея: EPSG: 3857 через EPSG: 4055
Я читав, що "веб-меркатор" використовує координати 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), і перетворюю їх у веб-меркатор:

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 через буксири84 = 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

беручи до уваги, що просторовий референс.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

Якщо я використовую визначення просторової референції.org, я отримав правильні координати за один крок (ну, я все одно не знаю, якщо вони є "правильними" координатами, але принаймні вони є самими, як ідея 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, ви подивитеся на такий вміст всесвітнього файлу:

78271.517
0
0
-78271.517
-19998372.6
19998372.6

Звідки ці цифри:

• Рядок 1: ширина пікселя зображення у світових координатах = 20037508.342789244 метри / 256 пікселів.
• Рядок 2 і 3: обертання, так н / а.
• Рядок 4: висота пікселя зображення у світових координатах. Так само, як і рядок 1, але негативний, оскільки у файлах зображень збільшення y відповідає "вниз", а в системі координат, збільшення y відповідає "вгору".
• Рядок 5: Х координата у світових координатах центру лівого верхнього пікселя. Це -20037508.342789244, як повідомляється плиткою a la carte, плюс 1/2 пікселя, щоб перенести його в центр.
• Рядок 6: Дітто, лише координата Y зліва вгорі.

GDAL повинен забрати ваш світовий файл (.pgw для png); вам все одно доведеться сказати це в командному рядку EPSG: 3857.

(Примітка: не встигли це перевірити, тому все з манжети ... але сподіваємось, виправдайте при першій спробі все-таки!)

Функції, необхідні для генерації глобальних плиток, що використовуються в Інтернеті. Він містить класи, що здійснюють перетворення координат для:

• GlobalMercator (на основі EPSG: 900913 = EPSG: 3785 ) для сумісних плиток Карт Google, Yahoo Maps, Microsoft Bing Maps

• GlobalGeodetic (заснований на EPSG: 4326) для базової карти OpenLayers та сумісних плиток Google Earth

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

Про моє вторинне запитання в четвертих ідеях: Чому існує така різниця у визначеннях EPSG: 3857 між визначенням у gdal та на просторіreference.org :

Основна відмінність полягає в тому, що gdal використовує "+ nadgrids = @ null" і просторову референцію "+ towgs84 = 0,0,0,0,0,0,0". Відповідно до документації або формату PROJ.4 обидва параметри використовуються для перетворень даних. Я знайшов цікавий коментар Мікаеля Рітрі на сервері списку 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."

Використання "+ буксирів84 = 0,0,0,0,0,0,0" не здається правильним або принаймні лише в конкретних умовах.