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

[G. Allegri]

Thanks Markus, this is what I needed to know. So, in synthesis:

clean topology is not required for vector processing algorithms to
work correctly (this is what I thought...) => (obviously) correctness
of results ONLY depend on correctness on input, not on algorithm
problems with unclesn topology.

thanks,
giovanni

2010/4/21 Markus Metz <markus.metz.giswork at googlemail.com>:
>
> On Wed, Apr 21, 2010 at 2:19 PM, G. Allegri <giohappy at gmail.com> wrote:
>>
>> 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?
>
> Sure. By default, topology or in case of OGR vectors pseudo-topology is
> always built, but no module enforces correct topology. If topology is not
> correct, results might be not correct, but in this case results would also
> not be correct when doing equivalent processing in a non-topological
> environment. GRASS gives you the chance to fix errors that would not be
> detectable in a non-topological environment, but you don't have to fix them.
> But then, GRASS will most probably remind you regularly that something is
> wrong with the data ;-)
>
> Markus M
>
>
>>
>> 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
>> >
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>