Привязка карт с поехали орг

[Moskus]

Таблица конечно чудесная.
Только для понимания процесса лично мне она нифига не дает..

[seno]

<<<для понимания процесса лично мне она нифига не дает>>>
Ну такая задача и не ставилась. Задача была в удобном виде показать, что координаты второй точки привязки зависят от проекции. Мне кажется так не должно быть. Если и правда "не должно быть", надо понять причину.
Только куда смотреть? У меня мыслей нет.

[Moskus]

В исходник смотреть, больше некуда. :)
Была бы возможность прямой конвертации уже нарезанных тайлов 256х256, ориентированных по сторонам света, и какого-нибудь CSV-файла (таблицы из их имен и пар координат углов, указанных в градусах) - я бы такой исходник для экспериментов подготовил. Но вроде как это нельзя сделать ни чем.

UPD: Получить такие данные легко:
- GlobalMapper поддерживает gridding с заданным размером тайлов в пикселях,
- их нужно выгнать в GeoTIFF,
- после чего сделать для каждого дамп метаданных через gdalinfo в текстовый файл,
- орудуя grep или любым аналогом - собрать таблицу, вынимая из дампов значения углов в градусах,
- сконвертировать все GeoTIFF-файлы в JPEG (imagemagick),
готово, остается уже без всяких преобразований собрать из этого заголовок и тело JNX, но на это моих программерских знаний уже маловато.

[AlexWhiter]

В коде map2jnx есть одно непонятное место.

Если проекция исходника - Lat/Lon, то координаты просто берутся из исходной карты и отдельных тайлов и просто записываются в JNX.
Для остальных проекций координаты преобразуются функцией pj_transform, и на выходе получаются координаты в проекции +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs. Документация сообщает, что pj_transform работает с радианами, а не градусами, и соответствующее преобразование в градусы в исходниках имеется.

Вроде всё нормально, но похоже на фигню. Еще раз вчитываемся:
при Lat/Lon - взяли из исходника координаты и сразу запихали в JNX (то есть вроде как везде градусы);
если не Lat/Lon - взяли координаты как они были в исходнике (то есть вроде бы опять же градусы), сразу запихали их в pj_transform (то есть уже радианы?), <b>преобразовали обратно в градусы</b>, запихали в JNX.

Короче, просматривается проблема смешивания величин в различных единицах.

Поинтересуюсь у Оливера, что он пытался этим сказать.

[Moskus]

Хм, в общем что-то странное действительно.
Если нужны такие вот "предварительно нарезанные" данные или таблица из них (для сверки с тем, что генерит софт) - сделаю.

UPD: Поясню свое понимание вопроса, так сказать.
Инструмент истинно удобен и универсален тогда, когда хорошо делает именно свою работу, а не выполняет кучу разнородных задач.
Вот есть, к примеру, gpsbabel, который дофига чего умеет. А есть к нему GUI с базовым набором функций, которые нужны большинству, не лезущему в дебри.
Так и тут, было бы очень неплохо, чтобы инструмент решал свою непосредственную задачу - генерацию формата, которого нет в драйверах форматов GDAL. А уже "обвязка" решала бы остальные вопросы. Но поскольку для оптимального решения задачи получения "хорошего" JNX нужно уметь без преобразований координат три проекции, обладающие общими свойствами (ориентация, характер искажения масштаба и т.п.), неплохо бы именно этот вопрос добить до победного, как говорится.

[AlexWhiter]

Подождем, что автор ответит.

[AlexWhiter]

Правильно ли я понял, что упомянутые три проекции - это Lat/Lon, Меркатор и Equirectangular?

[Moskus]

Да.
Хотя повторюсь, что Lat/Lon - это (в геометрическом смысле) та же Equirectangular, только "вырожденная" (там один параметр в ноль обращается), и у нее исторически принято указывать координаты сразу в угловых мерах.

[AlexWhiter]

Ответ Оливера на мой вопрос, не смешиваются ли в коде величины в различных единицах, а так же в каких единицах работает использующаяся в коде функция GetGeoTransform:

=== начало цитаты ===
Вопрос можно сформулировать так: являются ли две точки координатами в градусах, или же они представлены в других единицах, к примеру, метрах?

В проекциях Меркатор или Transversal Mercator координаты представлены в метрах, поэтому эти координаты должны быть переведены в градусы; датум при этом переделывается в WGS84.

Недостаток кода в том, что отсутствует обработка сдвига датума (в оригинале "the datum shift"), в том случае, когда в проекции карты используются градусы. То есть, если в качестве проекции используется "+proj=longlat", но датум отличен от "+datum=WGS84", получаемые тайлы будут показываться со смещением.

Так как этот недостаток кода может быть легко устранен использованием gdalwarp, я не пытался его исправлять.

Единици измерения значений, возвращаемых функцией GetGeoTransform, также зависят от используемой в карте проекции.
=== конец цитаты ===

Не является ли наблюдаемый сдвиг карты в проекции Equirectangular тем самым упомянутым сдвигом, который нужно исправлять в gdalwarp?

[Moskus]

В моем тестовом наборе все данные были в датуме WGS84 и сдвиги там должны быть в любом случае порядка полутора сотен метров, (у карты целиком).