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

Benjamin Ducke benducke at fastmail.fm
Sat Dec 3 14:50:04 EST 2011


+1

If we remove -c, we can also get rid of the confusing
separate topology build paths (one default and one
for "-c") in the v.in.ogr source code.

In addition, polygon cleaning in v.in.ogr is based on
the original information in the unmodified OGR data 
source. It seems to me that this is the one point in
the processing chain at which topologically correct 
areas can be produced with maximum accuracy. A later
run of v.clean will not have access to the original
data structures in the OGR data source and might thus
produce less good results (I think this point has been
raised before).

So from a user point of view, getting rid of "-c" in
GRASS 7 would remove another source of uncertainty.

Ben

-- 
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
  
  benducke AT fastmail.fm


On Saturday, December 03, 2011 4:03 PM, "Markus Metz"
<markus.metz.giswork at googlemail.com> wrote:
> Benjamin Ducke wrote:
> >
> > Using data with unchecked topology is possible via "v.external".
> > This module builds a pseudo topology that may be good enough in
> > many cases. It works particularly well in GRASS 7.
> 
> Good point. In this case we could remove the -c flag for v.in.ogr in
> trunk and always convert simple feature polygons to topological areas.
> Supporting arguments would be that compared to GRASS 6, topology in
> GRASS 7 is more robust, uses less resources, cleaning functions are
> often faster, also use less resources, and vector topology including
> cleaning functions is according to the bug tracker bug-free, AFAICT.
> 
> Markus M
> >
> >>
> >> Thanks for all your hard work and commitment to this project,
> >
> > You are welcome. Thanks for your input.
> >
> > Best,
> >
> > Ben
> >
> >>
> >> Roger
> >> --
> >>
> >>
> >>
> >> > 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
> >> > >
> >> > >
> >> >
> >>
> >> _______________________________________________
> >> grass-user mailing list
> >> grass-user at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/grass-user
> >>
> > _______________________________________________
> > grass-user mailing list
> > grass-user at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-user
> 



More information about the grass-user mailing list