[GRASSLIST:7572] Interior Buffers

GRASS GRASS user
1

using r.buffer how might I perform an interior buffer. That is take the outside of a raster clump (from r.clump) and make concentric internal buffers at 100, 200, 300 meters etc?.

The use is determining a wheighted score for habitat sensitive to edge disturbances.... check out http://www.udel.edu/johnmack/frec682/682proj2.html right at the end, fourth paragraph from the bootom.

this would be a benifical discovery. I thought of using a centroid and buffering out from that, but that is not accurate for the EDGE distaurbance

I tried using -100,-200 (no quotes) etc and also '-100' (single quote) and "-100" (double quote). No mention in the MAN pages of 6.0 or past versions.

Crucials:
Cygwin GRASS 6.1 CVS through Cygwin install
windows XP

don't imagine it is something on compiling as its a process that should be inherent somewhere.

Thanks

--
+---------------------------------------------------------------+
|Dave Sampson: Geographic Information System (GIS) Technician |
| |
|Centre for Sustainable Watersheds |
|Cooperative Approaches to Protect Canada's Water Resources |
| |
|14 Water St, P.O Box 280. Portland Ontario, Canada. K0G 1V0 |
|Lat: 44.700 Long: -76.19 |
|www.watersheds.ca gis@watersheds.ca |
+---------------------------------------------------------------+

2

David

From: "Dave Sampson" <gis@watersheds.ca>

using r.buffer how might I perform an interior buffer. That is take the outside of a raster clump (from r.clump) and make concentric internal buffers at 100, 200, 300 meters etc?.

Accidently I have found the functionality you are interested in in v.buffer, which seems to be a undocumented feature or a bug.

Anyway: if the input for v.buffer is a *closed* *line* (not the area), then the output is an "internal buffer" :slight_smile: area polygon, which is of about *twice* the extent you provide in option "buffer=".

I have reported it as a bug http://intevation.de/rt/webrt?serial_num=3427.

After rethinking it, I'm not sure what to think. It seems a kind of bug on one hand, especially that the "internal buffer" size is 2 x the buffer required, and a cool functionality on the other.

The best IMHO would be to extend v.buffer to be able to create such "internal buffers" in a controlled and documented way. Any chances? What do others think?

Maciek

3

On Mon, 18 Jul 2005 00:35, Dave Sampson wrote:

using r.buffer how might I perform an interior buffer. That is take the
outside of a raster clump (from r.clump) and make concentric internal
buffers at 100, 200, 300 meters etc?.

have you tried:
r.mapcalc outside='if(isnan(clump),1,nan())'

then using r.buffer on outside?

Regards
Gordon

--

Gordon Keith
Programmer/Data Analyst
Marine Acoustics
CSIRO Marine and Atmospheric Research
http://www.cmar.csiro.au

I believe OS/2 is destined to be the most important operating system,
and possibly program, of all time.
   -- Bill Gates

4

Accidently I have found the functionality you are interested in in
v.buffer, which seems to be a undocumented feature or a bug.

Anyway: if the input for v.buffer is a *closed* *line* (not the area),
then the output is an "internal buffer" :slight_smile: area polygon, which is of
about *twice* the extent you provide in option "buffer=".

I don't see this.

What I do see is:

points are buffered to the correct distance.

areas (boundary + centroid) are buffered externally to the correct
distance.

boundaries without centroid are not buffered.

lines are buffered either side. If the line forms a closed polygon then
the width of the buffer area is 2x the number given for buffer=, but
this is just the sum of the buffering on both sides of the line. The
area is centered on the line. The internal buffer is not 2x the buffer
distance, just 1x.

tip: use 'd.vect cat=1-99999' to only fill where there is data, ie skip
holes.

I have reported it as a bug
http://intevation.de/rt/webrt?serial_num=3427.

I just tried your "border" vector file. It works as expected for me:
width is 1x internal, 2x internal+external.

?

After rethinking it, I'm not sure what to think. It seems a kind of
bug on one hand, especially that the "internal buffer" size is 2 x
the buffer required, and a cool functionality on the other.

Line is buffered on both sides. How is this new functionality be it 1x
or 2x or 23x buffer width?

The best IMHO would be to extend v.buffer to be able to create such
"internal buffers" in a controlled and documented way. Any chances?
What do others think?

If you want an inverse buffer of an area make a inverse vector with
v.in.region + v.overlay, then v.buffer on that.

Hamish

5

Sorry Guys. All my fault. Stupid me displayed the output over the input, so I actually measured the distance between the interrior and exterior buffers of the output alone. All is fine with v.buffer, sorry for the mess. I wish I hadn't written that.

Dave

v.buffer might be usefull for your purpose, as it creates interior buffers (along with exterior) on line features, which you can obtain from you input rasters using r.to.vect, then v.type ... type=boundary,line.

Maciek

----- Original Message ----- From: "Maciek Sieczka" <werchowyna@epf.pl>
To: "Dave Sampson" <gis@watersheds.ca>; <GRASSLIST@baylor.edu>
Sent: Sunday, July 17, 2005 7:34 PM
Subject: [GRASSLIST:7574] Re: Interior Buffers

David

From: "Dave Sampson" <gis@watersheds.ca>

using r.buffer how might I perform an interior buffer. That is take the outside of a raster clump (from r.clump) and make concentric internal buffers at 100, 200, 300 meters etc?.

Accidently I have found the functionality you are interested in in v.buffer, which seems to be a undocumented feature or a bug.

Anyway: if the input for v.buffer is a *closed* *line* (not the area), then the output is an "internal buffer" :slight_smile: area polygon, which is of about *twice* the extent you provide in option "buffer=".

I have reported it as a bug http://intevation.de/rt/webrt?serial_num=3427.

After rethinking it, I'm not sure what to think. It seems a kind of bug on one hand, especially that the "internal buffer" size is 2 x the buffer required, and a cool functionality on the other.

The best IMHO would be to extend v.buffer to be able to create such "internal buffers" in a controlled and documented way. Any chances? What do others think?

Maciek