Radim wrote:
Of course, all modules missing boundary type needs that option.
If you add that option, please commit also to cvs for other users.
Done. The necessary changes are nearly trivial. I'm new with CVS so it
will take more time to figure out how to commit the changes then it took
to make the changes.
I suspect that there are a couple reported bugs that may be caused by
the line/area edge distinction.
I don't understand why you cannot not do the task with type=edge,
why you must remove 'line' type.
I can and did. But I regard that as a hack -- adding an unnecessary
complication to support a model that I disagree with.
Yes, but we are talking about the cases, where separation is not
effective.
The reason for fixing v.llabel and v.extract was to make separation more
effective. Fixes to a few other modules would help in the same regard.
I think that build process works without errors, i am interested in
clean
data sets, for which build process fails - please send to me if
possible.
I care about error messages, and i need to know if error is realy
error
in area topology and not correct free end of line.
What do you regard as a clean data set? If you mean one for which the
build reports no errors then we have a logical problem. v.transform has
always reported errors doing builds. Some errors may not even be
reported. It is more of a problem to me that GRASS offers no good tool
for finding and fixing the problems.
I don't understend why you must do that. If you like, you can use edge
type
for all arcs. We must keep possibility to do that, for those who
want.
In general, you can use edge type only, if you want, in system with
both
edge/line type, but others who need the distinction, cannot use the
system
where line type is not present.
I use the edge type when I can, but it isn't always possible. For
instance, US Census Bureau Tiger County Line data are broken down into
line objects and area object. I don't believe I have an option of
importing roads (typed as line objects) as area edges. In fact, most of
the GRASS import packages do not give one the choice of line type. That
means that for dxf data and for many important public data sources
(USGS, NRCS and US Census, for instance) I have to accept whatever line
type the import package decides to set.
The the only way you can get data that is consistent with the GRASS
line/area edge distinction is to digitize it in GRASS. And you can only
reasonably manipulate that distinction if you're working with small data
sets. That is very limiting. It isn't even very well supported in
GRASS.
The line/area edge distinctions causes a lot more problems then it has
has advantages, and in every case where there appears to be a use for
the difference there also appears to be a workable alternative. All
things considered I think we need to get rid of the distinction.
Roger Miller