Me again.
I am attempting to import what I think is an 8 bit unsigned binary data file from USGS. When I use the north, south, east, west parameters (used to define the region) in r.in.bin, it generates a filesize error, and gives me a negative value for total bytes and suggest trying bytes=0. When I use the row, column parameters, r.in.bin generates a raster that is about 10 times smaller than the data file. d.rast generates a blank screen (or maybe a really tiny map). Am I missing an intermediate step or two between r.in.bin and d.rast?
I have pasted the data info that comes with the datafile, and that I used to generate the region and plug into r.in.bin:
2.2 Lambert Azimuthal Equal Area Projection Parameters
The data dimensions of the Lambert Azimuthal Equal Area projection for the North America land cover characteristics data set are 8,996 lines (rows) and 9,223 samples (columns) resulting in a data set size of approximately 83 megabytes for 8-bit (byte) images. The following is a summary of the map projection parameters used for this projection:
Projection Type: Lambert Azimuthal Equal Area
Units of Measure: meters
Pixel Size: 1000 meters
Radius of sphere: 6370997 m
Longitude of origin: 100 00 00 W
Latitude of origin: 50 00 00 N
False easting: 0.0
False northing: 0.0
XY corner coordinates (center of pixel) in projection units (meters):
Lower left: (-4487000, -4515000)
Upper left: (-4487000, 4480000)
Upper right: (4735000, 4480000)
Lower right: (4735000, -4515000)
> So I managed to import the data using r.in.bin with r=8996, c=9223, and am
> currently messing around with r.support to get the output I want. However,
> there is a mismatch between the actual (81,026kb) and calculated file size
> (based on row x cols: 82,970kb). What does this mean?
Let me guess that you have to extend the region to be
imported by 0.5 pixel in all directions. The famous thing
of refering to cornder or pixel center coordinates...
instead of (example)
r.in.bin n=5 s=4 w=22 e=25 ...
is would be
r.in.bin n=5.5 s=3.5 w=21.5 e=25.5 ...
assuming a pixel size of 1.
Correct. However, r.in.bin still doesn't accept the data with the modified n, s, w, e, values, only with the original r, c values. I still have to make the pixel corner/center adjustment in r.support (which from what I understand is essentially affecting the LOCATION). Is the file size discrepancy affecting the accuracy and/or validity of the map I am producing, or is it just an accounting problem that I shouldn't lose sleep over?
Thanks again.
Martin
Martin du Saire wrote:
> So I managed to import the data using r.in.bin with r=8996, c=9223, and am
> > currently messing around with r.support to get the output I want. However,
> > there is a mismatch between the actual (81,026kb) and calculated file size
> > (based on row x cols: 82,970kb). What does this mean?
The mismatch is due to the difference between 1000 bytes and a
kilobyte (1024 bytes):
8996 * 9223 = 82970108 bytes.
82970108 / 1000 = 82970
82970108 / 1024 = 81025
--
Glynn Clements <glynn.clements@virgin.net>