ASCII grid bug - кто прав: ENVI, Surfer или GM?

[DCT]

Есть такой нехороший баг, который я уже давно подметил: небольшое "уплывание" привязок при работе с данными в .asc формате (это простая таблица значений с указанием в заголовке координат угла и шага растра). Глюк появляется при "перетаскивании" данных между разными пакетами.
Простой демонстрационный кейс.

Тестовый tiff 20x30 с таким world файлом

Код: Выделить всё

0.5
0
0
-0.5
20.25
49.75 

Открываю его в вышеперечисленном софте и сохраняю в ASCII grid. Полученные файлы не отличаются данными, а вот отличия из заголовков:
ENVI 5.2
xllcorner 20.000
yllcorner 35.500

Global Mapper 17.2
xllcorner 20
yllcorner 35

Surfer 12
xllcorner 19.75
yllcorner 34.75

Это вообще как?! Разработчики 2-х из 3-х пакетов до сих пор не научились решать школьную задачу о нахождении координат углов?!

Если я не ошибаюсь , то согласно Википедии 20.25 49.75 - это координаты центра верхнего левого пикселя. Т.е. координаты нижнего угла левого нижнего пикселя будут 20.25-0.5/2 = 20 и 49.75-0.5/2 - (30-1)*0.5 = 35

То, что прописывает ENVI в yllcorner - это координата верхней границы нижнего пикселя (вероятно, потеряли -1 в формуле). Surfer вообще уводит llcorner на полпикселя ниже и левее.

[ericsson]

Статью http://gis-lab.info/qa/asciigrid.html читали?

[DCT]

Статью http://gis-lab.info/qa/asciigrid.html читали?

Спасибо, прочитал (+глянул обсуждение на форуме).
Но там там по поводу вышеприведенного вопиющего безобразия ничего не сказано (из проблем только неквадратная ячейка, но как видно по world файлу, тут ячейка квадратная).
Про существование *llcenter знаю, первоначально, когда обнаружил расхождения, думал, что они связаны с *llcenter/*llcorner, но нет - все программы при экспорте пишут *llcorner (и это, кстати, более соответствует спецификации), только математика с логикой почему то у них различаются.

[DCT]

Перепроверил:
Line 1: pixel size in the x-direction in map units/pixel
Line 4: pixel size in the y-direction in map units, almost always negative
т.е. указанному world-файлу соответствует размер пикселя (и, соответственно, ячейки) 0.5.
И да, параметр cellsize у .asc файлов из всех трех программ совпадает и соответствует world-файлу (равен 0.5).

[ericsson]

Так, а https://en.wikipedia.org/wiki/World_file вы читали?

[DCT]

Так, а https://en.wikipedia.org/wiki/World_file вы читали?

Если я не ошибаюсь , то согласно Википедии ...

Если считаете, что я ошибаюсь, поясните, пожалуйста, какие должны быть параметры xllcorner и yllcorner у "правильного" .asc, а также почему 3 программы дают при экспорте разные значения.

Чтобы не говорить беспредметно, прилагаю архив со всеми файлами (исходный Tif и 3 варианта его экспорта, файлы .prj .tfw в комплекте).

[lam]

Если считаете, что я ошибаюсь, поясните, пожалуйста, какие должны быть параметры xllcorner и yllcorner у "правильного" .asc, а также почему 3 программы дают при экспорте разные значения.

В разных софтах xllcorner и yllcorner может быть как центром ячейки так и узлом регулярной сетки, в данном случае.

[DCT]

В разных софтах xllcorner и yllcorner может быть как центром ячейки так и узлом регулярной сетки, в данном случае.

Тоже поначалу так думал.
Хорошо, допустим, что это так. Где расположены "узлы регулярной сетки"?

Рассчитайте, пожалуйста, по world файлу для нижнего левого пикселя
а) координаты центра
б) координаты нижнего левого угла (и, в вашем понимании, координаты узлов сетки). Сравните результатом Surfer 12.

[ericsson]

Мда.
В world-файле:

Line 5: C: x-coordinate of the center of the upper left pixel
Line 6: F: y-coordinate of the center of the upper left pixel

Соответственно, если стараться конвертировать привязку как можно ближе к оригиналу (сократив число вычислений) и привязка не содержит поворота, то для x-координаты должен использоваться xllcenter, и он должен быть равен содержимому пятой строки world-файла (потому что это тоже левый угол, хотя и нижний, а не верхний).

Поскольку, как замечено в статье, куча софта понимает только llcorner, значение xllcorner должно быть вычислено из xllcenter путем вычитания из него половины ширины пикселя с учетом знака.

Автоматически, если мы видим в ASCII grid привязку через llcorner и значение для X, равное тому, что было в world-файле, а растр - тот же (не переинтерполирован как-то и не обрезан), это ошибка.

[DCT]

ericsson Там еще и yllcorner у Surfer-а оказывается, при любой трактовке "узла", за пределами растра.

2all У кого нибудь есть под рукой ESRI и GDAL, чтобы глянуть, что они пишут в заголовке при экспорте тифа из вложения?

[DCT]

С Surfer, кажется, разобрался: он, как оказалось, не читает world файл при наличии информации в геотегах geotiff-a, а теги у нас тут такие (по данным exiftool-а):

Код: Выделить всё

Pixel Scale : 0.5 0.5 0
Model Tie Point : 0 0 0 20 50 0

И по части интерпретации этих тегов Surfer попал в категорию "альтернативно понимающих", т.е. он считает Tie Point координатами центра ячейки, хотя весь имеющийся под рукой софт считает Tie Point ul-углом пикселя (для чистоты эксперимента открывал геотиф без world файла). В оправдание Surfer могу сказать, что я так и не смог найти спецификацию этих тегов geotiff. Т.е., в итоге, у Surfer-а неправильно читается geotiff, но .asc пишется правильно.

GDAL, кстати, дает заголовок .asc файла, совпадающий с заголовком Global Mapper.

Написал разработчикам ENVI и Surfer, посмотрим, что ответят.