[pgrouting-dev] Proposal: towards 3.0.0

pgRouting pgrouting-dev
1

Hello community of pgRouting developers:

I feel that pgRouting is being stagnated since the last release (2.0.0).
Part of the problem, I think, its the difficulty of creating new functions.
I’ve being working doing some modifications to create a kind of “core” for pgRouting while fixing some of the issues.
Based on that experience I wrote this proposal.
Basically, the proposal is “function based”, that is because:

  1. the code needed to connect to the database has bugs, for functions with similar signatures it was copied, so the bug spreaded out in the functions. (Not to blame the original developers, understanding the code needed to connect to postgresql its not easy task)
  2. that the underlying code cant handle bigint for ids (and osm ids are bigint)
  3. the way it handles the vertices (creating a huge table if the difference between the max value and min value of the id is big)
  4. some algorithms that can be stopped are not stopped (like Boost.graph.dijkstra) so they take longer than needed

3 & 4 are partly a consequence of the difficulty to understand of Boost.Graph, also not an easy task.

So, dijkstra, ksp, and driving distance that have very similar signatures in the SQL query parameter are the first step.
When you read the proposal, have in your mind that, there is a “core” that will simplify the coding, have the difficult tasks of connecting to postgresql as part of the core, and also the difficulty of the usage of boost.graph encapsulated to the kind of grpahs pgRouting needs, so it is easier to use.

https://docs.google.com/document/d/1lgBNr9I-otJmMJMeYyRTxi51VxvX9b6yaRWBT2p_ip4/edit

Once those are coded, and available to the community of users, we can start looking, on how to continue changing the other functions using the “core”, and Incrementing the “core” as needed.

Comments in the document are welcome as well are comments using pgrouting-dev list

Vicky Vergara

2

Hello packagers, devs and users,

Vicky has been doing a lot of work on pgrouting development. A big part of this effort has been to work with the boost code in all the algorithms that use Dijkstra and to refactor it into a common set of classes that get reused. This does a bunch of good things for us:

1) fixes lots of bugs
2) reduces the amount of code
3) reuses the same code in all the algorithms so fixing a bug in one fixes it in all of them
4) has done a huge amount of testing on the new algorithms to verify their correctness
5) has changed the function signatures to be more consistent with respect to the arguments and their meaning

Some of this code depends on C++11 so we need to know whether your system supports this so we can decide how to release this work.

For a potential pgRouting 2.1 release we need to:
* maintain compatibility with existing function signatures
* can we require C++11 or C++0x or will this break things?

For a potential pgRouting 3.0 release we can:
* break compatibility with function signature
* add the requirement for C++11 compiler

Also please read and provide feedback on Vicky's Toward 3.0 document linked below.

We need feedback!

Thanks,
   -Steve

On 6/24/2015 7:41 PM, Vicky Vergara wrote:

Hello community of pgRouting developers:

I feel that pgRouting is being stagnated since the last release (2.0.0).
Part of the problem, I think, its the difficulty of creating new functions.
I've being working doing some modifications to create a kind of "core"
for pgRouting while fixing some of the issues.
Based on that experience I wrote this proposal.
Basically, the proposal is "function based", that is because:
    1) the code needed to connect to the database has bugs, for
functions with similar signatures it was copied, so the bug spreaded out
in the functions. (Not to blame the original developers, understanding
the code needed to connect to postgresql its not easy task)
    2) that the underlying code cant handle bigint for ids (and osm ids
are bigint)
    3) the way it handles the vertices (creating a huge table if the
difference between the max value and min value of the id is big)
    4) some algorithms that can be stopped are not stopped (like
Boost.graph.dijkstra) so they take longer than needed

3 & 4 are partly a consequence of the difficulty to understand of
Boost.Graph, also not an easy task.

So, dijkstra, ksp, and driving distance that have very similar
signatures in the SQL query parameter are the first step.
When you read the proposal, have in your mind that, there is a "core"
that will simplify the coding, have the difficult tasks of connecting to
postgresql as part of the core, and also the difficulty of the usage of
boost.graph encapsulated to the kind of grpahs pgRouting needs, so it is
easier to use.

https://docs.google.com/document/d/1lgBNr9I-otJmMJMeYyRTxi51VxvX9b6yaRWBT2p_ip4/edit

Once those are coded, and available to the community of users, we can
start looking, on how to continue changing the other functions using the
"core", and Incrementing the "core" as needed.

Comments in the document are welcome as well are comments using
pgrouting-dev list

Vicky Vergara

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev