[GRASS5] line types

[Radim Blazek]

On Thursday 11 April 2002 06:34 pm, rgrmill at rt66.com wrote:
> I on occasion have apparently closed polygons that aren't identified by
> v.transform and which I can't label as an area in v.digit.  Sometimes I
> eventually figure out why, sometimes I don't have time.  In most of
> those cases v.support does report errors of some type but I don't have
> any evident way of associating the reported error with a specific
> polygon or with a specific cause.

To find the lines with error easier, you can use either v.support err=
or v.digit -> Toolbox -> o - Display Open area lines.

> In this case you would just use v.extract to move the roads into a
> different layer based on their category number.  Most of GRASS' modules
> seem to manipulate vectors on the basis of their category numbers, so
> there are several reasons why the roads should already be categorized.

Too complicated. Simple task: label area (which is unclosed = with error).
1. v.digit: somehow place the centroid in area - not supported now in
   v.digit, because you can only label closed area. You cannot see which
   lines will be extracted as lines and which ketp as boundaries, because
   symbology based on attributes is not available in v.digit = you cannot 
   see the area boundary and you have to label it.
2. v.extract -> edges + centroids  
3. v.support -> error reported because area is not closed
4. v.digit: correct the error (close area)
5. v.extract
6. v.support -> labeled area

Here is lost the main advantage of v.digit, which is that you can edit data
on level 2, i.e. with built topology. 

If you have support for line/edge types, you can do all at once, in one 
v.digit session.
   
> In fact, most data sets should separate land use and transportation data
> into separate layers to start with.

Not effective, if roads are often (not always) boundaries. If you separate 
roads to other vector (i expect that you mean other vector by other layer), 
you have to digitize many lines twice =>
- extra work
- (extra space used for data - not too important nowadays)
- maintenance problems - impossible to keep both layers consistent
- (it is not according to rules for good IS model, because it contains
    duplicities maintained manualy)

Radim