gdaltindex vs gdal_polygonize

[Игорь Лебедь]

gdaltindex vs gdal_polygonize: есть ли параметр, который позволяет polygonize считать только не NODATA пикселы как одну категорию, чтобы не образовывалось много полигонов, а один, или же для gdaltindex считать только по не NODATA пикселам? Короче, нужен аналог модуля Image Boundary в виде команды/скрипта gdal*, а то тот модуль далеко не со всеми данными справляется.

[Boris]

Пропустить сперва через gdal_calc?

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

for %b in (*.tif ) do gdal_calc -A "%~fb" --A_band=1 -B "%~fb" --B_band=2 -C "%~fb" --C_band=3 --outfile="%~dpnb_c.tif" --calc="((A<>255)+(B<>255)+(C<>255))*127" --overwrite --format=GTiff --NoDataValue=255 --co TFW=YES --type=Byte --co COMPRESS=LZW

Вместо 255 следует поставить ваше значение NODATA. 127 выбрано как образец, что было видно, что "((A<>255)+(B<>255)+(C<>255))" дает 0 или 1. ХЗ почему.

[Максим Дубинин]

да, gdal_calc

очень странно у вас выражение составлено, логические блоки так не определяются
вот тут есть примеры расписанные с логикой http://gis-lab.info/qa/gdal-examples.ht ... 1.82.D1.8B

еще, если я правильно помню, что все это не поможет, так как если 255 это NODATA, то оно gdal_calc'ом будет просто проигнорировано в выражении, сначала нужно очистить этот тег
http://gis-lab.info/qa/gdal-examples.ht ... .81_NODATA

[Boris]

Приведенный пример является рабочим, протестированным на 3-х канальном растре с NODATA==255, с результатом 127 везде, где значения пикселя не равны 255. Результат получен методом "тыка". Лет несколько назад я спрашивал о синтаксисе выражения --calc, и не получил понятного мне ответа, копаться в кодах numpy - не стал, а описании языка выражений numpy тогда сходу не нашел, так и осталось - что получилось в результате экспериментов - то и правильно. Приведенный пример, я упустил, и не был с ним знаком. Но мне и после прочтения текста по ссылке, синтаксис выражения не стал очевиден. Толкование я понимаю, но в самой записи "очевидно, что ..." я не вижу. Я уже от этого отвык, но еще помню, что в Си подобных языках:

True (правда) — 1 и False (ложь) — 0

,
в этой логике, написанное мною представляет собой ожидаемое переполнение разряда, 1+1+1=3; 3*127 > 255.
В реальности получается 0 и 127. 0 для исходной NODATA в 3-х каналах, и 127 - для всех остальных значений.
После ознакомления с примером, хотя я и не понимаю логики, упомянутой со словом ELSE, для задания пары 0-значимые области, 255 - NODATA, в выходном растре, код должен быть такой:

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

for %b in (*.tif ) do gdal_calc -A "%~fb" --A_band=1 -B "%~fb" --B_band=2 -C "%~fb" --C_band=3 --outfile="%~dpnb_c.tif" --calc="((A<>255)+(B<>255)+(C<>255))*0+((A==255)+(B==255)+(C==255))*255" --overwrite --format=GTiff --NoDataValue=255 --co TFW=YES --type=Byte --co COMPRESS=LZW

[Игорь Лебедь]

Всем спасибо, работает, у меня там не 255, а реальная NODATA, так что всё просто решалось. И тем не менее, это костыль. Не хочется создавать лишний шаг, тем более - создавать растр, пусть даже и виртуальный. Странно мне, что в polygonize нельзя задавать параметр или условие для пикселов.
То есть вопрос был не как отбиться от NODATA, этого мы не боимся, а как оттюнинговать polygonize.