Radim wrote:
On Wednesday 10 April 2002 07:08 pm, rgrmill@rt66.com wrote:
> 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.
Clean data fulfil "6.7 Vector Topology Rules" in Programmer's Manual.
I'll check into it.
> v.transform has always reported errors doing builds.
Vector without errors had errors after v.transform?
Sorry, my error. I meant to say that v.support has always reported
errors doing builds.
> Some errors may not even be reported.
Which errors are not reported.
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.
The first time that happened to me I actually dumped everything to ascii
and went through it manually to figure out the problem.
> It is more of a problem to me that GRASS offers no good tool
> for finding and fixing the problems.That is also problem for me, and that is challenge for future. It is
not
simple task, David can talk about that.
> 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.
So they use a model with edge/line distinction?
No. They have line objects, area objects and points. Area objects are
defined by a line, but the line itself is not of any special type.
The polygons that define areas may also be imported when you import
lines. When I import areas I get the line around the area, which I can
type as an area edge. In Tiger files a closed polygon is necessary to
define an area object, but a closed polygon by itself is not sufficient
to define an area object. Areas have to be designated. The Tiger files
I've looked at in the past don't designate very many area objects. They
reserve that object type for areas they regard as particularly
significant.
You can get consitent data to GRASS, what you only need, is to sort
lines and edges during the import. Is it problem to run?:
v.in.dxf lines=rivers type=line
v.in.dxf lines=lakes type=edge
(Of course if type= was available, now with v.line2area following the
later)
This would not be the simplest of the possible solutions, but if the
'type=' option actually existed then it might work. Whether or not it
actually works depends on whether the dxf file is layered the way you
want it. They often are not.
> 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.
What is an alternative for example with forests, fields and roads in
my last
mail?
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.
In fact, most data sets should separate land use and transportation data
into separate layers to start with. In my work I would more commonly
want to merge the roads and land use data so that I can break the land
use areas down into blocks based on access. This would be used for
wilderness definition and management, wildfire control, timber harvest
and a number of other applications. In that case the line/area edge
distinction is an annoyance.
I looked into v.out.shape and found that the problem I had with it not
exporting line layers was caused by the line type distinction. I can
add a type option. I also looked into v.cutter and found that some of
my problems there are also related to the line type distinction. I can
fix that part of v.cutter's problems, but probably not all of them.
In all cases the simpler (=better) alternative would be to remove the
line type distinction entirely.
Roger Miller