[GRASS-dev] Should v.in.ogr clean topology by default ? [was: Fwd:
Re: [GRASS-user] overlapping areas seem valid to v.build: why?]
mlennert at club.worldonline.be
Thu Dec 1 05:02:28 EST 2011
I think Roger's question below merits reflection, so I forward it to the
-------- Original Message --------
Subject: Re: [GRASS-user] overlapping areas seem valid to v.build: why?
Date: Wed, 30 Nov 2011 10:09:15 -0800
From: Roger André <randre at gmail.com>
To: Markus Metz <markus.metz.giswork at googlemail.com>
CC: Moritz Lennert <mlennert at club.worldonline.be>,
grass-user at lists.osgeo.org, "G. Allegri" <giohappy at gmail.com>
By the way, it seems that the official stance is that it is preferred to
allow the automatic cleaning of non-topological data sets when they are
imported. However, I do want to point out that I have seen many, many
instances where this auto-cleaning actually causes problems, rather than
fixes them. As a result, I explicitly exclude cleaning on every import
I do. If cleaning is required, I manually clean the data with v.clean.
In many cases only a subset of the full set of cleaning operations
performed automatically by v.in.ogr are needed to fix the data.
Personally, I do not think this "auto cleaning" should ever have been
made the default operation of the import tool.
On Wed, Nov 30, 2011 at 9:37 AM, Markus Metz
<markus.metz.giswork at googlemail.com
<mailto:markus.metz.giswork at googlemail.com>> wrote:
Moritz Lennert wrote:
> On 30/11/11 14:38, Markus Metz wrote:
>> It seems to me that the confusion arises because you made use of
>> features that allow you to skip topological cleaning which is
>> default and not recommended.
> Maybe this calls for a v.check.topology module ? Or an option in
> v.clean which does that (i.e. just check, not clean) ?
Good idea. I would opt for a new option/flag for v.build, which can
already provide rather detailed diagnostics, e.g. dumping topology.
Something like v.build -e for extended topology checks?
grass-user mailing list
grass-user at lists.osgeo.org <mailto:grass-user at lists.osgeo.org>
More information about the grass-dev