[GRASS-dev] Re: [GRASS GIS] #224: cache bug in DGLib
GRASS GIS
trac at osgeo.org
Mon Oct 25 03:28:43 EDT 2010
#224: cache bug in DGLib
----------------------+-----------------------------------------------------
Reporter: martinl | Owner: grass-dev@…
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>
More information about the grass-dev
mailing list