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

[Markus Metz]

Hi Roger,

I know you want to stop the discussion, just some last remarks,
including some for my motivation why I think topological cleaning
during import is absolutely necessary.

Roger André wrote:
> 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?

Because 1) import modules *must* work and produce healthy output which
for v.in.ogr means converting polygons to topological areas, 2) users
must be able to rely on the proper functioning of the default
behaviour (which includes topological cleaning for v.in.ogr) 1) I do
intend to eliminate the -c flag altogether (no topology-related bugs
reported in the bug tracker).

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

That would be great! I sort of collect difficult datasets, but do not
have one that makes v.in.ogr in GRASS 7 fail. An exception is the
import of several large layers at once and storing them in one single
GRASS vector, that may exceed hardware resources (although GRASS 7
performs magnitudes better in this regard than GRASS 6).

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