<div class="gmail_quote"><div><font class="Apple-style-span" color="#3366ff">Hi Markus,</font></div><div><font class="Apple-style-span" color="#3366ff"><br></font></div><div><font class="Apple-style-span" color="#3366ff">My responses are inline. </font></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div> </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
</div>I would prefer to get this fixed instead of not cleaning during<br>
import. Can you provide sample data for testing?<br></blockquote><div><font color="#3366ff">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 <i>v.in.ogr</i>, 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. </font><font class="Apple-style-span" color="#3366ff">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.</font></div>
<div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
</div>v.clean can not exactly repeat the cleaning done by v.in.ogr.<br></blockquote><div><font color="#3366ff">People keep saying that, but no one ever explains <i><b>how</b></i> 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 <i>v.clean</i>, rather than making changes to the existing auto-clean logic of <i>v.in.ogr.</i></font></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
</div>That's right, but there is no way to know this a priori. Checking<br>
would be as costly as actual cleaning.<br></blockquote><div><font color="#3366ff">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.</font></div>
<div><font class="Apple-style-span" color="#3366ff"><br></font></div><div><font class="Apple-style-span" color="#3366ff">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 <i>v.in.ogr</i> 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.</font></div>
<div><font class="Apple-style-span" color="#3366ff"><br></font></div><div><font class="Apple-style-span" color="#3366ff">Thanks for all your hard work and commitment to this project,</font></div><div><font class="Apple-style-span" color="#3366ff"><br>
</font></div><div><font class="Apple-style-span" color="#3366ff">Roger</font></div><div><font class="Apple-style-span" color="#3366ff">--</font></div><div><br></div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Markus M<br>
<div><div><br>
> Personally, I do not<br>
> think this "auto cleaning" should ever have been made the default operation<br>
> of the import tool.<br>
> --<br>
><br>
><br>
> On Wed, Nov 30, 2011 at 9:37 AM, Markus Metz<br>
> <<a href="mailto:markus.metz.giswork@googlemail.com" target="_blank">markus.metz.giswork@googlemail.com</a>> wrote:<br>
>><br>
>> Moritz Lennert wrote:<br>
>> > On 30/11/11 14:38, Markus Metz wrote:<br>
>> >><br>
>> >> It seems to me that the confusion arises because you made use of<br>
>> >> features that allow you to skip topological cleaning which is not the<br>
>> >> default and not recommended.<br>
>> ><br>
>> ><br>
>> > Maybe this calls for a v.check.topology module ? Or an option in v.build<br>
>> > or<br>
>> > v.clean which does that (i.e. just check, not clean) ?<br>
>><br>
>> Good idea. I would opt for a new option/flag for v.build, which can<br>
>> already provide rather detailed diagnostics, e.g. dumping topology.<br>
>> Something like v.build -e for extended topology checks?<br>
>><br>
>> Markus M<br>
>> _______________________________________________<br>
>> grass-user mailing list<br>
>> <a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
><br>
><br>
</div></div></blockquote></div><br>