Я пытаюсь прочитать растровый файл в формате .DEM в Windows, используя пакет 'raster' в R.
У меня возникают проблемы со значениями NA при загрузке данных в R в Windows 7, но у меня нет проблем на Mac с OSX Lion. На окнах значения NA, кажется, не читаются правильно. Вопрос в том, почему это происходит?
Используемый растровый файл был загружен из USGS со следующим R-кодом:
download.file('http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/e020n90.tar.gz', 'e020n90.tar.gz')
untar('e020n90.tar.gz')
Затем я прочитал растр в R, используя пакет 'raster'. В OSX Lion и R64 версии 2.13.1 значения NA распознаются:
> onMac <- raster('E020N90.DEM')
> onMac
class : RasterLayer
dimensions : 6000, 4800, 28800000 (nrow, ncol, ncell)
resolution : 0.008333333, 0.008333333 (x, y)
extent : 20, 60, 40, 90 (xmin, xmax, ymin, ymax)
coord. ref. : +proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs
values : /Users/Tam/Desktop/E020N90.DEM
min value : -9999
max value : 5483
> summary(values(onMac))
Min. 1st Qu. Median Mean 3rd Qu. Max. NA's
-137 85 148 213 213 5483 13046160
Но в Windows 7 (64Bit, та же версия R) она преобразует значения ячеек, которые должны быть в NA, в числа:
> onWindows <- raster('E020N90.DEM')
> onWindows
class : RasterLayer
dimensions : 6000, 4800, 28800000 (nrow, ncol, ncell)
resolution : 0.008333333, 0.008333333 (x, y)
extent : 20, 60, 40, 90 (xmin, xmax, ymin, ymax)
coord. ref. : +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs +towgs84=0,0,0
values : E:/WorldDegreeDays/gsoddata/gtopo/E020N90.DEM
min value : -9999
max value : 5483
> summary(values(onWindows))
Min. 1st Qu. Median Mean 3rd Qu. Max.
1 150 946 27190 55540 65540
Почему нет значений NA в растре, когда я читаю его в Windows? Как я мог обойти это? Я думаю, это связано с тем, как хранятся числа, многие значения NA преобразуются в 55540.
Информация из Windows (после загрузки растра):
SessionInfo()
R version 2.13.1 (2011-07-08)
Platform: x86_64-pc-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] rgdal_0.7-1 raster_1.9-12 sp_0.9-88
loaded via a namespace (and not attached):
[1] grid_2.13.1 lattice_0.19-30
Информация из OSX (после загрузки растра):
R version 2.13.1 (2011-07-08)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base
other attached packages:
[1] rgdal_0.6-33 raster_1.9-12 sp_0.9-88
loaded via a namespace (and not attached):
[1] grid_2.13.1 lattice_0.19-33
sessionInfo()
в свой пост?Ответы:
Один из обходных путей - просто использовать необработанные данные, поскольку это очень простой формат файла.
Не для всех, но это может быть полезным, чтобы увидеть, что происходит.
На этом этапе вы можете попробовать различные варианты целочисленного знака и порядкового номера напрямую, и, читая таким образом, мы достигаем того, что Роберт делает с
> 32767
преобразованием после чтения файла.Наконец, установите проекцию так, как она читается растром (и это дало бы такое же соотношение сторон на графике, которое видно при прочтении таким образом).
РЕДАКТИРОВАТЬ: Ой, забыл вычесть сверху, теперь исправлено - есть еще проблема с полуклеткой, от которой я так и не дошел.
источник
r <- raster('E020N90.DEM')
и затем запуститьvalues(r)<-readBin("E020N90.DEM", "integer", size = 2, signed = TRUE, n = nrows(r) * ncols(r), endian = "big")
и затемvalues(r)[values(r)==-9999]<-NA
Есть некоторые проблемы с этим файлом или с GDAL. Я использую windows 7
а также
Обратите внимание, что NoDataValue совпадает со значением Bmin (-9999), что нечетно. Хуже всего то, что GDType - это UInt16 - 2-байтовые целые числа без знака - это означает, что вы не можете иметь значения ниже нуля. Вероятно, это ошибка, которая была исправлена в gdal 1.8.0
Проблема иллюстрируется, когда вы делаете
Я думаю, что быстрый способ исправить это:
источник
Эта проблема, по-видимому, вызвана проблемой распознавания того факта, что данные представлены в двухбайтовом целочисленном формате со знаком. Это неправильно интерпретируется как 2-байтовый формат без знака. Поэтому значение вашего nodata -9999 становится: 2bytes = 256 * 256 -9999 = 55537
Что я нахожу странным, так это то, что минимальное значение: -9999 и максимальное значение: 5483 одинаковы как для Windows, так и для Mac. Кажется, что в обоих случаях никакие данные не были правильно идентифицированы при построении заголовков, но при фактическом использовании их для значений произошла ошибка.
обходной путь:
Чтобы копнуть глубже: кажется, что растр вызывает rgdal, который, в свою очередь, вызывает сам gdal. Скорее всего, в вашей системе установлена другая версия gdal. Проверьте при загрузке rgdal, например:
Loaded GDAL runtime: GDAL 1.8.0, released 2011/01/12
Я только что сделал быструю проверку на linux: gdal 1.8 нормально загружает файл, но gdal 1.6 дает сбой. Так что, похоже, это вызвано GDAL.
источник
rgdal
можно найти обновленнуюgdal
установку на Win7? Я скачал и установил самые последниеgdal
двоичные файлы (32 и 64). Они были установлены в папку по умолчанию, ноrgdal
все еще используют 1.7.2, даже после обновления.Хотя я не уверен в вашем требовании, вы можете конвертировать. DEM файлы в .GRID файлы. Затем гео-процессор ArcGIS или R автоматически распознает .GRID со значениями N / A во время манипулирования растром сетки.
источник
system2
.