[GRASS5] line types

[rgrmill at rt66.com]

Radim wrote:

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

I haven't tried v.support err=.  Thanks for pointing that out.  The open 
area lines tool in v.digit didn't find any open area lines, nor would it 
label the area.  For now the most recent problem seems to have gone 
away.

> Too complicated. Simple task: label area (which is unclosed = with 
error).

I've recently done this; it wasn't complicated and it worked very well.  
You do have to make sure that areas are closed, but that is true and 
will always be true if you want to use a polygon to define an area, 
regardless of whether GRASS uses one line type, or two line types.


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

I think that every time I've edited a vector file that was already built 
subsequent rebuilds reported errors.  The errors aren't fatal 
(pnt_to_area_failed, etc), but the only way I've found to avoid them is 
to manually delete old attributes before I rebuild.


> > 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.

That recommendation is built into the vector standard in the 
programmer's manual that you pointed me to yesterday.

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)

The obvious and simple alternative is to leave them all together as a 
single line type and just accept the fact that you might define more 
areas then you need.


Before we get too far afield I'd like to restate the original problem.

GRASS defines two arc types.  These are for area edges and linear 
objects.  Some GRASS modules handle both arc types identically (ps.map 
and the traditional d.vect, for instance) and some modules handle them 
differently.

In practice GRASS actually has four arc types:

arcs that define linear objects, 

arcs that are typed as forming linear objects but actually form closed 
polygons, 

arcs that are typed to form closed polygons, and 

arcs that are typed as forming closed polygons, but which actually form 
linear objects (unclosed polygons).

Actually, DOTs are another arc type.  Their existence complicates the 
coding but otherwise they don't enter into this problem.

Many (most?) of the GRASS modules that do handle the arc types 
differently can discard sometimes large parts of the vector data.  Other 
modules behave in ways that are not consistent with their documentation, 
because the documentation isn't clear on the distinctions between 
different arc types.

Discarded data is a big problem.  It happens because modules (v.extract 
and v.out.shape, for instance) when told to export areas export only 
"topologically correct" area arcs.  When told to export lines they 
export only line-type arcs.  These modules never export "topologically 
incorrect" area arcs and those data can never appear in the output.

The problem is aggravated because of a limitation in GRASS' topology 
calculations.  The ascii map below shows a city block, with a dead-end 
street ending in the middle of the block.  All lines are area arcs.  
This could be a part of any road pattern, but a city street pattern is a 
simple example.

*--*--*
|  |  |
|  *  |
*-----*

The surrounding square is an obvious closed area, but the algorithm used 
by GRASS sees the dead-end line in the middle of the block and will not 
identify the surrounding square as an area.  In the case that brought 
all of this to my attention this problem caused v.out.shape to discard 
more than half of the arc data in a simple vector map.

Returning to the original problem, there seem to be two possible 
solutions.  We can either 1) modify GRASS modules to treat the arc types 
so that data are not discarded, or we can 2) remove the arc-type 
distinction so that all arcs are treated the same.

Both solutions have advantages and disadvantages and both require fairly 
extensive changes in the code.  By and large, the first change 
complicates the code base, while the second change simplifies it.

I am in the process of adding code to some modules -- hacking around the 
problems by adding an option to effectively treat area arcs as if they 
were line arcs.  This is a quick fix because I need to get around major 
problems in the short term.  In the long term I think it is far better 
to discard the arc type distinction and use a simpler vector model.

My reasoning is that

1) the function of the arc type is largely duplicated by the function of 
the category number.  The category number provides a more flexible and 
more widely used mechanism.

2) large public data sets don't strictly conform to the two arc-type 
vector model; editing those data sets into conformity is at best 
difficult, tedious and time-consuming.

3) GRASS modules' current handling and documentation of arc type is very 
inconsistent.  The best way to get consistency is to simplify.

The evident downside is that without the two arc-type distinction the 
topology calculations will take longer and may define areas that the 
user doesn't need.  GRASS already offers the tools necessary to get 
avoid the problems.

All in all, simpler is better.


Roger Miller