Hamish wrote: > Markus M: > >> For speed-up, implement the respective algorithms directly in the GRASS >> vector libs? Lots of work... >> > > .... at the cost of having to maintain the code forever more and not > automatically get updates. > Hm, good point. But, independent of the new GEOS functionality in v.select, I was thinking about implementing some GEOS algorithms for functionality that is already used by the vector libs directly, if the GEOS algorithms are better (e.g. faster, lighter on memory) than the current vector lib version. This would mostly apply to topology building and maintenance, used by pretty much every vector module. IMO, forking would make sense in this case because it can then be better integrated in the GRASS vector libs.
With regard to v.select, I guess Martin will decide if the performance is acceptable or if it is worth a try to port some GEOS tools to GRASS, being aware of the disadvantages you mention. Markus M > is the slowness in the lib I/O or in the geos implementation? > how mature is the code? (ie will it improve/change upstream?) > > my general inclination is to not fork/clone anything if at all possible. > as long as the lib is not orphaned or too obscure for users to find, > outsource as much as possible to the experts (unless it really does > make a drastic performance difference). > > Hamish > > > _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev