[pgrouting-dev] A roadmap

Mon Apr 9 07:36:47 PDT 2018

I am excited about the proposed work in rewriting pgr_trsp with a Dijkstra
implementation and would be happy to participate in discussion related to
this rework as it might have good implication on my work (even without
With-Points capabilities).

I am also interested in working towards moving the pgr_lineGraphFull
function up from the experimental section and am hoping to work towards
this in the near future.

I remember some discussion of making pgRouting into an API style library
for the 3.0 release where the graph can stay loaded into memory across
multiple calls to pgRouting and this change interests me because of its
potential run-time benefits.

Another project that I have seen discussion on that I am interested in is
using osm2pgrouting to extract turn data to be used with the pgr_trsp
rewrite (although I think some work has already been done on this effort).

Because of all of this I would be happy to see a 3.0 release sooner as per
road map #2 so that these improvements can be made use of sooner but both
road maps look good to me!

Thanks,
Anthony

On Tue, Apr 3, 2018 at 11:36 AM, Vicky Vergara <vicky at georepublic.de> wrote:

>
> Hello fellow developers,
>
> As you know we are rewriting pgRouting, since v2.1, to remove all "bugs",
> like the non standard way of constructing a graph, and using more C++
> features.
>
> The rewrite is "almost done":
>
> **First pair of functions**
>
>    - pgr_alphaShape - Alpha shape computation
>    - pgr_pointsAsPolygon - Polygon around a set of points
>
> Both functions are tightly dependant, and I believe that they should be a
> postGIS function as is a geometry function, and the closest one that
> resembles this pair of functions is  ST_ConcaveHull [1] Some time ago I
> compared both functions on [2]
>
> I went to see how to add that function to postGIS, and for the moment that
> is not possible, it sould be done first in GEOS, and  GEOS is so big, right
> now I dont feel is the time to do that, but rewriting to use boost:Geometry
> would eliminate the need of CGAL, so one less pre-requisite to build
> pgRouting would be needed. or they can stay as they are now.
>
>
> **The other function is pgr_trsp**
>
> Which has so many problems at postgres level [4], Last year on GSoC,
> Vidham tried to do a rewrite, confirming that the problem is much harder
> than expected for the 3 month program. But as far as I know many people use
> them because it has the "points" version.
> The C++ code is not well designed [5], just a look at that, my_dijkstra
> calls my_dijkstra and that calls my_dijkstra, it still uses pointers, so
> great chance of memory leaks, etc.
> Basically is **Use at your own risk**
>
>
> Beside those functions mentioned above, now we are in the moment where
> there are  more proposed functions [7] than official functions. and a lot
> of deprecated functions that have to be maintained and tested because of
> backwards compatibility.
>
> ** So, here is my road map #1 **
>
> Version 2.7 to be released on September 2018 where fix bug of
> pgr_withPoints [8] is a must have, and the possibilities of what other
> things it could have:
> - New functionality done by GSoC students on "experimental section"
> - Write a substitution (with a different name maybe pgr_dijkstraTR) for
> pgr_trsp (one vertex to one vertex) based on dijkstra
> - Rewrite pgr_alphaShape to use boost:graph instead of CGAL
> - move some experimental functions up to proposed
>
> Version 3.0 I would like it to be on September 2019
> Where a complete cleanup of the deprecated functions would be done,
> Move proposed functions to official pgRouting functions.
>
> ** So, here is my road map #2 **
>
> Version 3.0 to be released on March 2019 where fix bug of pgr_withPoints
> [8] and Complete cleanup of the deprecated functions are a must have, and
> the possibilities of what other things it could have:
> - New functionality done by GSoC students on "experimental section"
> - Write a substitution (with a different name maybe pgr_dijkstraTR) for
> pgr_trsp (one vertex to one vertex) based on dijkstra
> - Rewrite pgr_alphaShape to use boost:graph instead of CGAL
> - move some experimental functions up to proposed
> - Move proposed functions to official pgRouting functions.
>
> Probably this second road map will make the second version of the
> pgRouting book a little easier to write, (please Robe, comment on this)
>
>
> We would like comments from the community about both road maps and if
> possible  to test proposed functions and experimental functions to help
> decide which proposed functions can go up one level. (don't forget to open
> issues)
>
> Regards
> pgRouting team
>
>
> [1] https://postgis.net/docs/ST_ConcaveHull.html
> [2] https://github.com/cvvergara/pgrouting/issues/57
> [3] https://github.com/pgRouting/pgrouting/blob/master/sql/
> alpha_shape/alpha_shape.sql#L62
> [4] https://github.com/pgRouting/pgrouting/tree/master/doc/trsp
> [
> 5] https://github.com/pgRouting/pgrouting/blob/master/include/
> trsp/GraphDefinition.h#L94
>
> [
> 6] https://github.com/pgRouting/pgrouting/tree/master/sql/pickDeliver
>
> [
> 7] http://docs.pgrouting.org/latest/en/proposed.html
> [8] https://github.com/pgRouting/pgrouting/issues/760
>
> --
>
> Georepublic UG (haftungsbeschränkt)
> Salzmannstraße 44,
> 81739 München, Germany
>
> Vicky Vergara
> Operations Research
>
> eMail: vicky at georepublic.de
> Web: https://georepublic.info
>
> Tel: +49 (089) 4161 7698-1
> Fax: +49 (089) 4161 7698-9
>
> Commercial register: Amtsgericht München, HRB 181428
> CEO: Daniel Kastl
>
>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20180409/accf9b5c/attachment-0001.html>