[GRASS5] Grass 6 capabilities

tlaronde at polynum.com tlaronde at polynum.com
Wed Nov 2 17:11:20 EST 2005


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




More information about the grass-dev mailing list