Значение NDVI в MOD13Q1 не показывает верных величин

[Natalia Novoselova]

В продукте MOD13Q1 параметр «250m 16 days NDVI» имеет scale factor 0.0001, а значения от 2.19685e+07 до 8.50412e+07
Как перевести эти значения в значения NDVI, который может быть от -1 до +1????

Например, значение, которое точно реально и должно быть от 0 до 1, имеет
2.296e+07
Это равно 2.296*10000000=29600000
Теперь это нужно умножить на scale factor, который равен 0.0001

29600000*0.0001= 2960



Значение явно не NDVI.

[Natalia Novoselova]

По смыслу, 2960 надо еще раз умножить на scale factor, который равен 0.0001. И тогда получится уже значение NDVI.

Но КАК это понять из описания продукта, почему на 0.0001 нужно умножать 2 раза??

https://lpdaac.usgs.gov/dataset_discove ... d13q1_v006

[alexandr cherepanov]

а значения от 2.19685e+07 до 8.50412e+07

Где это написано?

SDS Name:250m 16 days NDVI
Data Type:16-bit signed integer

Тип данных позволяет хранить значения в диапазоне −32,768 (−1 × 2^15) - +32,767 (2^15 − 1).

Fill Value:-3000
Valid Range:-2000 to 10000
Scale Factor:0.0001

А из этого следует, что значения могут быть только в диапазоне -2000 - +10000 и -3000.
С учетом Scale Factor NDVI будет в диапазоне от -0.2 до +1

[Natalia Novoselova]

Где это написано?

Это я вижу в открытых данных (скриншот)

Ничего не поняла - почему так вышло, что на scale factor нужно умножать 2 раза? Зачем вообще такая странная запись? Но главное - как из описания данных понять, как рассчитать нужное значение? Я думала, что просто умножением на scale factor. Но здесь это не так - умножать надо 2 раза (и только потому так считаю, что значения только так становятся ндви-шными).

[alexandr cherepanov]

Ну значит QGIS воспринимает Scale Factor 0.0001 так, как он есть и делит значения пикселов на него. Откройте hdf в другом софте и посмотрите как он пересчитывает.

[Natalia Novoselova]

Ну значит QGIS воспринимает Scale Factor 0.0001 так, как он есть и делит значения пикселов на него. Откройте hdf в другом софте и посмотрите как он пересчитывает.

А он это так может? То есть это еще от софта зависит, а не только от самих данных?

У меня под рукой нет другого софта сейчас, чтобы проверить.

[ericsson]

https://support.hdfgroup.org/products/j ... nload.html

[alexandr cherepanov]

Вот например та же проблема https://gis.stackexchange.com/questions ... ge-in-qgis. Вам же все равно их еще из синусоидальной проекции переводить.

[Natalia Novoselova]

Вот например та же проблема https://gis.stackexchange.com/questions ... ge-in-qgis. Вам же все равно их еще из синусоидальной проекции переводить.

Здесь это декларируется как ошибка QGIS

HDFview software lets you see the metadata, it doesn't report anything it creates. The metadata says the valid range is between -2000 and 10000. NDVI takes values between -1 and 1. The scale factor is 10000, so metadata is correct. However, QGIS displays the raster values wrong. When you open the dataset and read it into an array like this gdal.Open(NDVI dataset).ReadAsArray(), you will see that values are between -2000 and 10000. QGIS is doing something wrong here. It is safe to say there is a bug in QGIS when displaying 16bit integer arrays

Вопрос задали 2 года назад. И ошибка так и осталась.

Вопрос в том, я МОГУ ПРОСТО ПОДЕЛИТЬ ЗНАЧЕНИЯ НА 10000 0000? Или искажение в значениях hdf, которые дает QGIS, могут быть и в другом?
Конечно..ммм.. тут бы проверить..

Вам же все равно их еще из синусоидальной проекции переводить.

Про это не поняла. Да, они в какой-то синусоидальной проекции. Для использования их в своем проекте мне лучше перевести их в другую проекцию? В какую - можно ли в WGS84 EPSG:4326 ?

[Natalia Novoselova]

https://support.hdfgroup.org/products/j ... nload.html

Это софт для чтения hdf ? Не знаю, я открыла этот продукт в SNAP (открытый софт, который читает разные форматы, в т.ч. hdf ). И он показывает те же значения, что и QGIS. То есть - тоже надо делить на 10000 0000. Значит, все-таки это зашито в самих данных, а не ошибка QGIS ...

[alexandr cherepanov]

