Что делать с -3.4e + 38 значениями nodata?


17

Я пытаюсь обработать некоторые биоклиматические растровые файлы, например, которые можно скачать с http://www.worldclim.org/current (набор биоклимов). Кажется, что для них установлены значения узлов в -3.4e+38соответствии с QGIS (если посмотреть на вывод gdalinfo, это так -3.39999999999999996e+38).

Кажется, что инструменты gdal не могут справиться с этим значением нодаты, и qgis, похоже, тоже не может его распознать. В стилизации слоя есть запись для -3.4e + 38, установленная на 100% прозрачность, но она по-прежнему отображает такие значения, даже несмотря на то, что средство выбора «Определить объекты» показывает, что они имеют значение -3.4e + 38.

Я попытался создать vrt для преобразования значений узлов в -9999, но это тоже не сработало.

Как я могу обработать такие файлы, чтобы получить пригодные значения узлов?

значения узлов, взятые из файла настройка прозрачности не влияет


Предположительно, в новой версии qgis НАМНОГО лучше поддерживает nodata. У меня было много «ноданных» проблем с 1.8 (особенно когда я пытался вычислить гистограмму или средние значения в области).
Никв

Ответы:


4

GDAL может обрабатывать эти значения. На самом деле значение NoData GDAL по умолчанию почти такое же, как у вас. Я думаю, что проблема заключается в ошибке с плавающей запятой в QGIS. У меня та же проблема со значениями NoData с плавающей точкой.

Если вы хотите изменить значение NoData с помощью GDAL, вы можете использовать gdalwarp или, возможно, gdal_translate и установить для этого значения nodata целое число (-dstnodata и -a_nodata соответственно). Например, в прошлом я успешно установил значение NoData -999 в 64-битном растре с плавающей запятой. Однако, учитывая, что мы установили, что существует проблема с плавающей запятой в этом отношении, я не хотел бы гарантировать, что это будет работать во всех случаях.


Спасибо за ваш ответ, Сильвестр. Я не мог заставить работать gdal_translate, gdal_translate -a_nodata -9999 input.tif output.tifхотя и gdalwarp -dstnodata -9999 input.tif output.tifдобился цели . Из 9-мегабайтного входного файла мой подход позволил получить 26-мегабайтный файл, тогда как gdalwarp - 52-мегабайтный выходной. Однако, если растр содержит значения с плавающей точкой, мой подход не будет работать там, где этот будет.
Рудивонстаден

Вы проверили, есть ли для этого трекер ошибок в QGIS?
Подземье

1
Переполнение данных может быть вызвано либо увеличением глубины пикселя (скажем, 63-битным по сравнению с 16-битным), либо просто из-за того, что оригинал представляет собой JPEG, а ваш новый результат - TIFF. @underdark - Извините! Нет, я не проверял, есть ли открытый билет.
MappaGnosis

@underdark Я не смог найти билет, соответствующий этому, поэтому я добавил отчет об ошибке ( hub.qgis.org/issues/6786 ).
rudivonstaden

1
Для меньшего размера файла вам просто нужно добавить -co COMPRESS=LZW.
j08lue

11

Мне удалось найти обходной путь для этой проблемы путем преобразования формата данных в Int16 из Float32. Тогда минимальное значение равно -32768 и может быть обработано как значение узла. Следующая команда добилась цели:

gdal_translate -ot Int16 -a_nodata -32768 input.tif output.tif

Возможно, есть лучшее решение, но это, по крайней мере, решает мою непосредственную проблему.

нодата подобрана правильно



0

Вы можете попробовать gdal_calc.py input.tif --outfile = output.tif --calc = "A * (A> 0)" --NoDataValue = 0

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.