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

Я намагаюся прочитати растровий файл у форматі .DEM на Windows, використовуючи пакет 'растр' у Р.

У мене виникають проблеми зі значеннями 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, використовуючи пакет 'растр'. У 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"

EDIT: Уопс, забув відняти зверху, тепер виправлений - все ще існує проблема із півклітиною, до якої я також не потрапив.

Є деякі проблеми з цим файлом або з 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-байтовому цілому форматі. Це неправильно трактується як неподписаний 2-байтний цілочисельний формат. Тому значення вашого нодату -9999 стає: 2байта = 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-файли. Потім геопроцесор дуги або R автоматично розпізнає .GRID із значеннями N / A під час маніпуляції з растровими сітками.