<br><br>2010/4/19 Markus Metz <<a href="mailto:markus.metz.giswork@googlemail.com">markus.metz.giswork@googlemail.com</a>><br>><br>> G. Allegri wrote:<br>>><br>>> 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>><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). <br>
<br>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.<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>you mean pseudo-topology. I'm sorry, but I need to be clear, otherwise I make some confusion :)<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>
<br>No problem, this is not what I expect. 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. Obviously the correctness of results depend on the operation the user is doing (and it's his problem) but, i.e. a geometrical clip will be always correct, I think...<br>
<br>> These operations should be quite fast for native vectors with topology.<br><br>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!)<br>
<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><br>Ok, but the user just have to wait and wath the progress bar completing... that's ok from his perspective :)<br>
<br><br>>> Even with v.external?<br>><br>> Yes.<br><br>Ok, so v.external could be ok too.<br><br>giovanni<br><br><br>><br>> Markus M<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>