[GRASS-user] Importing a binary file: (a) why isn't the command logged in the maps history? (b) why is the resolution of the imported map slightly different than expected?

GRASS GRASS user
1

[ Sorry for bombing you with questions - I am close to complete my work
and need to clarify all details in my document. And BTW, GRASS plays
bouzouki!!! (something like the greek version of "GRASS Rocks!") ]

Here it goes:

1. cat projection_information.hdr
BANDS: 1
ROWS: 4256
COLS: 8064
INTERLEAVING: NA
DATATYPE: U8
BYTE_ORDER: NA
UL_X_COORDINATE: -25.99107192
UL_Y_COORDINATE: 71.99107144
LR_X_COORDINATE: 45.99998799
LR_Y_COORDINATE: 34.00000609
PIXEL_WIDTH: 0.00892857
PIXEL_HEIGHT: 0.00892857
[...]

2. r.in.bin in=GLC_EU_V2.bil out=glc2000_eu north=71.99107144
south=34.00000609 west=-25.99107192 east=45.99998799 rows=4256 cols=8064

3. r.info -h glc2000_eu
Data Source:
   
Data Description:
   generated by r.in.bin

4. r.info glc2000_eu

[...]
Projection: Latitude-Longitude |
| N: 71:59:27.857184N S: 34:00:00.021924N Res:
0:00:32.1353 |
| E: 45:59:59.956764E W: 25:59:27.858912W Res:
0:00:32.13886
[...]

2

Could it be a cell center / corner issue? Normally header information
gives cell corners...

Cheers
Daniel

On Tue, Mar 18, 2008 at 10:07 AM, Nikos Alexandris
<nikos.alexandris@felis.uni-freiburg.de> wrote:

[ Sorry for bombing you with questions - I am close to complete my work
and need to clarify all details in my document. And BTW, GRASS plays
bouzouki!!! (something like the greek version of "GRASS Rocks!") ]

Here it goes:

1. cat projection_information.hdr
BANDS: 1
ROWS: 4256
COLS: 8064
INTERLEAVING: NA
DATATYPE: U8
BYTE_ORDER: NA
UL_X_COORDINATE: -25.99107192
UL_Y_COORDINATE: 71.99107144
LR_X_COORDINATE: 45.99998799
LR_Y_COORDINATE: 34.00000609
PIXEL_WIDTH: 0.00892857
PIXEL_HEIGHT: 0.00892857
[...]

2. r.in.bin in=GLC_EU_V2.bil out=glc2000_eu north=71.99107144
south=34.00000609 west=-25.99107192 east=45.99998799 rows=4256 cols=8064

3. r.info -h glc2000_eu
Data Source:

Data Description:
   generated by r.in.bin

4. r.info glc2000_eu

[...]
Projection: Latitude-Longitude |
  | N: 71:59:27.857184N S: 34:00:00.021924N Res:
0:00:32.1353 |
  | E: 45:59:59.956764E W: 25:59:27.858912W Res:
0:00:32.13886
[...]

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

3

On Tue, 2008-03-18 at 11:04 -0300, Daniel Victoria wrote:

Could it be a cell center / corner issue? Normally header information
gives cell corners...

Cheers
Daniel

Daniel,

You are the Man! Correct!

1. gdalinfo /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.bil -noct
Driver: EHdr/ESRI .hdr Labelled
Files: /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.bil
       /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.hdr
       /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.stx
       /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.clr
Size is 8064, 4256
Coordinate System is `'
Origin = (-25.995536206400001,71.995535723208150)
Pixel Size = (0.008928570000000,-0.008928570000000)
Corner Coordinates:
Upper Left ( -25.9955362, 71.9955357)
Lower Left ( -25.9955362, 33.9955418)
Upper Right ( 46.0044523, 71.9955357)
Lower Right ( 46.0044523, 33.9955418)
Center ( 10.0044580, 52.9955388)
Band 1 Block=8064x1 Type=Byte, ColorInterp=Palette
  Min=0.000 Max=23.000
  Minimum=0.000, Maximum=23.000, Mean=16.000, StdDev=5.800
  Color Table (RGB with 256 entries)

(Compare gdalinfo report with corner coordinates given in the file
projection_information.hdr )

2. cat projection_information.hdr
[...]
UL_X_COORDINATE: -25.99107192
UL_Y_COORDINATE: 71.99107144
LR_X_COORDINATE: 45.99998799
LR_Y_COORDINATE: 34.00000609
[...]

3. r.in.bin in=GLC_EU_V2.bil out=glc2000_eu_test north=71.9955357
south=33.9955418 west=-25.9955362 east=46.0044523 rows=4256 cols=8064

4. r.info glc2000_eu_test -s
nsres=0:00:32.142852
ewres=0:00:32.142852

[ Youuuuuuuhohooohohooh........ !!!!]

4

On Tue, 2008-03-18 at 15:24 +0100, Nikos Alexandris wrote:

2. cat projection_information.hdr
[...]
UL_X_COORDINATE: -25.99107192
UL_Y_COORDINATE: 71.99107144
LR_X_COORDINATE: 45.99998799
LR_Y_COORDINATE: 34.00000609
[...]

And just to make sure that the correct corner coordinates are not given
anywhere else:

cat GLC_EU_V2.hdr
BYTEORDER I
LAYOUT BIL
NROWS 4256
NCOLS 8064
NBANDS 1
NBITS 8
BANDROWBYTES 8064
TOTALROWBYTES 8064
BANDGAPBYTES 0

5

Daniel Victoria wrote:
> Could it be a cell center / corner issue? Normally header information
> gives cell corners...

Nikos:

You are the Man! Correct!

1. gdalinfo /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.bil -noct
Driver: EHdr/ESRI .hdr Labelled
Files: /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.bil
       /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.hdr
       /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.stx
       /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.clr
Size is 8064, 4256

If gdalinfo can read it, why not use r.in.gdal instead of r.in.bin?
It's less work.

(a) why isn't the command logged in the maps history?

r.in.bin and r.in.ascii now updated in 6.3svn to write out command
history. (This has had to be done manually for all modules which create
raster maps. We have now done this for most of the common modules and so
it is encouraging for folks to find it strange when it is missing)

Hamish

      ____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

6

On Wed, 2008-03-19 at 00:20 -0700, Hamish wrote:

> Daniel Victoria wrote:
> > Could it be a cell center / corner issue? Normally header information
> > gives cell corners...

Nikos:
> You are the Man! Correct!
>
> 1. gdalinfo /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.bil -noct
> Driver: EHdr/ESRI .hdr Labelled
> Files: /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.bil
> /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.hdr
> /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.stx
> /home/nik/grassdb/tmp/glc2000/Binary/GLC_EU_V2.clr
> Size is 8064, 4256

If gdalinfo can read it, why not use r.in.gdal instead of r.in.bin?
It's less work.

Correct! But, for the sake of demonstration, I will keep both ways in my
document.

> (a) why isn't the command logged in the maps history?

r.in.bin and r.in.ascii now updated in 6.3svn to write out command
history. (This has had to be done manually for all modules which create
raster maps. We have now done this for most of the common modules and so
it is encouraging for folks to find it strange when it is missing)

Hamish,

I am sorry but my english has its (greek) limits. You write "it is
encouraging ... to find it strange" but I don't understand what this
means. Can you please explain? Maybe it's nothing important or so
easy... but I don't get it right now (?)