[GRASS-dev] Should v.in.ogr clean topology by default ? [was: Fwd: Re: [GRASS-user] overlapping areas seem valid to v.build: why?]

[Benjamin Ducke]

Personally,
I dislike the "non-topological data is also valid data" 
perspective. GIS and spatial analysis are inherently
topological. From my point of view, the only distinction 
that applies is whether that data contains topological 
errors in its structure, or not.

GRASS 6 has been designed as a GIS that honors topological
data structures, and by default enforces topological correctness
on the input data to ensure consistent analysis results.
This, among other design decisions, is one of the reasons why 
GRASS GIS is so wide-spread in the scientific community, 
and has acquired its reputation there.

If all you want is to map and query data, and therefore are OK 
with "garbage in, garbage out": go ahead and use "v.in.ogr -c", 
or maybe even a different GIS, such as QGIS.

But in terms of GRASS as a scientific software: Better improve 
the current topology tools to make them more flexible,
than to drop all topological constraints by default.

Cheers,

Ben

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


On Thursday, December 01, 2011 11:02 AM, "Moritz Lennert"
<mlennert at club.worldonline.be> wrote:
> I think Roger's question below merits reflection, so I forward it to the 
> developer's list.
> 
> Moritz
> 
> -------- 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
>      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 <mailto:grass-user at lists.osgeo.org>
>      http://lists.osgeo.org/mailman/listinfo/grass-user
> 
> 
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>