[GRASS5] line types

[rgrmill at rt66.com]

Radim wrote:

> On Wednesday 10 April 2002 07:08 pm, rgrmill at 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