[R-sig-Geo] Dear Friends,

[Michael Sumner]

Apparently it's common for extra bytes to be added by Fortran "raw 
binary" writers. I don't know exactly, but I had to figure this out by 
trial and error for some binary versions of the Reynolds SST products - 
that had precise descriptions of the file arrangement that doesn't 
include the extra bytes. Some colleagues with more experience confirmed 
that there were some strange additional bytes to be expected from Fortran.

ftp://podaac.jpl.nasa.gov/pub/sea_surface_temperature/reynolds/oisst/software/v2/README.v2
When reading from these files you can see the bytes that I ignore as 
"junk", the rest of the data in there is tidy and predictable:

    if (length(grep(".gz", fl)) == 1)
      con <- gzfile(file.path(dir, fl), "rb") else    con <- 
file(file.path(dir, fl), "rb")
   
    head <- readBin(con, "integer", size = 4, n = 11, endian = "big",  
signed = FALSE)
    temps <- readBin(con, "numeric", size = 4, n = 180 * 360,endian = "big")
    junk <- readBin(con, "integer", size = 4, endian = "big", n = 2)

    err <- readBin(con, "numeric", size = 4, n = 180 * 360, endian = "big")
    junk <- readBin(con, "integer", size = 4, endian = "big", n = 2)
    ice <- readBin(con, "integer", size = 1, n = 180 * 360, endian = 
"big",signed = FALSE)

    close(con)

HTH
Cheers, Mike.
Roger Bivand wrote:
> On Fri, 23 May 2008, Rodrigo W. Soria Auza wrote:
>
>> Hi all,
>> I have a file (MOD06_auza_gridded_cldstats.bin) created by a college 
>> (Richard Frey). It is a binary written with FORTRAN in a 
>> little-endian (Linux) machine that contains a 400x300x84-bite integer 
>> array.
>
> If you have access to the Fortran source code, use readBin() to read 
> the chunks. I'm puzzled by the 84 bytes, because that suggests that 
> each cell record contains more than 8 8-byte double precision numbers 
> (which would be 64 bytes). So you need a more detailed description 
> than you have now.
>
> If you read the data into pre-allocated vectors (perhaps grouped in a 
> list), thes can readily be converted to a data frame. This can be 
> converted into a SpatialPointsDataFrame (class defiled in the sp 
> package) and further to a SpatialGridDataFrame. This can then be 
> exported using writeGDAL() in the rgdal package, to a range of 
> different formats, defined by the drivers in your installed GDAL, see 
> gdalDrivers() for the ones you have.
>
> Roger
>
>> The 400 represents 1/20 degree cells in a N-S direction (7S-27S), 300 
>> is 1/20 degree cells in the E-W direction (55-70W). The 8 products in 
>> order for each of the 120000 cells:
>> 1) Number retrievals
>> 2) Yearly mean cloud fraction
>> 3) Frequency of high, thick clouds
>> 4) Frequency of thick clouds top temperatures <-65C
>> 5) Same as # 4 but <-38C
>> 6) Same as # 4 but <-12C
>> 7) Center of cell latitude
>> 8) Center of cell longitude
>> So as you can see is a multi layer file
>> Now neither Richard (the guy who made this file) nor I know how to 
>> import this kind of file into other GIS software, and I would like to 
>> know if somebody here could give us detailed instructions or advise 
>> to convert layer by layer into a common format (separate from each 
>> other. so we could manage every layer independently from the others), 
>> so we will be able to import them into other GIS software (Arcview or 
>> DIVA GIS) as raster (or grid) layers. (maybe ascii?).
>> I have a limited experience using R, but every day I learn a bit more 
>> and I think (actually hope) there is a package that is able to do this.
>> Sincerely,
>> Rodrigo
>>
>>
>>
>