[GRASSLIST:2750] r.patch multiple maps

Hi,

I attempted to use r.patch -z input=bufferzone,map1,map2,... output=map_data_in_bufferzone

to fill a zone with data from multiple maps, but the procedure only merged data from the first map in the list (map1). No error was reported. In order to map all maps into bufferzone, I ended up

r.patch input=map1,map2,map3,... output=all_maps
r.patch -z input=bufferzone,all_maps output=map_data_in_bufferzone

Is it necessary to do this in two steps?

Thanks. This is great software, now if I only knew what I was doing...

Martin

Martin du Saire wrote:

I attempted to use r.patch -z input=bufferzone,map1,map2,...
output=map_data_in_bufferzone

to fill a zone with data from multiple maps, but the procedure only merged
data from the first map in the list (map1). No error was reported. In
order to map all maps into bufferzone, I ended up

r.patch input=map1,map2,map3,... output=all_maps
r.patch -z input=bufferzone,all_maps output=map_data_in_bufferzone

Is it necessary to do this in two steps?

I don't know if this is relevant to your problem, but there appears to
be a bug in r.patch when the -z switch is used.

Note that the -z switch exists primarily for historical reasons.
Versions of GRASS prior to version 5 didn't have a distinguished null
value, but many programs treated zero as no-data.

GRASS 5 uses a distinguished null value for no-data cells. Maps which
use zero to indicate no-data should be converted to use null using
"r.null map=... setnull=0".

--
Glynn Clements <glynn.clements@virgin.net>

At 11:25 PM 2/25/2004 +0000, you wrote:

>
> r.patch input=map1,map2,map3,... output=all_maps
> r.patch -z input=bufferzone,all_maps output=map_data_in_bufferzone
>
> Is it necessary to do this in two steps?

I don't know if this is relevant to your problem, but there appears to
be a bug in r.patch when the -z switch is used.

Note that the -z switch exists primarily for historical reasons.
Versions of GRASS prior to version 5 didn't have a distinguished null
value, but many programs treated zero as no-data.

GRASS 5 uses a distinguished null value for no-data cells. Maps which
use zero to indicate no-data should be converted to use null using
"r.null map=... setnull=0".

Okay, I guess I could have reclassed the buffer zone to NULL and then used the default r.patch, correct? If so, that may actually save me a couple of steps along the way.

Thanks.

Martin

> > r.patch input=map1,map2,map3,... output=all_maps
> > r.patch -z input=bufferzone,all_maps output=map_data_in_bufferzone
> >
> > Is it necessary to do this in two steps?
>
>I don't know if this is relevant to your problem, but there appears to
>be a bug in r.patch when the -z switch is used.
>
>Note that the -z switch exists primarily for historical reasons.
>Versions of GRASS prior to version 5 didn't have a distinguished null
>value, but many programs treated zero as no-data.
>
>GRASS 5 uses a distinguished null value for no-data cells. Maps which
>use zero to indicate no-data should be converted to use null using
>"r.null map=... setnull=0".

Okay, I guess I could have reclassed the buffer zone to NULL and then used
the default r.patch, correct? If so, that may actually save me a couple of
steps along the way.

also note r.patch uses the maps in order for priority, e.g.

input=map7,map5,map3

if data exists for all maps, the value from the first one (here map7) is
used.

So if your buffer map covers the whole space, only its values will be used.

Better to use r.mask.

Hamish