[GRASS-user] overlapping areas seem valid to v.build: why?

[Markus Metz]

Roger André wrote:
> 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.

I would prefer to get this fixed instead of not cleaning during
import. Can you provide sample data for testing?

> If cleaning is required, I manually clean the data with v.clean.

v.clean can not exactly repeat the cleaning done by v.in.ogr.

> 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.

That's right, but there is no way to know this a priori. Checking
would be as costly as actual cleaning.

Markus M

> 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> 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 not the
>> >> default and not recommended.
>> >
>> >
>> > Maybe this calls for a v.check.topology module ? Or an option in v.build
>> > or
>> > 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?
>>
>> Markus M
>> _______________________________________________
>> grass-user mailing list
>> grass-user at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>