Привязка карт с поехали орг
Правила форума
Для предотврашения спама первые сообщения вновь зарегистрированных пользователей проходят ручную премодерацию.
Для предотврашения спама первые сообщения вновь зарегистрированных пользователей проходят ручную премодерацию.
Re: Растр+.map в GeoTIFF
Таблица конечно чудесная.
Только для понимания процесса лично мне она нифига не дает..
Только для понимания процесса лично мне она нифига не дает..
|
||
Re: Растр+.map в GeoTIFF
<<<для понимания процесса лично мне она нифига не дает>>>
Ну такая задача и не ставилась. Задача была в удобном виде показать, что координаты второй точки привязки зависят от проекции. Мне кажется так не должно быть. Если и правда "не должно быть", надо понять причину.
Только куда смотреть? У меня мыслей нет.
Ну такая задача и не ставилась. Задача была в удобном виде показать, что координаты второй точки привязки зависят от проекции. Мне кажется так не должно быть. Если и правда "не должно быть", надо понять причину.
Только куда смотреть? У меня мыслей нет.
Re: Растр+.map в GeoTIFF
В исходник смотреть, больше некуда. :)
Была бы возможность прямой конвертации уже нарезанных тайлов 256х256, ориентированных по сторонам света, и какого-нибудь CSV-файла (таблицы из их имен и пар координат углов, указанных в градусах) - я бы такой исходник для экспериментов подготовил. Но вроде как это нельзя сделать ни чем.
UPD: Получить такие данные легко:
- GlobalMapper поддерживает gridding с заданным размером тайлов в пикселях,
- их нужно выгнать в GeoTIFF,
- после чего сделать для каждого дамп метаданных через gdalinfo в текстовый файл,
- орудуя grep или любым аналогом - собрать таблицу, вынимая из дампов значения углов в градусах,
- сконвертировать все GeoTIFF-файлы в JPEG (imagemagick),
готово, остается уже без всяких преобразований собрать из этого заголовок и тело JNX, но на это моих программерских знаний уже маловато.
Была бы возможность прямой конвертации уже нарезанных тайлов 256х256, ориентированных по сторонам света, и какого-нибудь CSV-файла (таблицы из их имен и пар координат углов, указанных в градусах) - я бы такой исходник для экспериментов подготовил. Но вроде как это нельзя сделать ни чем.
UPD: Получить такие данные легко:
- GlobalMapper поддерживает gridding с заданным размером тайлов в пикселях,
- их нужно выгнать в GeoTIFF,
- после чего сделать для каждого дамп метаданных через gdalinfo в текстовый файл,
- орудуя grep или любым аналогом - собрать таблицу, вынимая из дампов значения углов в градусах,
- сконвертировать все GeoTIFF-файлы в JPEG (imagemagick),
готово, остается уже без всяких преобразований собрать из этого заголовок и тело JNX, но на это моих программерских знаний уже маловато.
- AlexWhiter
- Сообщения: 384
- Зарегистрирован: 09 дек 2016, 16:50
Re: Растр+.map в GeoTIFF
В коде 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.
Короче, просматривается проблема смешивания величин в различных единицах.
Поинтересуюсь у Оливера, что он пытался этим сказать.
Если проекция исходника - 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.
Короче, просматривается проблема смешивания величин в различных единицах.
Поинтересуюсь у Оливера, что он пытался этим сказать.
Re: Растр+.map в GeoTIFF
Хм, в общем что-то странное действительно.
Если нужны такие вот "предварительно нарезанные" данные или таблица из них (для сверки с тем, что генерит софт) - сделаю.
UPD: Поясню свое понимание вопроса, так сказать.
Инструмент истинно удобен и универсален тогда, когда хорошо делает именно свою работу, а не выполняет кучу разнородных задач.
Вот есть, к примеру, gpsbabel, который дофига чего умеет. А есть к нему GUI с базовым набором функций, которые нужны большинству, не лезущему в дебри.
Так и тут, было бы очень неплохо, чтобы инструмент решал свою непосредственную задачу - генерацию формата, которого нет в драйверах форматов GDAL. А уже "обвязка" решала бы остальные вопросы. Но поскольку для оптимального решения задачи получения "хорошего" JNX нужно уметь без преобразований координат три проекции, обладающие общими свойствами (ориентация, характер искажения масштаба и т.п.), неплохо бы именно этот вопрос добить до победного, как говорится.
Если нужны такие вот "предварительно нарезанные" данные или таблица из них (для сверки с тем, что генерит софт) - сделаю.
UPD: Поясню свое понимание вопроса, так сказать.
Инструмент истинно удобен и универсален тогда, когда хорошо делает именно свою работу, а не выполняет кучу разнородных задач.
Вот есть, к примеру, gpsbabel, который дофига чего умеет. А есть к нему GUI с базовым набором функций, которые нужны большинству, не лезущему в дебри.
Так и тут, было бы очень неплохо, чтобы инструмент решал свою непосредственную задачу - генерацию формата, которого нет в драйверах форматов GDAL. А уже "обвязка" решала бы остальные вопросы. Но поскольку для оптимального решения задачи получения "хорошего" JNX нужно уметь без преобразований координат три проекции, обладающие общими свойствами (ориентация, характер искажения масштаба и т.п.), неплохо бы именно этот вопрос добить до победного, как говорится.
|
||
- AlexWhiter
- Сообщения: 384
- Зарегистрирован: 09 дек 2016, 16:50
Re: Растр+.map в GeoTIFF
Подождем, что автор ответит.
- AlexWhiter
- Сообщения: 384
- Зарегистрирован: 09 дек 2016, 16:50
Re: Растр+.map в GeoTIFF
Правильно ли я понял, что упомянутые три проекции - это Lat/Lon, Меркатор и Equirectangular?
Re: Растр+.map в GeoTIFF
Да.
Хотя повторюсь, что Lat/Lon - это (в геометрическом смысле) та же Equirectangular, только "вырожденная" (там один параметр в ноль обращается), и у нее исторически принято указывать координаты сразу в угловых мерах.
Хотя повторюсь, что Lat/Lon - это (в геометрическом смысле) та же Equirectangular, только "вырожденная" (там один параметр в ноль обращается), и у нее исторически принято указывать координаты сразу в угловых мерах.
- AlexWhiter
- Сообщения: 384
- Зарегистрирован: 09 дек 2016, 16:50
Re: Растр+.map в GeoTIFF
Ответ Оливера на мой вопрос, не смешиваются ли в коде величины в различных единицах, а так же в каких единицах работает использующаяся в коде функция GetGeoTransform:
=== начало цитаты ===
Вопрос можно сформулировать так: являются ли две точки координатами в градусах, или же они представлены в других единицах, к примеру, метрах?
В проекциях Меркатор или Transversal Mercator координаты представлены в метрах, поэтому эти координаты должны быть переведены в градусы; датум при этом переделывается в WGS84.
Недостаток кода в том, что отсутствует обработка сдвига датума (в оригинале "the datum shift"), в том случае, когда в проекции карты используются градусы. То есть, если в качестве проекции используется "+proj=longlat", но датум отличен от "+datum=WGS84", получаемые тайлы будут показываться со смещением.
Так как этот недостаток кода может быть легко устранен использованием gdalwarp, я не пытался его исправлять.
Единици измерения значений, возвращаемых функцией GetGeoTransform, также зависят от используемой в карте проекции.
=== конец цитаты ===
Не является ли наблюдаемый сдвиг карты в проекции Equirectangular тем самым упомянутым сдвигом, который нужно исправлять в gdalwarp?
=== начало цитаты ===
Вопрос можно сформулировать так: являются ли две точки координатами в градусах, или же они представлены в других единицах, к примеру, метрах?
В проекциях Меркатор или Transversal Mercator координаты представлены в метрах, поэтому эти координаты должны быть переведены в градусы; датум при этом переделывается в WGS84.
Недостаток кода в том, что отсутствует обработка сдвига датума (в оригинале "the datum shift"), в том случае, когда в проекции карты используются градусы. То есть, если в качестве проекции используется "+proj=longlat", но датум отличен от "+datum=WGS84", получаемые тайлы будут показываться со смещением.
Так как этот недостаток кода может быть легко устранен использованием gdalwarp, я не пытался его исправлять.
Единици измерения значений, возвращаемых функцией GetGeoTransform, также зависят от используемой в карте проекции.
=== конец цитаты ===
Не является ли наблюдаемый сдвиг карты в проекции Equirectangular тем самым упомянутым сдвигом, который нужно исправлять в gdalwarp?
Re: Растр+.map в GeoTIFF
В моем тестовом наборе все данные были в датуме WGS84 и сдвиги там должны быть в любом случае порядка полутора сотен метров, (у карты целиком).
Кто сейчас на конференции
Сейчас этот форум просматривают: Bing [Bot] и 58 гостей