<br><div class="gmail_quote">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>By default, pseudo-topology and a spatial index is built for both v.external and direct OGR access.<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;">
Questions:<br>
- what is meant by pseduo-topology?<br></blockquote><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><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><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><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><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><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><br>Can you give examples for such SF algorithms/operators? It's not clear to me what you have in mind.<br> </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><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>