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

[Roger André]

Hi Markus,

My responses are inline.

>
>
I would prefer to get this fixed instead of not cleaning during
> import. Can you provide sample data for testing?
>
Why spend time *fixing* this, unless you intend to eliminate the "-c" flag
altogether?  It's not broken as far as I'm concerned.  Mentally I view the
current "-c" functionality as the correct default mode of operation for *
v.in.ogr*, with the automated cleaning as the optional feature.  Since it
is an option (as far as I am concerned mentally), the fact that it
sometimes doesn't work is not a problem.  When I come across another data
set that fails on auto-cleaning, but which can be repaired manually, I will
make the data and my workflow available.  I'm processing quite a bit of
data at the moment, and can't remember which set of polygons had this
problem.  There were several and once I came up with a solution that
accomplished what I needed I moved on.


> v.clean can not exactly repeat the cleaning done by v.in.ogr.
>
People keep saying that, but no one ever explains *how* they differ.  Can
someone please do that?  Once that is identified, then my suggestion would
be to spend the development time on making that functionality available in *
v.clean*, rather than making changes to the existing auto-clean logic of *
v.in.ogr.*

>
> That's right, but there is no way to know this a priori. Checking
> would be as costly as actual cleaning.
>
Which is why I skip the automated cleaning.  I don't need a black box to
try to figure out what needs to be done.  I appreciate that the cleaning
option is available and sometimes I use it.  Many times it works well.
 Other times the cost of allowing all of those tools to run (many of which
are unnecessary) is simply unacceptable.

By the way, from some of the comments I've seen on the GRASS Dev list in
response to this, it seems to be a much more contentious issue than it
needs to be.  No one, least of all me, is arguing against the beauty of
GRASS's topological data model.  For me it is the only reason I use GRASS.
 It allows me to clean many of the really, really dirty sets of shapefile
data that I receive from commercial vendors.  However, there also seems to
be a strong expressed bias against other GIS systems which use a simple
geometry model.  Please don't allow discussions on technical functionality
to devolve into this.  GRASS is not the only solution out there and tools
like *v.in.ogr* are a great example of the foresight and thoughtfulness of
the GRASS dev team in accommodating the interaction with these other
systems.  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.

Thanks for all your hard work and commitment to this project,

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