<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;">Hi Markus,<br>thanks for the clarifying reply.<br>
For SF algorithms I mean those that can apply to SF structures, as meant by the OGC definition. For example a simple clip based on the SF spatial operators (like those in v.select in GRASS 7).<br></blockquote><div><br>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). 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>Enabling v.select to work without topology would 1) require a near complete rewrite of the module and 2) make clips slower, at least for native GRASS vectors.<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's not uncommon to need these operations rapidly, even on unclean data (at least, this happens frequently between my collegues and practioners). </blockquote><div><br>These operations should be quite fast for native vectors with 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;"><br>
But from your explanation I understand that with pseudo-topology Grass can digest unclean polygons too... so I suppose that these kind of operations (like a clip) can be rapidly made through direct OGR read access. </blockquote>
<div><br>Yes, although not that rapidly because pseudo-topology needs to be built first. Polygons do not need to be clean, but then nobody can guarantee for the results.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Even with v.external? </blockquote><div><br>Yes.<br><br>Markus M<br><br></div><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br><div class="gmail_quote">
2010/4/19 Markus Metz<span dir="ltr">></span><div><div></div><div class="h5"><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><div class="gmail_quote"><div>G. Allegri <span dir="ltr"></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;">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. </blockquote><div> </div></div><div>By default, pseudo-topology and a spatial index is built for both v.external and direct OGR access.<br><br></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Questions:<br>
- what is meant by pseduo-topology?<br></blockquote></div><div><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>
</div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- 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></blockquote></div><div><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>
</div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<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></blockquote></div><div><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>
</div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
My first concern is about the use of simple features in the grass<br>
environment, and tha ability to write SF algorithms </blockquote></div><div><br>Can you give examples for such SF algorithms/operators? It's not clear to me what you have in mind.<br> </div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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></blockquote></div><div><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>
</div></div><br>Markus M<br>
</blockquote></div></div></div><br>
</blockquote></div><br>