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

GRASS GIS GRASS GIS developer
1

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@gmail.com>
To: Markus Metz <markus.metz.giswork@googlemail.com>
CC: Moritz Lennert <mlennert@club.worldonline.be>,
grass-user@lists.osgeo.org, "G. Allegri" <giohappy@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@googlemail.com
<mailto:markus.metz.giswork@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@lists.osgeo.org <mailto:grass-user@lists.osgeo.org>
     http://lists.osgeo.org/mailman/listinfo/grass-user

2

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@fastmail.fm

On Thursday, December 01, 2011 11:02 AM, "Moritz Lennert"
<mlennert@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@gmail.com>
To: Markus Metz <markus.metz.giswork@googlemail.com>
CC: Moritz Lennert <mlennert@club.worldonline.be>,
grass-user@lists.osgeo.org, "G. Allegri" <giohappy@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@googlemail.com
<mailto:markus.metz.giswork@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@lists.osgeo.org <mailto:grass-user@lists.osgeo.org>
     http://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

3

Hi,

a couple of points--

* Radim said many times: v.in.ogr's cleaning and v.clean are not
the same thing. (with a number of !! added) He explained it and
understood it always better than I ever could, so check in the
mailing list archives for details.

* GRASS is a topological GIS. so when data is imported into GRASS
it is natural and desirable that it gets converted into the
family way at that time.

* In defense of the option to allow non topological imports:
in the past I have imported a shapefile created by leading
proprietary non-topological GIS. this file was a string of
buffers around points with unique ID numbers. the idea was to
run (the predecessor to) v.rast.stats on each buffer to collect
some neighborhood context stats for each ID point, which could
be loaded into a table. wherever the line of points was not
exactly straight the buffers overlapped a little and grass's
cleaning would treat it as a ven diagram and create a new
centroid in the overlapping sliver. no good for extracting the
buffer area where='NODE_ID = 1234'.
also you might consider a vector area map with multiple over-
lapping home ranges for different territorial animals. not 3d,
but still merging/flattening overlapping areas is not appropriate.

for things like neighboring land parcels, political lines, or
land/sea boundaries non-topological is a nightmare, but for
other tasks it can occasionally be very useful.

Hamish