[pgrouting-dev] PGR-2: Add some robustness to the boost wrappers

pgRouting pgrouting-dev
1

Hi all,

I have looking into how to fix issue #32 which has to do with a fatal error happening deep in the boost code.

I think we have the info we need to fix this issue in C++ but I need some C++ developer help as you already know.

Anyway I have found a simple way to catch these error and without crashing the server. In all likelihood, this will cause memory leaks which probably will require a graceful server restart, but at least it won't be a hard crash like before.

So the pattern for this is to simply wrapt the whole body of any C++ code that is called from C with a try-cacth block like:

int my_cpp_function(args...)
{
   try {

     //function body

     return EXIT_SUCCESS;
   }
   catch(...) {
     return -1;
   }
}

So I just added this change to the following files:

src/apsp_johnson/src/apsp_johnson_boost_wrapper.cpp
src/apsp_warshall/src/apsp_boost_wrapper.cpp
src/astar/src/astar_boost_wrapper.cpp
src/dijkstra/src/boost_wrapper.cpp
src/dijkstra/tester/boost_wrapper.cpp
src/driving_distance/src/boost_drivedist.cpp

and my test file for issue #32 now reports:

pgr_test=# SELECT * FROM pgr_dijkstra('SELECT id, source, target, cost FROM network', 4401489, 4401483, false, false) ;
ERROR: Error computing path: Unknown exception caught!

but it does not crash the server.

Progress in small steps!

-Steve

2

Hi,

Are there any plans to implement a version of the traveling salesman problem that would use a non euclidean solution and perhaps include a cost factor?

My network is navigated in terms of a cost function for getting between two different nodes, which givens a 'distance' calculation between two different nodes the cost of the journey between A->B and B->A may be different.

Is anybody aware of any work that may have been done in implementing such a solution in pgroute software? From my understanding the current version of traveling salesman only works in term of euclidean distance which is measured from an direct calculation of the physical location. Such that the cost of A->B is the same as B->A

Dave.

3

On Sun, May 19, 2013 at 5:28 PM, Dave Potts <dave.potts@pinan.co.uk> wrote:

Hi,

Are there any plans to implement a version of the traveling salesman
problem that would use a non euclidean solution and perhaps include a cost
factor?

My network is navigated in terms of a cost function for getting between
two different nodes, which givens a 'distance' calculation between two
different nodes the cost of the journey between A->B and B->A may be
different.

Is anybody aware of any work that may have been done in implementing such
a solution in pgroute software? From my understanding the current version
of traveling salesman only works in term of euclidean distance which is
measured from an direct calculation of the physical location. Such that
the cost of A->B is the same as B->A

Hi Dave,

Best would be to pass a distance matrix as parameter of TSP.
Then the calculation of the distances would be more flexible: euclidean
distance for example, if it should be fast. Or someone could already have a
distance matrix stored as a different able.

But this hasn't been implemented.
Steve and I talked about it already though.

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

4

On 5/19/2013 4:28 AM, Dave Potts wrote:

Hi,

Are there any plans to implement a version of the traveling salesman
problem that would use a non euclidean solution and perhaps include a
cost factor?

My network is navigated in terms of a cost function for getting between
two different nodes, which givens a 'distance' calculation between two
different nodes the cost of the journey between A->B and B->A may be
different.

Is anybody aware of any work that may have been done in implementing
such a solution in pgroute software? From my understanding the current
version of traveling salesman only works in term of euclidean distance
which is measured from an direct calculation of the physical location.
Such that the cost of A->B is the same as B->A

Dave,

My plan has been to write another API that will allow you to pass a distance matrix to the solver and it will return the ordered indexes to the matrix. I'll see if I can pick up the pace on that.

Initially, I my goal was to just get rid of the GAUL dependancy and it was fairly easy to just slide the new code into the existing api transparently for the most part.

-Steve