Problemas com valores de NA ao ler o arquivo .DEM com o pacote R 'raster' no Windows

Eu estou tentando ler um arquivo raster em um formato .DEM no Windows usando o pacote 'raster' em R.

Tenho problemas com os valores de NA ao carregar os dados no R no Windows 7, mas não tenho o problema em um Mac com OSX Lion. No Windows, os valores de NA não parecem ser lidos corretamente. A questão é por que isso acontece?

O arquivo de varredura usado foi baixado do USGS com o seguinte código R:

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

Então eu li o raster no R usando o pacote 'raster'. No OSX Lion e R64 versão 2.13.1, os valores de NA são reconhecidos:

> 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

Mas no Windows 7 (64Bit, mesma versão R), ele converte os valores das células que devem ser de NA em números:

> 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

Por que não há valores de NA na varredura quando a leio no Windows? Como eu poderia contornar isso? Meu palpite é que tem a ver com a maneira como os números são armazenados, muitos valores de NA são convertidos em 55540.

Informações do Windows (após o carregamento da varredura):

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

Informações do OSX (após o carregamento da varredura):

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

Uma solução alternativa é usar os dados brutos, pois esse é um formato de arquivo muito simples.

Não é para todos, mas pode ser esclarecedor ver o que está acontecendo.

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

Nesse ponto, você pode tentar as diferentes opções de sinal inteiro e endianidade diretamente, e lendo dessa maneira, conseguimos o que Robert faz com a > 32767transformação após a leitura do arquivo.

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)

Por fim, defina a projeção conforme lida por varredura (e isso daria a mesma proporção no gráfico que é visto quando lido dessa maneira).

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

Edição: Opa, tinha esquecido de subtrair do topo, agora corrigido - ainda há um problema de meia célula que eu não cheguei ao fundo também.

Há alguns problemas com este arquivo ou com o GDAL. Estou usando o 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
> 

Observe que o NoDataValue é igual ao valor Bmin (-9999), o que é ímpar. O pior é que GDType é UInt16 - Inteiros não assinados de 2 bytes - o que significa que você não pode ter valores inferiores a zero. Este é provavelmente um bug que foi corrigido no gdal 1.8.0

O problema é ilustrado quando você faz

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

Eu acho que a maneira mais rápida de corrigir isso é:

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

O problema parece ser causado por um problema ao reconhecer o fato de que os dados estão no formato inteiro assinado de 2 bytes. É interpretado incorretamente como formato inteiro não assinado de 2 bytes. Portanto, seu valor nodata de -9999 se torna: 2bytes = 256 * 256 -9999 = 55537

O que eu acho estranho é que o valor mínimo: -9999 e o valor máximo: 5483 são os mesmos para Windows e Mac. Parece que em ambos os casos, nenhum dado não foi identificado corretamente ao criar os cabeçalhos, mas ao usá-lo para os valores, ocorreu um erro.

Gambiarra:

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

Para aprofundar: Parece que a varredura chama rgdal, que por sua vez chama a própria gdal. Provavelmente você tem uma versão diferente do gdal no seu sistema. Verifique ao carregar o rgdal, por exemplo:

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

Acabei de fazer uma verificação rápida no linux: o gdal 1.8 carrega bem o arquivo, mas o gdal 1.6 falha. Por isso, parece ser causado por gdal.

Embora eu não tenha certeza sobre sua exigência, você pode converter. Arquivos DEM em arquivos .GRID. Em seguida, o geoprocessador arcgis ou R reconhecerá automaticamente .GRIDs com valores N / A durante a manipulação de varredura de grade.