I'm trying to simplify a vector map of areas describing countries.
I tried to use v.generalize with the various proposed simplification method but the result is completely wrong as soon as I set a high threshold value(actually, it works only with very low values) The resulting map is always completely broken with most of the areas having disappeared.
I have attached a sample file(in grass standard ascii format). If you run v.generalize with a threshold of 100, the map will be broken but with a value of 10, it works. Note that a threshold of 100 is still very low considering the resolution of the map...
I know that there has been a few posts on this topic but I could not find a answer which corrects the problem.
Interestingly, I tried instead to use v.clean with the "prune" tool and the result is very good. It works with very high threshold (at least up to 10000) but I don't know if I can trust it as it is written in the documentation that "The /prune/ tool is currently broken, please use /v.generalize <http://grass.osgeo.org/grass64/manuals/html64_user/v.generalize.html>/ instead." So, it is a bit contradictory with the results I got?
Do you know why v.generalize doesn't work with high threshold?
And do you know what is the actual status of the "prune" tool of v.clean?
v.generalize does a great job with simplifying or smoothing lines, but areas either disappear or attribute attachment changes. That's why I would recommend not to use v.generalize for areas. v.clean tool=prune behaves the other way around, areas are always preserved, with attribute attachment, as they are, but line simplification does not always work, i.e. produces strange results or does not simplify at all. Should we swap the warnings, e.g. say for v.generalize that there are problems with processing areas and for areas use v.clean tool=prune instead?
Markus M
Marc-Antoine Nussli wrote:
Hi,
I'm trying to simplify a vector map of areas describing countries.
I tried to use v.generalize with the various proposed simplification method but the result is completely wrong as soon as I set a high threshold value(actually, it works only with very low values) The resulting map is always completely broken with most of the areas having disappeared.
I have attached a sample file(in grass standard ascii format). If you run v.generalize with a threshold of 100, the map will be broken but with a value of 10, it works. Note that a threshold of 100 is still very low considering the resolution of the map...
I know that there has been a few posts on this topic but I could not find a answer which corrects the problem.
Interestingly, I tried instead to use v.clean with the "prune" tool and the result is very good. It works with very high threshold (at least up to 10000) but I don't know if I can trust it as it is written in the documentation that "The /prune/ tool is currently broken, please use /v.generalize <http://grass.osgeo.org/grass64/manuals/html64_user/v.generalize.html>/ instead." So, it is a bit contradictory with the results I got?
Do you know why v.generalize doesn't work with high threshold?
And do you know what is the actual status of the "prune" tool of v.clean?
I'm using grass 6.4RC5 on linux.
Thanks!
ma
------------------------------------------------------------------------
On Wed, Sep 16, 2009 at 9:40 PM, Markus Metz
<markus.metz.giswork@googlemail.com> wrote:
v.generalize does a great job with simplifying or smoothing lines, but areas
either disappear or attribute attachment changes. That's why I would
recommend not to use v.generalize for areas. v.clean tool=prune behaves the
other way around, areas are always preserved, with attribute attachment, as
they are, but line simplification does not always work, i.e. produces
strange results or does not simplify at all. Should we swap the warnings,
e.g. say for v.generalize that there are problems with processing areas and
for areas use v.clean tool=prune instead?
Yes, and also perhaps add a type test? Like v.select and v.overlay which
do not work yet with all types (although desired ).
On Wed, Sep 16, 2009 at 9:40 PM, Markus Metz
<markus.metz.giswork@googlemail.com> wrote:
v.generalize does a great job with simplifying or smoothing lines, but areas
either disappear or attribute attachment changes. That's why I would
recommend not to use v.generalize for areas. v.clean tool=prune behaves the
other way around, areas are always preserved, with attribute attachment, as
they are, but line simplification does not always work, i.e. produces
strange results or does not simplify at all. Should we swap the warnings,
e.g. say for v.generalize that there are problems with processing areas and
for areas use v.clean tool=prune instead?
Yes, and also perhaps add a type test? Like v.select and v.overlay which
do not work yet with all types (although desired ).
I have changed the manual of v.clean and added warnings to v.generalize in all branches (r39229/31 for 6.4, 6.5, 7.0 respectively) when boundaries are modified.
).