Проблемы со значениями NA при чтении файла .DEM с R 'растровым' пакетом в Windows

Я пытаюсь прочитать растровый файл в формате .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

Один из обходных путей - просто использовать необработанные данные, поскольку это очень простой формат файла.

Не для всех, но это может быть полезным, чтобы увидеть, что происходит.

## all these details are in the .HDR file
NROWS   <-      6000
NCOLS   <-      4800

На этом этапе вы можете попробовать различные варианты целочисленного знака и порядкового номера напрямую, и, читая таким образом, мы достигаем того, что Роберт делает с > 32767преобразованием после чтения файла.

x1 <- readBin("E020N90.DEM", "integer", size = 2, signed = TRUE, n = NROWS * NCOLS, endian = "big")

range(x1)
[1] -9999  5483

x1[x1 < -9998] <- NA

## now for the simple georeferencing, also in the HDR file

ULXMAP   <-     20.00416666666667
ULYMAP   <-     89.99583333333334
XDIM     <-     0.00833333333333
YDIM     <-     0.00833333333333

## now generate x/y coordinates, and the data matrix (flip on Y)
x <- list(x = seq(ULXMAP, by = XDIM, length = NCOLS),
       y = seq(ULYMAP - NROWS * YDIM, by = YDIM, length = NROWS),
      z = matrix(x1, nrow = NCOLS)[ , NROWS:1])

library(sp)

x <- image2Grid(x)

library(raster)
r <- raster(x)

plot(r)

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

projection(r) <- "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs +towgs84=0,0,0"

РЕДАКТИРОВАТЬ: Ой, забыл вычесть сверху, теперь исправлено - есть еще проблема с полуклеткой, от которой я так и не дошел.

Есть некоторые проблемы с этим файлом или с GDAL. Я использую windows 7

R version 2.13.1 (2011-07-08)
Platform: x86_64-pc-mingw32/x64 (64-bit)

а также

> getGDALVersionInfo()
[1] "GDAL 1.7.2, released 2010/04/23"


> GDALinfo('E020N90.DEM')
rows        6000 
columns     4800 
bands       1 
origin.x        20 
origin.y        40 
res.x       0.008333333 
res.y       0.008333333 
ysign       -1 
oblique.x   0 
oblique.y   0 
driver      EHdr 
projection  +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs 
file        E020N90.DEM 
apparent band summary:
 GDType  Bmin Bmax   Bmean    Bsd hasNoDataValue NoDataValue
1 UInt16 -9999 5483 -4412.9 5088.6           TRUE       -9999
> 

Обратите внимание, что NoDataValue совпадает со значением Bmin (-9999), что нечетно. Хуже всего то, что GDType - это UInt16 - 2-байтовые целые числа без знака - это означает, что вы не можете иметь значения ниже нуля. Вероятно, это ошибка, которая была исправлена ​​в gdal 1.8.0

Проблема иллюстрируется, когда вы делаете

r <- 'E020N90.DEM'
plot(r)

Я думаю, что быстрый способ исправить это:

r <- raster('E020N90.DEM')
fun <- function(x){ x[x > 32767] <- x[x > 32767] - 65536; x[x == -9999] <- NA; x}
r[] <- fun(values(r))

plot(r)
r <- writeRaster(r, 'E020N90.TIF')

Эта проблема, по-видимому, вызвана проблемой распознавания того факта, что данные представлены в двухбайтовом целочисленном формате со знаком. Это неправильно интерпретируется как 2-байтовый формат без знака. Поэтому значение вашего nodata -9999 становится: 2bytes = 256 * 256 -9999 = 55537

Что я нахожу странным, так это то, что минимальное значение: -9999 и максимальное значение: 5483 одинаковы как для Windows, так и для Mac. Кажется, что в обоих случаях никакие данные не были правильно идентифицированы при построении заголовков, но при фактическом использовании их для значений произошла ошибка.

обходной путь:

values(onWindows)[values(onWindows)>128*256]<-values(onWindows)[values(onWindows)>128*256]-256*256
values(onWindows)[values(onWindows)==-9999]<-NA

Чтобы копнуть глубже: кажется, что растр вызывает rgdal, который, в свою очередь, вызывает сам gdal. Скорее всего, в вашей системе установлена ​​другая версия gdal. Проверьте при загрузке rgdal, например:

Loaded GDAL runtime: GDAL 1.8.0, released 2011/01/12

Я только что сделал быструю проверку на linux: gdal 1.8 нормально загружает файл, но gdal 1.6 дает сбой. Так что, похоже, это вызвано GDAL.

Хотя я не уверен в вашем требовании, вы можете конвертировать. DEM файлы в .GRID файлы. Затем гео-процессор ArcGIS или R автоматически распознает .GRID со значениями N / A во время манипулирования растром сетки.