[pgrouting-dev] A roadmap

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@[georepublic.de](http://georepublic.de)
Web: [https://georepublic.info](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

The Roadmap looks good to me. Should make some sections of pgRouting book obsolete and allow us to cover other topics.

*withPoints functions are very popular, but I think there has to be a simpler way of coming up with the point/frac as that’s where I think most people struggle.

But unfortunately I don’t have any thoughts about that yet and haven’t looked at recent functions added.

As far as getting rid of CGAL not sure how important that is. I think a lot of package maintainers are used to having that dependency now and for Windows, I need to include CGAL anyway to support PostGIS SFCGAL.

There is also some talk of expanding CGAL use in PostGIS. That said, if the alpha shape rewriting is a lot of work, I’d put it off, as the gain would have been useful a couple of years ago, but not so much today.

Thanks,

Regina

From: pgrouting-dev [mailto:pgrouting-dev-bounces@lists.osgeo.org] On Behalf Of Vicky Vergara
Sent: Tuesday, April 03, 2018 11:37 AM
To: pgRouting developers mailing list pgrouting-dev@lists.osgeo.org
Subject: [pgrouting-dev] A roadmap

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@[georepublic.de](http://georepublic.de)
Web: [https://georepublic.info](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

Thank you Vicky for your thoughts about the roadmap!

I agree, that the function to calculate the drivetime polygon would be much better suited to PostGIS (and/or GEOS).
It’s nice to have as few dependencies as possible. Like Regine said, current package maintainers already for got used to having CGAL as a dependency, and I remember a time, when it was a real obstacle, but now it’s not so big problem anymore.

I’m not sure, if there are non-pgRouting users, that may find the AlphaShape function useful.
It would be nice, if such a work to “move” this part out of pgRouting would be funded or contributed.

Daniel

···

On Wed, Apr 4, 2018 at 6:41 AM, Regina Obe <lr@pcorp.us> wrote:

The Roadmap looks good to me. Should make some sections of pgRouting book obsolete and allow us to cover other topics.

*withPoints functions are very popular, but I think there has to be a simpler way of coming up with the point/frac as that’s where I think most people struggle.

But unfortunately I don’t have any thoughts about that yet and haven’t looked at recent functions added.

As far as getting rid of CGAL not sure how important that is. I think a lot of package maintainers are used to having that dependency now and for Windows, I need to include CGAL anyway to support PostGIS SFCGAL.

There is also some talk of expanding CGAL use in PostGIS. That said, if the alpha shape rewriting is a lot of work, I’d put it off, as the gain would have been useful a couple of years ago, but not so much today.

Thanks,

Regina

From: pgrouting-dev [mailto:pgrouting-dev-bounces@lists.osgeo.org] On Behalf Of Vicky Vergara
Sent: Tuesday, April 03, 2018 11:37 AM
To: pgRouting developers mailing list <pgrouting-dev@lists.osgeo.org>
Subject: [pgrouting-dev] A roadmap

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@[georepublic.de](http://georepublic.de)
Web: [https://georepublic.info](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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev

Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: https://georepublic.info

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.

···

On Tue, Apr 3, 2018 at 9:06 PM, Vicky Vergara <vicky@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@[georepublic.de](http://georepublic.de)
Web: [https://georepublic.info](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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev

Aasheesh Tiwari
Mtech , IIT Bombay

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@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@[georepublic.de](http://georepublic.de)
Web: [https://georepublic.info](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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev