[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