[pgrouting-users] New release planning for pgrouting 2.1 and 3.0 was) Re: [pgrouting-dev] Proposal: towards 3.0.0

[Stephen Woodbridge]

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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>