На выходных готовил растровую карту для похода на Кодар, с последующей конвертацией оной в JNX.
Самые неинтересные и скучные моменты в этом деле была обрезка рамки. А кроме того, печаль, по причине того, что есть карты с привязками OZI, но нет нормального конвертера для них.
В результате, подумал и написал за выходные две программы: ozi2map и geocrop
ozi2map
Первая, как можно понять из названия, предназначена для конвертации карты с привязкой OZI (сама карта в JPEG или GIF или другом распространённом растровом формате, который поддерживает OZI, но не OZFX/OZFX2/OZFX3, для них преобразования можно сделать средствами самого gdal (в прошлых статьях писал про это)).
Для чтения точек привязки и параметров проекции используется функция из недр GDAL: GDALReadOziMapFile(...)
, что, в отличии от питоновского ozi2geotiff.py, даёт корректные параметры проекции. Далее, не стал особо заморачиваться и подсовывая нужные параметры gdal_translate/gdalwarp вызываю их через system()
.
Я вообще не стал лезть в разбор map файла, поэтому файла растра автоматически не определяется и его нужно указывать самому: ./ozi2map O-50-103.map O-50-103.jpg ./ozi2map O-50-103.map O-50-103.jpg O-50-103.tif
Если имя выходного файла не задано, имя будет сформировано из имени растра с заменой расширения на .tif.
Всё, пользоваться программой должно быть проще простого. Найти исходники (GPLv2) можно тут:
https://git.gitorious.org/h4tr3d-utils/ozi2map.git
Собирать просто: make
Полученный бинарник можно запускать от куда угодно.
geocrop
Вторая программа предназначена для автоматической (хотя лукавлю: полуавтоматической) обрезки рамки на номенклатурном листе. Принцип действия прост: определённому набору координат соответствует какой-то стандартный лист заданного масштаба (его как раз и нужно указывать). Стандартный лист обрамлён вполне конкретными координатами, по которым вполне можно осуществить обрезку без вмешательства человека.
Т.е. по сути, программе на вход нужен только масштаб листа (в виде 1M, 500k, 200k, 100k, 50k, 25k, 10k, 5k, 2k) и сам лист карты в формате, поддерживаемом GDAL с корректной привязкой.
Когда расчёты по привязке будут выполнены, вызывается gdalwarp через system()
. Полигон для обрезки формируется в координатах листа (не в точках растра), для всех листов, кроме 1M, это 4х угольник (на будущее будет более качественно сделано, но и текущего результата хватит в 99.99% случаев).
Пользоваться программой не сложнее чем ozi2map: ./geocrop -s 100k O-50-103.tif O-50-103-crop.tif
Первым аргументом - стилизованное обозначение масштаба:
- 1M - 1:1 000 000 (это масштаб используется, если мнемоника не распознана)
- 500k - 1:500 000 (“пятикилометровка”)
- 200k - 1:200 000 (“двухкилометровка”)
- 100k - 1:100 000 (“километровка”)
- 50k - 1:50 000 (“полукилометровка” или “пятисотметровка”)
- 25k - 1:25 000 (“двухсотпятидесятиметровка”)
- 10k - 1:10 000 (“стометровка”, пока не реализовано)
- 5k - 1:5000 (“пятидесятиметровка”, пока не реализовано)
- 2k - 2:2000 (“двадцатиметровка”, пока не реализовано) Если этот параметр пропущен, используется масштаб 100k.
Вторым аргрументом - входной файл, поддерживаемый GDAL.
Третий аргумент - выходной, кропнутый файл. По умолчанию - GeoTiff, но можно переопределить опцией “-f FORMAT”, где FORMAT - любой поддерживаемый GDAL.
Если хотите обрезанные карты потом склеивать при помощи gdal_merge.py
, и получить вразумительные результат, входной файл должен быть в цветовой палитре RGB, узнать это можно при помощи утилиты gdalinfo
, если в выводе есть такое:
Band 1 Block=4096x1 Type=Byte, ColorInterp=Red
Band 2 Block=4096x1 Type=Byte, ColorInterp=Green
Band 3 Block=4096x1 Type=Byte, ColorInterp=Blue
значит всё хорошо, если нет (выводится палитра из 255 цветов), то палитра индексированная, нужно преобразовать в RGB при помощи утилиты pct2rgb.py
из комплекта GDAL.
Собирать просто: mkdir build cd build cmake .. make
Если на стадии cmake будут какие-то проблемы, стоит поставить dev-пакеты для GDAL и PROJ.4
Исходники можно взять тут (GPLv2):
https://github.com/h4tr3d/geocrop