Skip to content
Prev 615 / 29559 Next

The length of common boundaries

(cc grass user list)
On Wed, Oct 12, 2005 at 05:43:35PM +0200, Markus Neteler wrote:
With the help of Radim I managed to find out how to do it.
It's pretty easy (but you need the today's version of GRASS 6.1-CVS
due to a related bugfix in v.db.addtable).


EXERCISE: HOW LONG ARE COMMON BOUNDARIES OF POLYGONS?


# Requires: GRASS 6.1-CVS from 13 Oct 2005 or later
#
# data: sudden infant deaths data from North Carolina
# data imported from SHAPE file with v.in.ogr

#let's have a look
 d.mon x0
 d.vect sids

#we work on a copy:
 g.copy vect=sids,sids_nc

#we add a second layer to the map which references the boundaries of
#polygons. In the vector geometry we generate an ID (category) for each
#boundary:
 v.category sids_nc out=sids_nc2 layer=2 type=boundary option=add

#Underlying idea:
#we'll fetch the IDs (categories) of the polygons left and right from
#each boundary and store it into the attribute table linked to layer 2.
#In general:
# cat_of_boundary | cat_of_left_polygon | cat_of_right_polygon | length_of_boundary
#
#We want only one category per boundary, that's why the sides check is
#needed (a boundary may consist of several pieces)
#
#So we create a new attribute table and link it to the new layer 2
#of the vector map:
 v.db.addtable sids_nc2 layer=2 col="left integer,right integer,length integer"

#Now we query the polygon/boundary relationsships and store it into
#the attribute table linked to layer 2:
 v.to.db map=sids_nc2 option=sides col=left,right layer=2 

#Now we have unique categories for the boundaries and can calculate the
#lengths:
 v.to.db map=sids_nc2 option=length col=length layer=2 

#Done.

#See the new attribute table containing the boundary lengths:
 v.db.select sids_nc2 layer=2

# verification (let's check boundary #193):
 d.vect sids_nc2 cat=193 layer=2 col=red type=boundary
 d.zoom
 d.measure
# LEN:     12756.00 meters

#what does the attribute table say:
 v.db.select sids_nc2 layer=2 | grep '^193'
#190|65|68|12814

#This is reasonably close since on screen digitization in d.measure
#isn't always that precise ...


Best

 Markus