[GRASS5] line types

[rgrmill at rt66.com]

Radim wrote:

> I cannot agree. You are still talking about your one special case.

No, it isn't one special case.  It is a fairly general case.  Many of us 
have to deal with public data sets.  The data sets tend to be large, 
they tend to be imperfect and they often don't fit the GRASS vector 
model.

> You are missing some functionality for some modules. I think that what 
you 
> need is 'type=edge,line' instead of only 'type=line', you can add 
'edge'
> type to that modules. 

This is a change that I can make myself.  It's a simple work around for 
these two modules.  There are certainly other modules that share the 
problem.

> Instead, you propose as a solution, to limit grass funcionality to 
only area 
> edges. I don't think that it is good idea, to resolve problems of 
missing 
> funcionality by another reduction of existing functionality. Better is 
to 
> extend existing options.

This isn't a matter of limiting functionality.  If a user needs to 
distinguish between lines and area edges then the functionality is 
already there in the category values and in layer separation.  Removing 
the distinction between area edges and lines can actually increase the 
functionality.  I already demonstrated that by removing the distinction 
from two modules and getting behavior out of those modules that I could 
not get otherwise.

As a practical matter I think it's always best to start with simple 
concepts and make them work perfectly before complicating things.

The division between lines of type "line" and lines of type "area edge" 
is wrong; it's a bad model.  There is no actual distinction between the 
edge of an area and a line.  A fence is also an edge of a field.  A user 
could very reasonably want to know both the length of the fence line and 
the area of the field. A single object should be able to serve both 
functions. Trying to draw and maintain a synthetic distinction may work 
for some things but in the long run I don't think that it is a good 
idea.

> I can give you some examples where to distinguish edges and lines is 
usefull:
> 
> 1) map with mixed area and line features:
> - line feature in area, obviously it may not be area edge, otherwise 
build
>    fails
> - report size for lines (length) and areas (area), of course here we 
don't
>    want lengt of areas' perimeters (BTW, I used this many times)
> 
> 2) map with one feature type
> - imagine road network, if you use only area edges, build process 
will
>    try to build ares (lost time), it will report problems with 
topology
>    because some areas are not closed (free ends of roads), and if user 
query
>    the map with d.what.vect, he will get report on area sizes - is not 
that
>    confusing for road network?

A lot of problems can be avoided by separating line features and areas 
into different data sets.  Once they're separated the distinction should 
be insignificant.  What difference should the line type make if the data 
set contains only one type of data?  Category values can also be used to 
draw the distinction.

The behavior of queries is certainly something we can adjust, so I don't 
find that to be a strong argument against simplifying the system.  

Errors in building the topology are nothing new.  I guess I would worry 
more about reported errors in the build if the system worked now without 
errors.  It doesn't.

Finally, I far prefer spending a few extra minutes waiting for v.support 
to build extra areas to spending days manually assigning the correct 
line types.  Imagine digging through 45,000 lines of type "line" to 
manually toggle 10,000 lines to "area edge" so that they can be used to 
define areas.


Roger Miller