[GRASS5] line types
rgrmill at rt66.com
rgrmill at rt66.com
Fri Apr 12 13:32:42 EDT 2002
Radim wrote:
> To find the lines with error easier, you can use either v.support
err=
> or v.digit -> Toolbox -> o - Display Open area lines.
I haven't tried v.support err=. Thanks for pointing that out. The open
area lines tool in v.digit didn't find any open area lines, nor would it
label the area. For now the most recent problem seems to have gone
away.
> Too complicated. Simple task: label area (which is unclosed = with
error).
I've recently done this; it wasn't complicated and it worked very well.
You do have to make sure that areas are closed, but that is true and
will always be true if you want to use a polygon to define an area,
regardless of whether GRASS uses one line type, or two line types.
> Here is lost the main advantage of v.digit, which is that you can edit
data
> on level 2, i.e. with built topology.
I think that every time I've edited a vector file that was already built
subsequent rebuilds reported errors. The errors aren't fatal
(pnt_to_area_failed, etc), but the only way I've found to avoid them is
to manually delete old attributes before I rebuild.
> > In fact, most data sets should separate land use and transportation
data
> > into separate layers to start with.
>
> Not effective, if roads are often (not always) boundaries.
That recommendation is built into the vector standard in the
programmer's manual that you pointed me to yesterday.
If you separate
> roads to other vector (i expect that you mean other vector by other
layer),
> you have to digitize many lines twice =>
> - extra work
> - (extra space used for data - not too important nowadays)
> - maintenance problems - impossible to keep both layers consistent
> - (it is not according to rules for good IS model, because it
contains
> duplicities maintained manualy)
The obvious and simple alternative is to leave them all together as a
single line type and just accept the fact that you might define more
areas then you need.
Before we get too far afield I'd like to restate the original problem.
GRASS defines two arc types. These are for area edges and linear
objects. Some GRASS modules handle both arc types identically (ps.map
and the traditional d.vect, for instance) and some modules handle them
differently.
In practice GRASS actually has four arc types:
arcs that define linear objects,
arcs that are typed as forming linear objects but actually form closed
polygons,
arcs that are typed to form closed polygons, and
arcs that are typed as forming closed polygons, but which actually form
linear objects (unclosed polygons).
Actually, DOTs are another arc type. Their existence complicates the
coding but otherwise they don't enter into this problem.
Many (most?) of the GRASS modules that do handle the arc types
differently can discard sometimes large parts of the vector data. Other
modules behave in ways that are not consistent with their documentation,
because the documentation isn't clear on the distinctions between
different arc types.
Discarded data is a big problem. It happens because modules (v.extract
and v.out.shape, for instance) when told to export areas export only
"topologically correct" area arcs. When told to export lines they
export only line-type arcs. These modules never export "topologically
incorrect" area arcs and those data can never appear in the output.
The problem is aggravated because of a limitation in GRASS' topology
calculations. The ascii map below shows a city block, with a dead-end
street ending in the middle of the block. All lines are area arcs.
This could be a part of any road pattern, but a city street pattern is a
simple example.
*--*--*
| | |
| * |
*-----*
The surrounding square is an obvious closed area, but the algorithm used
by GRASS sees the dead-end line in the middle of the block and will not
identify the surrounding square as an area. In the case that brought
all of this to my attention this problem caused v.out.shape to discard
more than half of the arc data in a simple vector map.
Returning to the original problem, there seem to be two possible
solutions. We can either 1) modify GRASS modules to treat the arc types
so that data are not discarded, or we can 2) remove the arc-type
distinction so that all arcs are treated the same.
Both solutions have advantages and disadvantages and both require fairly
extensive changes in the code. By and large, the first change
complicates the code base, while the second change simplifies it.
I am in the process of adding code to some modules -- hacking around the
problems by adding an option to effectively treat area arcs as if they
were line arcs. This is a quick fix because I need to get around major
problems in the short term. In the long term I think it is far better
to discard the arc type distinction and use a simpler vector model.
My reasoning is that
1) the function of the arc type is largely duplicated by the function of
the category number. The category number provides a more flexible and
more widely used mechanism.
2) large public data sets don't strictly conform to the two arc-type
vector model; editing those data sets into conformity is at best
difficult, tedious and time-consuming.
3) GRASS modules' current handling and documentation of arc type is very
inconsistent. The best way to get consistency is to simplify.
The evident downside is that without the two arc-type distinction the
topology calculations will take longer and may define areas that the
user doesn't need. GRASS already offers the tools necessary to get
avoid the problems.
All in all, simpler is better.
Roger Miller
More information about the grass-dev
mailing list