[pgrouting-dev] A roadmap

[Aasheesh Tiwari]

Thank You Vicky ma'am for sharing some insight about future works.

While drafting my GSoC proposal I found that there are a lot of stable
functions ( probably made by previous GSoC participants) , these functions
must be tested thoroughly and released with next version. As I am new to
pgRouting community , I cannot comment on CGAL dependency issue  but it
looks that it needs to be addressed in next release. I think that Roadmap
#2 is more beneficial , it is also easier to execute. We as a community can
test the proposed and experimental functions , this will give more
functionality to pgRouting in future.

Aasheesh Tiwari
Mtech , IIT Bombay

On Tue, Apr 3, 2018 at 9:06 PM, 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/8b10464c/attachment.html>