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