Return to Answer

The issue seems to be caused by a problem recognising the fact that the data is in signed 2 byte integer format. It is wrongly interpreted as unsigned 2 byte integer format. Therefore your nodata value of -9999 becomes: 2bytes=256*256 -9999 = 55537

What I find strange is that min value : -9999 and max value : 5483 are the same for both windows and mac. It seems that in both cases no data was not correctly identified when building the headers, but when actually using it for the values an error occured.

possible workaround: edit: robert suggestion is better, because it also handles other negative values values(onWindows)[values(onWindows)==55537]<-NA

To dig deeper: It seems that raster calls rgdal, which in turn call gdal itself. Most likely you have a different version of gdal on your system. Check when loading rgdal eg:

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

I just did a quick check on linux: gdal 1.8 loads the file fine, but gdal 1.6 fails. So it does seem to be caused by gdal.

The issue seems to be caused by a problem recognising the fact that the data is in signed 2 byte integer format. It is wrongly interpreted as unsigned 2 byte integer format. Therefore your nodata value of -9999 becomes: 2bytes=256*256 -9999 = 55537

What I find strange is that min value : -9999 and max value : 5483 are the same for both windows and mac. It seems that in both cases no data was not correctly identified when building the headers, but when actually using it for the values an error occured.

workaround:

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

To dig deeper: It seems that raster calls rgdal, which in turn call gdal itself. Most likely you have a different version of gdal on your system. Check when loading rgdal eg:

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

I just did a quick check on linux: gdal 1.8 loads the file fine, but gdal 1.6 fails. So it does seem to be caused by gdal.

The issue seems to be caused by a problem recognising the fact that the data is in signed 2 byte integer format. It is wrongly interpreted as unsigned 2 byte integer format. Therefore your nodata value of -9999 becomes: 2bytes=256*256 -9999 = 55537

What I find strange is that min value : -9999 and max value : 5483 are the same for both windows and mac. It seems that in both cases no data was not correctly identified when building the headers, but when actually using it for the values an error occured.

possible workaround:

values(onWindows)[values(onWindows)==55537]<-NA

To dig deeper: It seems that raster calls rgdal, which in turn call gdal itself. Most likely you have a different version of gdal on your system. Check when loading rgdal eg:

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

I just did a quick check on linux: gdal 1.8 loads the file fine, but gdal 1.6 fails. So it does seem to be caused by gdal.

The issue seems to be caused by a problem recognising the fact that the data is in signed 2 byte integer format. It is wrongly interpreted as unsigned 2 byte integer format. Therefore your nodata value of -9999 becomes: 2bytes=256*256 -9999 = 55537

What I find strange is that min value : -9999 and max value : 5483 are the same for both windows and mac. It seems that in both cases no data was not correctly identified when building the headers, but when actually using it for the values an error occured.

possible workaround: edit: robert suggestion is better, because it also handles other negative values values(onWindows)[values(onWindows)==55537]<-NA

To dig deeper: It seems that raster calls rgdal, which in turn call gdal itself. Most likely you have a different version of gdal on your system. Check when loading rgdal eg:

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

I just did a quick check on linux: gdal 1.8 loads the file fine, but gdal 1.6 fails. So it does seem to be caused by gdal.

The issue seems to be caused by a problem recognising the fact that the data is in signed 2 byte integer format. It is wrongly interpreted as unsigned 2 byte integer format. Therefore your nodata value of -9999 becomes: 2bytes=256*256 -9999 = 55537

What I find strange is that min value : -9999 and max value : 5483 are the same for both windows and mac. It seems that in both cases no data was not correctly identified when building the headers, but when actually using it for the values an error occured.

possible workaround:

values(onWindows)[values(onWindows)==55537]<-NA

To dig deeper: It seems that raster calls rgdal, which in turn call gdal itself. Most likely you have a different version of gdal on your system. Check when loading rgdal eg:

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

I just did a quick check on linux: gdal 1.8 loads the file fine, but gdal 1.6 fails. So it does seem to be caused by gdal.

UPDATE: a no data value of -9999 is indeed not supported prior to version 1.8 of gdal, you can see the actual commit adding support here: https://github.com/mloskot/gdal/commit/a8c9760ac5f969955135a19e72e9792ccdcce30a and the bugreport here.

The issue seems to be caused by a problem recognising the fact that the data is in signed 2 byte integer format. It is wrongly interpreted as unsigned 2 byte integer format. Therefore your nodata value of -9999 becomes: 2bytes=256*256 -9999 = 55537

What I find strange is that min value : -9999 and max value : 5483 are the same for both windows and mac. It seems that in both cases no data was not correctly identified when building the headers, but when actually using it for the values an error occured.

possible workaround:

values(onWindows)[values(onWindows)==55537]<-NA

To dig deeper: It seems that raster calls rgdal, which in turn call gdal itself. Most likely you have a different version of gdal on your system. Check when loading rgdal eg:

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

I just did a quick check on linux: gdal 1.8 loads the file fine, but gdal 1.6 fails. So it does seem to be caused by gdal.