• Dataset #1: 250m 16 days NDVI
  Dims: INT (4800 x 4800)
  Attribute 1-1: "long_name"
  "250m 16 days NDVI"
  Attribute 1-2: "units"
  "NDVI"
  Attribute 1-3: "valid_range"
  -2000, 10000
  Attribute 1-4: "_FillValue"
  -3000
  Attribute 1-5: "scale_factor"
  10000.00000000
  Attribute 1-6: "scale_factor_err"
  0.00000000
  Attribute 1-7: "add_offset"
  0.00000000
  Attribute 1-8: "add_offset_err"
  0.00000000
  Attribute 1-9: "calibrated_nt"
  5

Если будете просто читать нужный Dataset - получите реальные значения, записанные в файле. Если через ПО, которое пытается как-то эти данные еще и переводить на лету и делает это неправильно (из-за ошибок в ПО или из-за ошибок в метаданных снимка) - будете получать те значения, что получаете.

Если немного умеет работать с GDAL простой код для командной строки.

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

gdalwarp -t_srs EPSG:4326 "HDF4_EOS:EOS_GRID:"d:\mod\MOD13Q1.A2017257.h13v11.006.2017276132641.hdf":MODIS_Grid_16DAY_250m_500m_VI:250m 16 days NDVI" d:\mod\MOD13Q1.A2017257.h13v11.006.2017276132641.tif

Прочитает содержимое MODIS_Grid_16DAY_250m_500m_VI:250m 16 days NDVI из файла d:\mod\MOD13Q1.A2017257.h13v11.006.2017276132641.hdf перепроецирует его в 4326 (можно поставить любую проекцию нужную Вам) и сохранит в новый GeoTiff d:\mod\MOD13Q1.A2017257.h13v11.006.2017276132641.tif

[Natalia Novoselova]

Если через ПО, которое пытается как-то эти данные еще и переводить на лету и делает это неправильно (из-за ошибок в ПО или из-за ошибок в метаданных снимка)

Вы подозреваете все-таки ошибку в QGIS и SNAP?

Вообще - это тот самый вопрос доверия к опытности специалистов... ведь если НЕ доверять (н-р ПО, которое открывает продукт), то это можно вообще всё делать самому, вплоть до того, что скачивать исходные снимки, делать коррекцию и продукты..

Да, конечно, можно так делать.
Но не рядовому пользователю. И не слишком виден смысл.

Ну ладно. Итогом, все-таки ошибка скорее в самих данных. Поскольку QGIS и SNAP показывают одинаковые величины.
Правда тогда, если следовать вашему методу и просто открыть данные, то должно быть то же самое.

[alexandr cherepanov]

И QGIS и SNAP при открытии данных применяют к нему то, что они находят под параметром scale_factor. А там сейчас стоит число 10000, и умножают значения на него. Почему они работают именно так - умножают, а не делят, я не могу знать. Может быть в более старых версиях продукта стояло именно 0.0001. ENVI 5.0 читает все корректно. GDAL сам массив данных читает тоже корректно.

[ericsson]

Нет никакой проблемы. HDF5 в описании содержит избыточность (диапазоны значений) для того, чтобы иметь возможность все проверить и настроить конвертацию. Собственно, даже в описаниях формата строго не сказано, делить или умножать В идеале, при импорте программы должны спрашивать, что делать с этим числом, показывая оценочные значения того, что получится.

[Natalia Novoselova]

Нет никакой проблемы. HDF5 в описании содержит избыточность (диапазоны значений) для того, чтобы иметь возможность все проверить и настроить конвертацию. Собственно, даже в описаниях формата строго не сказано, делить или умножать В идеале, при импорте программы должны спрашивать, что делать с этим числом, показывая оценочные значения того, что получится.

Меня успокоило то, что я поняла, что они просто умножили на scale factor, вместо того чтобы на него поделить. Как-то сначала эта простая мысль не дошла и заподозрила бОльший глюк.


Но остался вопрос с проекциями. Не поняла, почему alexandr cherepanov особенно заострил на том, что

Вам же все равно их еще из синусоидальной проекции переводить.

Просто в отношении QGIS у меня уже были не до конца понятые проблемы с проекциями. Кажется, в отличие от ArcGIS, который предупреждает о несоответствиях или вовсе не открывает данные в разных проекциях, QGIS может открывать в одном проекте данные в разных проекций.. что-то в общем делать из-за чего возникают смещения.

Здесь мне очень критично избежать смещений. Ведь проверить я никак не смогу по наложению.


Можно ли прояснить вопрос с проекциями относительно продуктов MODIS?