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

[Markus Metz]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20100421/cd8ebc2b/attachment-0001.html