Тандем GRASS, QGIS, EASY Trace и GIMP

[eucrariano]

Здравствуйте! Прошу совета здесь, поскольку конечная цель - создание ЦМР и ее постобработка будет возложена на GRASS.
Вопросы, а точнее ответы на них, вероятно будут полезны не только мне, а учитывая квалификацию отвечающих (в большинстве своем) их можно рассматривать в большинстве случаев чуть ли не как истину в последней инстанции (это такой небольшой преферанс в сторону отвечающих ).
А поскольку правильно заданый вопрос — это правильный ответ, постараюсь задавать его/их правильно, по крайней мере развернуто, что-бы яснее выразить мысль (точнее их набор или, еще точнее, хитросплетение набора ).
Так вот. Мы, то есть я, начинаем проект. Главный (возможно единственным и останусь) исполнитель - я. И поскольку проект достаточно масштабен, хочется создать, точнее улучшить, алгоритм работы, который по максимуму даст возможность использовать время и дисковое пространство. И при этом наделать наименьшее количество глупостей.
Раньше было так. При работе с малыми объемами данных работу организовывал, используя тандем GRASS, QGIS, EASY Trace и GIMP следующим образом:
1. Отсканированный материал (файл 0 — исходный, и лежащий в архиве неизмененным на всякий случай) переворачиваю в GIMPе (поскольку ориентация карт разная в связи с ветхостью карт и невозможностью в ряде случаев "всунуть/впихнуть" их "правильной"стороной в протяжный сканер) и сохраняю как файл 1.
2. Отсканированный лист карты (файл 1) обрезаю по контуру карты, убирая зарамочную информацию, что нужно для последующей сборки мозаичного покрытия и для впихивания в Изи трейс с последующим беспроблемным экспортом векторов из него в Грасс (файл 2).
3. Привязка фрагмента карты (файл 2), лишенного зарамочного оформления в QGIS (поскольку процесс привязки здесь реализован просто превосходно (поправьте меня, если это не так) и сохранение его в двух вариантах в geotiff (файл 3 и файл 4).
4. В файле 4 создаю пирамиду и из таких файлов мозаика разного калибра собирается и отображается уже без проблем.
5. Пересохранение файла 3 в файл 5 (простой tiff) с удалением информации про альфа канал (прозрачность), поскольку изитрейс без такой манипуляции его не открывает.
6. Файл 3 импортируем в GRASS.
Итого куча файлов:
файл 0 — неизмененный архивный
файл 1 — повернутый файл в ориентации север-юг
файл 2 — карта без зарамачной информации непривязанная
файл 3 — карта без зарамачной информации привязанная в geotiff
файл 4 — карта без зарамачной информации привязанная в geotiff + с пирамидой
файл 5 — пересохранение файла 3 в простой тиф без альфа-канала + генерация twf файла (я это делал давно, и, честно говоря, забыл чем).
+ еще в Easy Trace создаются несколько промежуточных карт: чветоделенные растры, черно-белый растр, подложка для контроля и т.д.
Вот так раньше было. Как видим, файлов куча, цепочка операций тоже немалая. Каким образом можно все это хозяйство оптимитизировать/укоротить?
Спасибо

[Александр Мурый]

это такой небольшой преферанс в сторону отвечающих

+1, повысило настроение с утра

По теме:
-- пункты 1 и 2 (поворот растра и его обрезание обрезку), вроде бы, можно сделать и в ET
-- пункт 3 (привязку) при желании использовать меньше программ тоже можно сделать в ET
-- не понял, зачем после привязки в QGIS создавать пирамиды, если конечная обработка будет происходит в GRASS (а там пирамиды бесполезны)?
Наверное, всё можно свести к ET+GRASS.

[Voltron]

это такой небольшой преферанс в сторону отвечающих .

Спасибо за поднятое настроение.

файл 0 — неизмененный архивный
файл 1 — повернутый файл в ориентации север-юг
файл 2 — карта без зарамачной информации непривязанная
файл 3 — карта без зарамачной информации привязанная в geotiff
файл 4 — карта без зарамачной информации привязанная в geotiff + с пирамидой
файл 5 — пересохранение файла 3 в простой тиф без альфа-канала + генерация twf файла (я это делал давно, и, честно говоря, забыл чем).
+ еще в Easy Trace создаются несколько промежуточных карт: чветоделенные растры, черно-белый растр, подложка для контроля и т.д.

Пирамиды могут быть внешними, так что «файл 4» можно без проблем заменить «файлом 3» + внешний файл пирамид. Если есть prj+tfw, то необходимость дополнительного geotiff-а тоже вызывает вопрос, разве что нужна информация об альфа-канале.

[ericsson]

Ну и чисто графические операции (пирамиды, отбрасывание прозрачности, поворот) можно поручить средствам без всякого GUI: gdal и imagemagick, утилитам tifflib. Просто создать batch-файлы, для каждой задачи - свой, сложить ярлыки на них в одну папку, присвоить им понятные иконки (стрелка влево, стрелка вправо, стрелка на 180 градусов, пирамидные слои, буква α ) и при необходимости выполнения нужной операции просто делать drag-n-drop на иконку. В batch-файле сделать сохранение результата в исходную папку, имя - с понятным префиксом (*.noalpha.* *.pyramid.*) и т.п.

[Александр Мурый]

Я правильно предполагаю, что работа будет проводиться в Linux-системе? Если так, то "дрыги-дропы" и иконки тут (IMHO) ни к чему (хотя и возможны), а вот поворот и снятие прозрачности в ImageMagick, создание пирамид с пом. gdaladdo и создание world-файлов можно было бы замешать в один или несколько shell-скриптов..

[ericsson]

Я предположил windows, поскольку был упомянут ET. Что он пашет под wine - в курсе, но тем не менее.

[eucrariano]

Спасибо за ответы, рад что удалось немного поднять настроение.
Operating System: Debian GNU/Linux wheezy/sid - sorry, что сразу не указал. ЕТ работает под вайном.

1. Раньше как-то даже не задумывался о возможности подготовки (поворота и обрезки) растров в ЕТ. Вот сейчас попробовал. ЕТ все делает и очень неплохо. Даже попробовал сшивать растры — все очень даже ничего, но в связи с качеством исходного материала (усадка, ветхость и перегибы, склейка разрывов скотчем и т.д.) получаются несовпадения, и они достаточно велики, обрезка точно по углам иногда оставляет полоски пикселов зарамочной информации, иногда обрезает саму карту. Еще, в связи с поворотом растра, получаются белые полоски (треугольники, которые дополняют растр до идеального прямоугольника), так вот они белые, поскольку ЕТ 7.99 не поддерживает прозрачность/альфа канал. И при привязке такого фрагмента сделанного в ЕТ и сборке мозаики на стыках карт будут такие вот артефакты ;( . Получается, что первым этапом должна быть именно привязка файла (файл 1) в QGIS с большим набором точек (вероятно по каждому пересечению координатной сетки и их выходам на край листа и сохранением файла с точками) и использованием алгоритмов трансформации чтобы получить “идеальный” растр. Кстати вот и ВОПРОС: какой алгоритм лучше при этом использовать. К сожалению, материала лучшего по качеству не будет, да и этот — еле достал, это БОЛЬШАЯ удача, что есть хотя бы такой. Обрезать растр по рамке в Квантуме можно? Если да то как, может я невнимательно читаю?
Иначе, что-бы получались вот эти треугольники прозрачными, придется таки обрезать в Гимпе, сохранять в тиф, снова перепривязывать в геотиф с использованием ранее сохраненного файла с точками и паралельно сохранять в простой тифф, для которого создавать файл привязки *.tfw Geo_Tiff_Examiner’ом и который собственно будет векторизироваться в ЕТ.
2. Геотиф нужен, потому, что что нужна информация об альфа-канале и сборка мозаики будет осуществлятся не только мной для себя, а и другими людьми при наличии моего отсутствия в неизвестном мне ПО — то-ли ArcGIS, то-ли Map Info или Digitals ... Не знаю поддерживает это ПО внешние файлы пирамид или нет? А привязать данные и подготовить для мозаики надо, это как-бы плата за картографический материал. Для себя я то уже сделаю внешние пирамиды, посмотрю еще как лучше.
3. Автоматизировать процессы скриптами довольно заманчивое предложение, проблема только в незнании баша и нехватке времени на его освоение ;( . Проблема еще в том, что материал разнороден. Есть карты разных масштабов, от 10000 (большинство), до 25000 и 50000 — где пропуски в 10000. В 10000 разнобой по годам/десятилетиям выпуска, часть с координатами, часть — без, причем совсем в другой номенклатуре, сопоставление между листами показывает, что полного соответствия нет, карты без координат смещены к востоку на X и к северу на Y метров. Полный набор короче. Поэтому автоматизировать процесс скорее всего не буду, а постепенного руками слеплю в красивую упорядоченную кучу .

ИТОГО, процесс, вероятно, выглядеть будет так:

файл 0 — неизмененная страховая копия, архивный
файл 1 — QGIS: карта с зарамочной информацией привязанная в geotiff по куче точек, чтобы по максимуму воссоздать геометрию исходной карты (в процессе привязки карта сама перевернется/повернется в нужную сторону на нужный угол + файл 1’ (файл с точками привязки)
файл 2 — GIMP: вырезанная идеально внутрирамочная часть карты непривязанная
тот же файл 2 — QGIS: вырезанная идеально внутрирамочная часть карты перепривязанная в geotiff с использованием файла 1’ (после его модификации) + сгенерированный файл привязки *.tfw с помощью Geo_Tiff_Examiner’а (файл 2’) + файл пирамид файл 2’’.
файл 3 — GIMP: тот же файл 2 но с “прибитой” геоинформацией и без альфаканала для векторизации в ЕТ

ВЕКТОРИЗАЦИЯ В ЕТ ПРЕДУСМАТРИВАЕТ СОЗДАНИЕ как минимум одной копии файла 3 для выделения тематического слоя (в даном случае даже двух, поскольку гидрография важна не меньше рельефа) + еще копия с приглушенной цветопередачей и яркостью для контроля собственно векторизации, затем цветоделение и получение черно-белых растров с горизонталями и гидрографией.

Ну и набор карт в GRASS, по поводу чего наверное... чего уж там, точно надо будет, новую тему открывать.

Ну вот, все равно куча файлов, но меньше не получится, иначе выпадет какая-либо стадия процесса.

[Voltron]

Обрезать растр по рамке в Квантуме можно? Если да то как, может я невнимательно читаю,

Если правильно понял, то можно. «Растр - Extraction - Обрезка», границы задаете либо выделяя прямоугольник на карте, либо используя полигональный векторный слой с границами контура.

паралельно сохранять в простой тифф, для которого создавать файл привязки *.tfw Geo_Tiff_Examiner’ом

*.tfw + *.prj можно получать в QGIS, причем в групповом режиме (см. «Растр - Projections - Extract projection»)

[eucrariano]

Здравствуйте.
Попробовал использовать «Растр - Extraction - Обрезка». Границы задавал используя откорректированный полигональный векторный слой с границами контура внутрирамочной информации полученный из "Вектор - Инструменты исследований - Полигон из границ слоя". В зависимости от входных параметров получаем растр или с черными полями, или с "прозрачными/белыми", которые без проблемно отображаются в Кугисе. Но вот в ЕТ они не отображаются: почему-то - сплошное черное поле. В чем проблема? И еще. Реально файл содержит то же количество пикселов, что и исходный, просто векторная рамка служит для обнуления всего за ее границами, а не "вырезает" фрагмент, как в редакторе изображений. При этом размер файла остается практически таким же. Исходя из разрешения 600 dpi и количества файлов, это достаточно много "холостого" места на диске.

*.tfw действительно можно получить в "Растр - Проекции - Экстрагирование проекций". Правда у меня не получилось, Кугис вылетает напрочь при любых раскладах. Грешу на то, что это QGIS version 1.9.90-Alpha.

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

файл 0 — неизмененная страховая копия, архивный
файл 1 — QGIS: карта с зарамочной информацией привязанная в geotiff по куче точек, чтобы по максимуму воссоздать геометрию исходной карты (в процессе привязки карта сама перевернется/повернется в нужную сторону на нужный угол + файл 1’ (файл с точками привязки)
файл 2 — QGIS: вырезанная идеально внутрирамочная часть карты (привязанная поскольку вырезается из привязанной) + сгенерированный в Кугисе файл привязки *.tfw (файл 2’) + файл пирамид файл 2’’
т.
файл 3 — наверное все-таки GIMP (или можно удалить информацию про привязку из геотиффа средствами Кугиса): тот же файл 2 но с “прибитой” геоинформацией и без альфаканала для векторизации в ЕТ.

Файлов вроде-бы то же количество, но выпадают стадии перепривязки. Так уже лучше.

P.S. Вот, только что обнаружил, что ни один файл после обработки «Растр - Extraction - Обрезка» (независимо от параметров сохранения) не отображается и в ГИМПЕ: сплошное черное поле и сообщение "alpha channel type not defined for file название.TIF. Assuming alpha is not premultiplied". При этом Кугис открывает их без проблем.

[Voltron]

*.tfw действительно можно получить в "Растр - Проекции - Экстрагирование проекций". Правда у меня не получилось, Кугис вылетает напрочь при любых раскладах. Грешу на то, что это QGIS version 1.9.90-Alpha.

QGIS собранный из последнего среза master, ошибки не наблюдается. Система случаем не 64 битная?

По поводу обрезки. Тут надо смотреть на gdal_translate, т.к. в QGIS всего лишь интерфейс к этой утилите.

[eucrariano]

Именно 64 бит: Kernel and CPU - Linux 3.0.0-1-amd64 on x86_64. Это имеет значение ввиду меньшей вылизаности, если так можно говорить про альфу?
А с обрезкой и gdal_translate попробую вечером разобраться.
Хочется все сделать одним заходом.

[Voltron]

Именно 64 бит: Kernel and CPU - Linux 3.0.0-1-amd64 on x86_64. Это имеет значение ввиду меньшей вылизаности, если так можно говорить про альфу?

Не пугайтесь слова alpha, в данном случае это не означает совсем другое. QGIS 1.9.90 стабильна не менее чем 1.7.3.
А ошибка, с которой вы столкнулись, похоже, специфична только для 64-битных систем. Не знаю, с чем именно это связано, но несколько человек уже жаловалось, что зависание с последующим падением происходит до запуска процесса, при попытке закрыть окно выбора каталога.

[eucrariano]

Плохо получается, точнее ничего не получается ;(
gdal_translate - конвертирует в разные форматы, но то что нужно - истинную "обрезку" по непрямоугольному вектору - ну не нашел как запустить, как мне кажется, это все-таки инструмент не для этого.

Прямоугольная обрезка — "позволяет вырезать прямоугольный фрагмент растра или нескольких соседних растров и сохранить этот фрагмент в отдельный файл (на базе gdal_merge) (взято отсюда - http://gis-lab.info/qa/gdaltools.html)" - это ближе к делу, но нужно именно обрезку по произвольному вектору, с заданием прозрачности в полях, которые дополняют растр до прямоугольного.

Прошло несколько дней. Поскольку у меня Дебиан Wheezy, каждый день что-то обновляется, львиная доля обновлений - это код QGIS. Но все-равно при - "Растр - Проекции - Экстрагирование проекций" имею моментальное падение Кугиса без всяких сообщений о ошибках. Как отчет сгенерировать и как его отправить разработчикам?
И кажется я тему не в той ветке начал. Основные вопросы пока что идут по КуГИСУ.

P.S. А слова "alpha" я не боюсь, потому что, как в известной песне Высоцкого, - "я ведь лежа жму 150"

[Voltron]

gdal_translate - конвертирует в разные форматы, но то что нужно - истинную "обрезку" по непрямоугольному вектору - ну не нашел как запустить, как мне кажется, это все-таки инструмент не для этого.

Прямоугольная обрезка — "позволяет вырезать прямоугольный фрагмент растра или нескольких соседних растров и сохранить этот фрагмент в отдельный файл (на базе gdal_merge) (взято отсюда - http://gis-lab.info/qa/gdaltools.html)" - это ближе к делу, но нужно именно обрезку по произвольному вектору, с заданием прозрачности в полях, которые дополняют растр до прямоугольного.

Виноват, недосмотрел, прощу прощения. gdal_translate умеет делать обрезку только по прямоугольнику. Для обрезки по произвольному полигону используется gdalwarp c опциями "cutline", "crop_to_cutline" и "dstalpha", но при этом охват результирующего растра будет равен охвату маскирующего слоя.

Статья, на которую вы ссылаетесь порядком устарела, надо будет обновить.

Прошло несколько дней. Поскольку у меня Дебиан Wheezy, каждый день что-то обновляется, львиная доля обновлений - это код QGIS. Но все-равно при - "Растр - Проекции - Экстрагирование проекций" имею моментальное падение Кугиса без всяких сообщений о ошибках. Как отчет сгенерировать и как его отправить разработчикам?

Ошибка уже зафиксирована — #4534. Если есть возможность, попробуйте сгенерировать backtrace, запустив QGIS из-под отладчика (небольшая инструкция есть здесь) и приложить его к этому тикету или выложить на форум. Это поможет в решении проблемы. И да, вопросы по QGIS лучше задавать в соседнем форуме.