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

[Benjamin Ducke]

> be a strong expressed bias against other GIS systems which use a simple
> geometry model.  

It was certainly not my intention to suggest that GRASS
is the only "proper" GIS.

Different GIS have different design philosophies. 
Thus, they fit different use cases. I myself use
more than one.

> Please don't allow discussions on technical
> functionality to devolve into this.  

You asked for opinions on a topic that goes well
beyond the technicalities of "v.in.ogr".
Please see my notes further down.

> When I read something like, "Well if you don't care about the
> quality of your data, go use another GIS system." I then seriously
> consider looking at the new PostGIS topological model, for example, for reasons
> that have NOTHING to do with the technical capability of either system.

Having been part of the GRASS development team for a long time
now, and having spent some time on improving v.in.ogr/v.out.ogr 
myself in the past, allow me to sum up:

Without topological correctness (according to the GRASS
data model, not PostGIS' or anybody else's), options for processing
polygonal data in GRASS are severely limited. And it will 
not be possible to correctly manage complex polygons with
islands/holes in them. Thus the man page for "v.in.ogr" states:

-c
    Do not clean polygons (not recommended)

So in fact you are asking for a modification to one of the most 
frequently used modules in GRASS that will *revert* the 
default behavior on which a lot of users (including myself) and 
shell scripts written by users to automate data analysis have 
come to rely.

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.

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