<br><div class="gmail_quote">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;"><div class="im"><br><br>Markus Metz:<br>><br>
</div><div class="im">> v.select requires a spatial index which in turn requires (at least some basic information stored in) topology. Doing the same >operation without a spatial index would be much slower. BTW, v.select should be faster in GRASS 7 than in GRASS 6.x, >particularly for larger vectors, because the spatial index is handled differently in GRASS 7. The same applies for v.what (simple >vector querying). <br>
<br></div>ok, this is how grass works, but spatial index isn't strictly associated to topology. Many other gis systems use indexes but don't require topology info.</blockquote><div><br>GRASS works like this for historical reasons, in GRASS 6.x the spatial index is always built on the fly from topology, and because the spatial index also holds features only available with topology (nodes, areas and isles of native GRASS vectors). Technically it's possible to change that in GRASS 7 and build a spatial index but no topology.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"><br><br>>For direct OGR access however, topology is always built anew on the fly, whenever that OGR vector is accessed which can take >some time for larger vectors.<br>
<br></div>you mean pseudo-topology. I'm sorry, but I need to be clear, otherwise I make some confusion :)</blockquote><div><br>Right, I meant pseudo-topology. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br><br></div>[...] I just expect a user to be able to import a polygonal layer, without worrying about topology correctness (clean/build operations), and do spatial operations on it. </blockquote><div><br>
Spatial operations without a preceding topology build are currently not possible in GRASS. It would be quite a lot of work to change that if possible at all. Note that topology must not necessarily be correct, but for most operations in GRASS it must exist. I don't see such a huge drawback in building topology for OGR vectors, but then admittedly I usually import and clean them before I work with them.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
<br>> These operations should be quite fast for native vectors with topology.<br><br></div>With "rapidly" I meant: load data, do-the-op, save the results. I'm sure that the native grass data structures can deal more efficiently then SF structures.... but often a user prefer to wait a minute more for the operation to end, then working a minute to have to manage the data cleaness (more often it takes much more then a minute, and it doesn't worth it!)</blockquote>
<div><br>Cleaning is optional although highly recommended ;-) Contrary to some other topological vector formats, GRASS vectors must not be 100% clean and correct and most modules can tolerate somewhat corrupted topology. IOW, you could e.g. clip an OGR vector (linked in with v.external or direct OGR access) and directly export the result without cleaning, sometimes it might work, sometimes not.<br>
<br>OGR support in GRASS 7 is work in progress, I'm sure it will improve in the near future.<br><br>Markus M<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
</div><div><div class="h5"><br><br><br>><br>>><br>>> 2010/4/19 Markus Metz><br>>>><br>
>>> G. Allegri wrote:<br>>>>><br>>>>> I open a new post on the argument because it's something more general<br>>>>> that me and my collegues need to unsertstand.<br>>>>> I've tried to make the point with the various vector structures and<br>
>>>> modes in grass7 and I admit to be a bit confused.<br>>>>><br>>>>> - v.external is meant to read ogr data sources without the<br>>>>> topoloigcal overhead.<br>>>><br>
>>> <br>>>> By default, pseudo-topology and a spatial index is built for both v.external and direct OGR access.<br>>>><br>>>>> Questions:<br>>>>> - what is meant by pseduo-topology?<br>
>>><br>>>> Reduced topology: each boundary is attached to one area only, i.e. smoothing, simplification, removing small areas etc. will not work properly for adjacent areas or areas within areas.<br>>>> <br>
>>>><br>>>>> - does the 'b' option is referred to pseudo-topology creation? If<br>>>>> I set it, I cannot see the map and the "zoom to selected map" gives me<br>>>>> an empty error box...<br>
>>><br>>>> ... because the extends of a vector map are stored in topology, also in pseudo-topology. If topology and thus the extends are not available, "zoom to selected map" won't work. And yes, the 'b' option refers to pseudo-topology.<br>
>>> <br>>>>><br>>>>> - direct read/write access creates the same topo structure as native<br>>>>> access, but it builds it each time I open the data source. Am I wrong?<br>>>>> Is it too simplicistic my understanding?<br>
>>><br>>>> No, it also builds pseudo-topology, not native full topology, this is only available for native GRASS vectors. Full, correct topology can only be built after all polygons are cleaned as done by v.in.ogr.<br>
>>>><br>>>>> My first concern is about the use of simple features in the grass<br>>>>> environment, and tha ability to write SF algorithms<br>>>><br>>>> Can you give examples for such SF algorithms/operators? It's not clear to me what you have in mind.<br>
>>> <br>>>>><br>>>>> that don't require<br>>>>> topology to be built. This is a requirement in daily work, mostly when<br>>>>> we deal with unclean polygonal data but the topology is not required<br>
>>>> (ie simple feature operators, etc.).<br>>>><br>>>> GRASS is rather strict about polygonal data. Working with unclean polygonal data will produce unclean results which is not desired IMHO.<br>
>>><br>>>> It seems to me that you are missing some functionality in GRASS, so it would be great if you could give some examples about what is missing.<br>>>><br>>>> Markus M<br>>><br>
><br><br>
</div></div></blockquote></div><br>