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

Roger André randre at gmail.com
Wed Nov 30 13:09:15 EST 2011


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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20111130/a3d73591/attachment.html


More information about the grass-user mailing list