Problemi con i valori NA durante la lettura del file .DEM con il pacchetto R 'raster' in Windows

Sto cercando di leggere un file raster in formato .DEM su Windows usando il pacchetto 'raster' in R.

Ottengo problemi con i valori NA durante il caricamento dei dati in R in Windows 7, ma non ho il problema su un Mac con OSX Lion. Su Windows, i valori NA non sembrano essere letti correttamente. La domanda è: perché succede?

Il file raster utilizzato è stato scaricato da USGS con il seguente codice R:

download.file('http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/e020n90.tar.gz', 'e020n90.tar.gz')
untar('e020n90.tar.gz')

Quindi ho letto il raster in R usando il pacchetto "raster". In OSX Lion e R64 versione 2.13.1, i valori NA sono riconosciuti:

> 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

Ma su Windows 7 (64 bit, stessa versione R) converte i valori delle celle che dovrebbero essere NA in numeri:

> 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

Perché non ci sono valori NA nel raster quando lo leggo su Windows? Come potrei aggirarlo? Suppongo che abbia a che fare con il modo in cui sono memorizzati i numeri, molti dei valori NA vengono convertiti in 55540.

Informazioni da Windows (dopo aver caricato il raster):

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

Informazioni da OSX (dopo aver caricato il raster):

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

Una soluzione alternativa è solo quella di cercare i dati grezzi, poiché si tratta di un formato di file molto semplice.

Non per tutti, ma può essere illuminante vedere cosa sta succedendo.

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

A questo punto puoi provare direttamente le diverse opzioni per il segno intero e l'endianness, e leggendo in questo modo otteniamo ciò che Robert fa con la > 32767trasformazione dopo la lettura del file.

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)

Infine, imposta la proiezione così come viene letta dal raster (e questo darebbe le stesse proporzioni nella trama che si vede leggendo in quel modo).

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

EDIT: Whoops, aveva dimenticato di sottrarre dall'alto, ora risolto - c'è ancora un problema a mezza cellula che non sono riuscito a capire.

Ci sono alcuni problemi con questo file o con GDAL. Sto usando Windows 7

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

e

> 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
> 

Notare che NoDataValue è uguale al valore Bmin (-9999), che è dispari. Quel che è peggio è che GDType è UInt16 - Integer a 2 byte senza segno - il che significa che non è possibile avere valori inferiori a zero. Questo è probabilmente un bug che è stato corretto in gdal 1.8.0

Il problema è illustrato quando lo fai

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

Penso che il modo veloce per risolvere questo problema sia:

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')

Il problema sembra essere causato da un problema che riconosce il fatto che i dati sono in formato intero a 2 byte con segno. Viene erroneamente interpretato come formato intero a 2 byte senza segno. Pertanto il valore dei nodati di -9999 diventa: 2byte = 256 * 256 -9999 = 55537

Quello che trovo strano è quel valore minimo: -9999 e il valore massimo: 5483 sono gli stessi sia per Windows che per Mac. Sembra che in entrambi i casi non siano stati identificati correttamente i dati durante la creazione delle intestazioni, ma quando si sono effettivamente utilizzati per i valori si è verificato un errore.

soluzione alternativa:

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

Per approfondire: sembra che il raster chiami rgdal, che a sua volta chiama gdal stesso. Molto probabilmente hai una versione diversa di gdal sul tuo sistema. Controllare durante il caricamento di rgdal ad es .:

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

Ho appena fatto un rapido controllo su Linux: gdal 1.8 carica bene il file, ma gdal 1.6 fallisce. Quindi sembra essere causato da Gdal.

Anche se non sono sicuro del tuo requisito, puoi convertirlo. File DEM in file .GRID. Quindi, il geoprocessore arcgis o R riconoscerà automaticamente .GRID con valori N / A durante la manipolazione del raster della griglia.