<br><div class="gmail_quote">On Wed, Apr 21, 2010 at 2:19 PM, G. Allegri <span dir="ltr"><<a href="mailto:giohappy@gmail.com">giohappy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
These are respectable points of view. As I've repeated many times in<br>
this post, I don't expect Grass to work different. My only questions<br>
was: is it possible to do not-topological processing in Grass? Given<br>
its data structures, is it possible to develop geoprocessing<br>
operations which don't strctly require rigorous topology? </blockquote><div><br>Sure. By default, topology or in case of OGR vectors pseudo-topology is always built, but no module enforces correct topology. If topology is not correct, results might be not correct, but in this case results would also not be correct when doing equivalent processing in a non-topological environment. GRASS gives you the chance to fix errors that would not be detectable in a non-topological environment, but you don't have to fix them. But then, GRASS will most probably remind you regularly that something is wrong with the data ;-)<br>
<br>Markus M<br><br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">It seems<br>
that the answer is not. Ok, that's all I needed :)<br>
<br>
thanks for all the usefull informations you gave me,<br>
giovanni<br>
<br>
<br>
2010/4/21 Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>>:<br>
<div><div></div><div class="h5">> On 21/04/10 00:21, Volker Wichmann wrote:<br>
>><br>
>> Hi Moritz,<br>
>><br>
>> I fully agree with you that GRASS should not change its concepts. But<br>
>> your arguments are misleading: just cleanning up your vector data does<br>
>> not imply that your results are more correct - the cleaning process<br>
>> itself introduces new errors. so it depends on your application if it is<br>
>> more appropriate to count a point twice or to let the cleaning algorithm<br>
>> take the choice to which polygon it will be added. The "dirty" approach<br>
>> somehow introduces some kind of fuzziness. With SAGA we also encourage<br>
>> the user to know her/his data - but we leave it to the user to decide if<br>
>> the she/he wants to do a certain calculation or not. It's in her/his<br>
>> responsibility to interpret the results correctly. This is a thing which<br>
>> software can't take the responsibility for.<br>
><br>
> I think this is exactly what I said:<br>
><br>
>>> I see as one of the trademarks and strengths of<br>
>>> GRASS its rigour in pushing the [user] as far as possible towards a<br>
>>> careful and thoughtful use of the data.<br>
><br>
> You can decide how to clean the data, but you have to make a choice. If you<br>
> just let the user do what he wants without thinking about the implications<br>
> of the data quality for his results, then I would wager that many analyses<br>
> contain mistakes without anybody knowing about them.<br>
><br>
> As you so rightly say, it's one of these questions about whether software<br>
> should impose certain limits or leave complete freedom to the user to make<br>
> his own mistakes. Not currently active as a developer, but active in using<br>
> GRASS for teaching and research, I see daily how GRASS allows us to avoid a<br>
> series of mistakes (cf also the debate about on-the-fly reprojection). And<br>
> when there are so many other tools out there to do analyses on spaghetti<br>
> data, and so little developers available for GRASS, I'd rather see those<br>
> spend time on the core strenghts of GRASS, then on trying to implement this<br>
> particular feature.<br>
><br>
> But as always, that's only my less than 2 cents worth...<br>
><br>
> Moritz<br>
><br>
><br>
>> Moritz Lennert schrieb:<br>
>>><br>
>>> I don't want to make this discussion go on too long, but<br>
>>><br>
>>> On 20/04/10 13:38, G. Allegri wrote:<br>
>>>><br>
>>>> 1 - we had to make a simple points in polygon count. The polygon layer<br>
>>>> wasn't 'clean' (we hadn't perfect boundary adjacency for example), and<br>
>>>> it was made of hundreds of thousands of polygons. The v.in.ogr<br>
>>>> process, and the necessary clean, was taking too much time respect to<br>
>>>> the simple operation we needed, so we imported it in saga, and with a<br>
>>>> few clicks we had our result.<br>
>>><br>
>>> This is typically the example where quick and dirty "works", but where<br>
>>> it might contain imprecise results if you do not ensure clean<br>
>>> polygons: any point falling into sliver polygons will be counted<br>
>>> double. So this is exactly why I would plead for not allowing such<br>
>>> operation in GRASS, as I see as one of the trademarks and strengths of<br>
>>> GRASS its rigour in pushing the use as far as possible towards a<br>
>>> careful and thoughful use of the data.<br>
>>><br>
>>> Moritz<br>
>>> _______________________________________________<br>
>>> grass-dev mailing list<br>
>>> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
>>> <a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
>><br>
>><br>
><br>
> _______________________________________________<br>
> grass-dev mailing list<br>
> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
><br>
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</div></div></blockquote></div><br>