Що робити з -3,4e + 38 значеннями нодатів?


17

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

Здається, що інструменти gdal не в змозі впоратися з цим значенням nodata, а qgis, схоже, не може розпізнати його. У стилі шару є запис для -3,4e + 38, встановленого на 100% прозорим, але він все одно відображає такі значення, навіть якщо вибральник "Визначити особливості" показує, що він має значення -3,4e + 38.

Я спробував створити сад для перетворення значень нодатів на -9999, але це теж не спрацювало.

Як я можу обробити такі файли, щоб вони мали корисні значення вузлів?

значення nodata, зібрані з файлу встановлення прозорості не впливає


Імовірно, в новій версії qgis має НАШИХ кращу підтримку вузлів. У мене було багато «ноданих» проблем із 1,8 (особливо, коли я намагався обчислити гістограму чи засоби в межах області).
ники

Відповіді:


4

GDAL може обробляти ці значення. Насправді значення GDAL за замовчуванням NoData приблизно таке ж, як і ваше. Я думаю, що проблема полягає в помилці з плаваючою комою в 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 Мб. Однак якщо растр містить знаки з плаваючою точкою, мій підхід не працюватиме там, де це буде.
rudivonstaden

Ви перевірили, чи немає для цього відкритого квитка у програмі помилок QGIS?
underdark

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

@underdark Я не зміг знайти квиток, який би відповідав цьому, тому я додав звіт про помилку ( hub.qgis.org/isissue/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.