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
_______________________________________________
R-sig-Geo mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
