[GRASS5] Grass 6 capabilities

It appears to me that the difficulties I originally described with importing
shape files to GRASS 5.3 are actually two or more different problems. I
compiled two examples from a single imported shape file.

The first example below contains 4 complete polygons -- none of which share a
common node -- along with the necessary att and cats files. The polygons
should be correctly supported by GRASS 5. If, after the file is set up as a
valid GRASS vector file, you use d.what.vect to query the left-most polygon the
program will highlight all 4 polygons and produce bad information about the
polygon area. Similar problems occur with other modules that need to identify
the polygons.

I don't have a clue what might cause the problem in GRASS 5. My main concern is
whether GRASS 6 suffers the same result.

The second example contains 3 complete polygons composed of 7 lines. The
polygons all share a single node. v.support reports several "Unclosed area..."
errors. In this case, I can resolve most of the errors by patching the lines
together so there is one line and one node for each polygon. If the polygons
still share a node then v.support will still report errors and fail to support
the polygons. If the sequence of points in the lines are rotated so that the
polygons do not share a node then polygons can be supported.

The question with this is whether GRASS 6.X can import and support these
polygons without errors.

Thank you for your attention.

Roger Miller

(attachments)

example1 (2.1 KB)
example2 (2.6 KB)

Hello,

I've read your message on the grass5 list and since KerGIS is based
on CERL GRASS 4.1 for vector (same as GPL GRASS 5.x serie) I was
interested in your examples.

Explanations hold for GPL GRASS 5.x too. For GPL GRASS 6.x, which has
a new vector engine, Radim has answered and I do know nothing about it.

In brief, there are not several distinct "bugs"---there are indeed no
bug at all in GRASS derivatives---but your data is simply topologically
incorrect/dirty.

First example: GRASS assumes that the data is topologically correct (if
would a waste of time to build in features to verify correctness: the
data shall be correct, and if not user shall use the program provided to
correct it first).
If it is not correct, you must run v.spag(1) on it.
This is typically the case for
your first example. GRASS has no problem closing the "areas" since the
areas are described by a single closed arc. Since they do share no node,
it can not detect intersecting arcs. But your areas ("polygons") do
intersect/overlap and if you zoom enough you will see that indeed in the
left most area, the other nodes of the other areas are _inside_ the
area: GRASS compute the surface with the positive inside and substract
the isles detected (by the presence of a node inside the area) leading
to a negative total.

Using v.spag(1) you will see that several sliver areas are created
simply because the boundaries of your areas do not match.

Second example: since they share a node, GRASS tries to find a closing
path. But segments are duplicated leading to a go/return and the
impossibility to close the path -> areas not created.

Reason: your data is "dirty".
If you have at least correct topological shape files, importing shape
polygons splitting contours by segments (since I have redevelopped for
KerGIS a shape library, there is in KerGIS v.in.shape(1) an option to do so),
running v.spag -i for removing duplicate segments corrects the thing (there
is probably an equivalent option in GPL GRASS associated programs).

If the data is topologically incorrect, running v.spag(1) the hard way
will cut the arcs at the intersections, creating areas and probably
slivers that will show the problems. The areas labelled will have a
surface < to the surface computed using the original shape polygons,
since the overlapping zones will be substracted (i.e. new small areas
will be created at the instersection).

Shape is probably good---i.e. simple---for displaying features but as a
format for building a GIS, data provided shows that this simply allows
people to create mess---that's why more advanced software, after arguing
that topology is useless, recreate it using coverage and so on...

Cheers,
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.org/ | http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C