[GRASS5] r.example on spearfish60 data

GRASS GIS GRASS GIS developer
1

Hello,

Sorry. I'm not sure this is the best place to post this newbie
question, but maybe you can redirect me to the right list.

Trying my Grass 6.0.1 under cygwin (compiled by myself) with the most
basic sample code, (r.example)[1] on the spearfish60 data [2], I
realized that the input and output raster maps don't match. The basic
code is a loop G_get_raster_row (...), then G_put_raster_row (...)
with no transformation, but the raster map "PERMANENT/cell/density",
size 16853, converts to "user1/cell/d",size 180759, using same region
parameters. Size x 10!!.

user> grass spearfish60/user1
$ g.region ...
$ r.example input=density output=d
$ ls -l spearfish60/PERMANENT/cell/density spearfish60/user1/cell/d

Is this size increment a normal behaviour? Didn't spearfish60 data
maps optimized for grass 6.0x data formats?

Thanks

[1] http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/raster/
[2] http://grass.itc.it/download/data6.php

--
-- marcos boullón magán

2

marcos boullón magán wrote:

Sorry. I'm not sure this is the best place to post this newbie
question, but maybe you can redirect me to the right list.

Trying my Grass 6.0.1 under cygwin (compiled by myself) with the most
basic sample code, (r.example)[1] on the spearfish60 data [2], I
realized that the input and output raster maps don't match. The basic
code is a loop G_get_raster_row (...), then G_put_raster_row (...)
with no transformation, but the raster map "PERMANENT/cell/density",
size 16853, converts to "user1/cell/d",size 180759, using same region
parameters. Size x 10!!.

user> grass spearfish60/user1
$ g.region ...
$ r.example input=density output=d
$ ls -l spearfish60/PERMANENT/cell/density spearfish60/user1/cell/d

Is this size increment a normal behaviour? Didn't spearfish60 data
maps optimized for grass 6.0x data formats?

What does:

  diff -u PERMANENT/cellhd/density user1/cellhd/d

say?

--
Glynn Clements <glynn@gclements.plus.com>

3

2005/12/23, Glynn Clements <glynn@gclements.plus.com>:

marcos boullón magán wrote:

> Sorry. I'm not sure this is the best place to post this newbie
> question, but maybe you can redirect me to the right list.
>
> Trying my Grass 6.0.1 under cygwin (compiled by myself) with the most
> basic sample code, (r.example)[1] on the spearfish60 data [2], I
> realized that the input and output raster maps don't match. The basic
> code is a loop G_get_raster_row (...), then G_put_raster_row (...)
> with no transformation, but the raster map "PERMANENT/cell/density",
> size 16853, converts to "user1/cell/d",size 180759, using same region
> parameters. Size x 10!!.
>
> user> grass spearfish60/user1
> $ g.region ...
> $ r.example input=density output=d
> $ ls -l spearfish60/PERMANENT/cell/density spearfish60/user1/cell/d
>
> Is this size increment a normal behaviour? Didn't spearfish60 data
> maps optimized for grass 6.0x data formats?

What does:

        diff -u PERMANENT/cellhd/density user1/cellhd/d

say?

--
Glynn Clements <glynn@gclements.plus.com>

You were right! The "e-w resol", "n-s resol" were changed from 100 to
10 for this map, therefor the x10 increase in the data. I only checked
the WIND file in both mapsets, not the cellhd files. Never more.

(BTW: I assume the x10 size increase instead a predicted x100
--resolution changed in the both dimensions x10-- is because the map
is stored in compressed format; could anyone confirm?)

Thanks a lot.

M.

GRASS 6.0.1 (spearfish60):~/trabajo/grass/data/spearfish60 > ls PERMANENT/cell
/density user1/cell/density -la
-rw-r--r-- 1 marcos mkgroup-l-d 16853 Nov 5 2001 PERMANENT/cell/density
-rw-r--r-- 1 marcos mkgroup-l-d 180759 Dec 19 18:31 user1/cell/density

GRASS 6.0.1 (spearfish60):~/trabajo/grass/data/spearfish60 > diff -u PERMANENT/
cellhd/density user1/cellhd/density
--- PERMANENT/cellhd/density 2001-11-05 12:13:24.000000000 +0100
+++ user1/cellhd/density 2005-12-19 18:31:38.000000000 +0100
@@ -1,12 +1,12 @@
proj: 1
zone: 13
north: 4928000
-south: 4914000
+south: 4914020
east: 609000
-west: 590000
-cols: 190
-rows: 140
-e-w resol: 100
-n-s resol: 100
+west: 590010
+cols: 1899
+rows: 1398
+e-w resol: 10
+n-s resol: 10
format: 0
compressed: 1

--
-- marcos boullón magán

4

marcos boullón magán wrote:

(BTW: I assume the x10 size increase instead a predicted x100
--resolution changed in the both dimensions x10-- is because the map
is stored in compressed format; could anyone confirm?)

Probably. By default, integer rasters are stored using run-length
encoding. A run of 2 or more cells with the same value only takes one
byte more than a single cell.

It's likely that each map row takes almost the same amount of space
regardless of the resolution, so the 10-fold increase simply reflects
the 10-fold increase in the number of rows (there is no inter-row
compression).

--
Glynn Clements <glynn@gclements.plus.com>