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 <[email protected]>: > > On Wed, Apr 21, 2010 at 2:19 PM, G. Allegri <[email protected]> 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 <[email protected]>: >> > 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 >> >>> [email protected] >> >>> http://lists.osgeo.org/mailman/listinfo/grass-dev >> >> >> >> >> > >> > _______________________________________________ >> > grass-dev mailing list >> > [email protected] >> > http://lists.osgeo.org/mailman/listinfo/grass-dev >> > >> _______________________________________________ >> grass-dev mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/grass-dev > > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
