#224: cache bug in DGLib ----------------------+----------------------------------------------------- Reporter: martinl | Owner: grass-...@… Type: defect | Status: reopened Priority: major | Milestone: 6.4.1 Component: Vector | Version: 6.4.0 Resolution: | Keywords: dglib, cache, v.net.path Platform: All | Cpu: All ----------------------+-----------------------------------------------------
Comment(by mmetz): Replying to [comment:17 mmetz]: > > Also, with cache enabled it would be great if you could design a test where you recover a path to a given point and in the very next step recover a path from the same starting point but the end point must be exactly one line (edge) farther away from the previous end point. First, this second end point must be reachable, second, the shortest path to this second end point should go through the previous end point, unless there is a shorter path avoiding the previous end point. I have done that with a small test vector that should represent all sorts of special cases targeting BUG1 and BUG2 but I might have overlooked something. > Done with OpenStreetMap roads, the cache is now robust, results are correct. BTW, time to update the documentation: when many shortest paths or distances are to be calculated from the same starting point, v.net.path is fastest if the (estimated) longest path/distance is calculated first and the shorter paths/distances are extracted later (chances are good that they are now already known). Markus M -- Ticket URL: <http://trac.osgeo.org/grass/ticket/224#comment:18> GRASS GIS <http://grass.osgeo.org>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev