[GRASS-dev] v.external, ogr direct access, topology and pseudo-topology.... a bit confused

[G. Allegri]

These are respectable points of view. As I've repeated many times in
this post, I don't expect Grass to work different. My only questions
was: is it possible to do not-topological processing in Grass? Given
its data structures, is it possible to develop geoprocessing
operations which don't strctly require rigorous topology? It seems
that the answer is not. Ok, that's all I needed :)

thanks for all the usefull informations you gave me,
giovanni


2010/4/21 Moritz Lennert <mlennert at club.worldonline.be>:
> On 21/04/10 00:21, Volker Wichmann wrote:
>>
>> Hi Moritz,
>>
>> I fully agree with you that GRASS should not change its concepts. But
>> your arguments are misleading: just cleanning up your vector data does
>> not imply that your results are more correct - the cleaning process
>> itself introduces new errors. so it depends on your application if it is
>> more appropriate to count a point twice or to let the cleaning algorithm
>> take the choice to which polygon it will be added. The "dirty" approach
>> somehow introduces some kind of fuzziness. With SAGA we also encourage
>> the user to know her/his data - but we leave it to the user to decide if
>> the she/he wants to do a certain calculation or not. It's in her/his
>> responsibility to interpret the results correctly. This is a thing which
>> software can't take the responsibility for.
>
> I think this is exactly what I said:
>
>>> I see as one of the trademarks and strengths of
>>> GRASS its rigour in pushing the [user] as far as possible towards a
>>> careful and thoughtful use of the data.
>
> You can decide how to clean the data, but you have to make a choice. If you
> just let the user do what he wants without thinking about the implications
> of the data quality for his results, then I would wager that many analyses
> contain mistakes without anybody knowing about them.
>
> As you so rightly say, it's one of these questions about whether software
> should impose certain limits or leave complete freedom to the user to make
> his own mistakes. Not currently active as a developer, but active in using
> GRASS for teaching and research, I see daily how GRASS allows us to avoid a
> series of mistakes (cf also the debate about on-the-fly reprojection). And
> when there are so many other tools out there to do analyses on spaghetti
> data, and so little developers available for GRASS, I'd rather see those
> spend time on the core strenghts of GRASS, then on trying to implement this
> particular feature.
>
> But as always, that's only my less than 2 cents worth...
>
> Moritz
>
>
>> Moritz Lennert schrieb:
>>>
>>> I don't want to make this discussion go on too long, but
>>>
>>> On 20/04/10 13:38, G. Allegri wrote:
>>>>
>>>> 1 - we had to make a simple points in polygon count. The polygon layer
>>>> wasn't 'clean' (we hadn't perfect boundary adjacency for example), and
>>>> it was made of hundreds of thousands of polygons. The v.in.ogr
>>>> process, and the necessary clean, was taking too much time respect to
>>>> the simple operation we needed, so we imported it in saga, and with a
>>>> few clicks we had our result.
>>>
>>> This is typically the example where quick and dirty "works", but where
>>> it might contain imprecise results if you do not ensure clean
>>> polygons: any point falling into sliver polygons will be counted
>>> double. So this is exactly why I would plead for not allowing such
>>> operation in GRASS, as I see as one of the trademarks and strengths of
>>> GRASS its rigour in pushing the use as far as possible towards a
>>> careful and thoughful use of the data.
>>>
>>> Moritz
>>> _______________________________________________
>>> grass-dev mailing list
>>> grass-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>