The language doesn't help, so please forgive me if I haven't been clear: I don't expect from grass something more or something less, I was wondering if with the new grass 7 features (like direct ogr access) it was possible to make some daily operations faster.<br>
<br>I frequently use SAGA for spatial processing, so I have its features in mind... So I just was looking how to unify the various needs (more or less rigorous) in a single environent, like grass.<br><br>giovanni<br><br><div class="gmail_quote">
2010/4/19 Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Jumping into the debate, since it raises some fundamental questions in my eyes;<div class="im"><br>
<br>
On 19/04/10 17:46, G. Allegri wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
No problem, this is not what I expect. I just expect a user to be able<br>
to import a polygonal layer, without worrying about topology correctness<br>
(clean/build operations), and do spatial operations on it. Obviously the<br>
correctness of results depend on the operation the user is doing (and<br>
it's his problem) but, i.e. a geometrical clip will be always correct, I<br>
think...<br>
</blockquote>
<br></div>
The questions here for me are:<br>
<br>
<br>
- What is the actual error linked to doing operations on non-topological formats ?<br>
<br>
- Why do you absolutely want GRASS to do this ? If all you want to do is simple geometry operations on spaghetti files, you can easily do this with most of the available open source viewers / GIS, such as QGIS, gvSIG, uDIG, etc or even directly with ogr. Why go through the trouble of using GRASS for that ?<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
These operations should be quite fast for native vectors with topology.<br>
</blockquote>
<br>
With "rapidly" I meant: load data, do-the-op, save the results. I'm sure<br>
that the native grass data structures can deal more efficiently then SF<br>
structures.... but often a user prefer to wait a minute more for the<br>
operation to end, then working a minute to have to manage the data<br>
cleaness (more often it takes much more then a minute, and it doesn't<br>
worth it!)<br>
<br>
> Yes, although not that rapidly because pseudo-topology needs to be<br>
built first. Polygons do not need to be clean, but then nobody can<br>
guarantee for the results.<br>
<br>
Ok, but the user just have to wait and wath the progress bar<br>
completing... that's ok from his perspective :)<br>
</blockquote>
<br></div>
I find it a bit suspicious when user comfort is apparently put so much higher in priority then correctness of results...<br><font color="#888888">
<br>
Moritz<br>
</font></blockquote></div><br>