[pgrouting-dev] A roadmap

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[pgrouting-dev] A roadmap

Vicky Vergara-2

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

[
[
[
--
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] A roadmap

Regina Obe

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:[hidden email]] On Behalf Of Vicky Vergara
Sent: Tuesday, April 03, 2018 11:37 AM
To: pgRouting developers mailing list <[hidden email]>
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

 

[


[


[


--

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany
 
Vicky Vergara
Operations Research
 
eMail: vicky@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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] A roadmap

dkastl
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 <[hidden email]> 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:[hidden email]] On Behalf Of Vicky Vergara
Sent: Tuesday, April 03, 2018 11:37 AM
To: pgRouting developers mailing list <[hidden email]>
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

 

[


[


[


--

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany
 
Vicky Vergara
Operations Research
 
eMail: vicky@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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev



--
Georepublic UG & Georepublic Japan
eMail: [hidden email]
Web: https://georepublic.info




_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] A roadmap

Aasheesh Tiwari
In reply to this post by Vicky Vergara-2
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 <[hidden email]> 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

[
[
[
--
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] A roadmap

A Tasca
In reply to this post by Vicky Vergara-2
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 <[hidden email]> 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

[
[
[
--
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] A roadmap

Aditya Pratap Singh
In reply to this post by Vicky Vergara-2
Hello,


When I was reading documentation I found a bug in pgr_withPointsDD and I created an issue ( https://github.com/pgRouting/pgrouting/issues/979 ) which was finally resolved but as you pointed this function still have some other bugs, So it should be our first prior to fix bugs of pgr_withPoints function.
I think it is right time to take some proposed function to official function as there are very less official functions and some experiment function to proposed function.
Seriously telling I don’t know the functionality of pgr_alphaShape but as Daniel said that there are very few non-pgRouting users, that find the AlphaShape function useful. So according to me it should be our least prior but if possible and time permit we can implement using boost in #2 road map. 
Another important function is pgr_trsp. I know the functionality of this function and as you have pointed this function is not well designed. So we will fix bugs of this function ASAP as many users are using this functions. So, I’ll also go with road map #2 as it looks more stable to me. I am going to learn lot of things in release of version 3.0 of pgRouting.

Thanks
Aditya Pratap Singh

On Tue, Apr 3, 2018 at 9:06 PM, Vicky Vergara <[hidden email]> 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: [hidden email]
 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] A roadmap

Rohith Reddy
Hello ,

The road map looks great !!!! I really like the idea of moving some experimental functions to proposed functions in both the road maps. I believe that this will continue to be in all the future road maps, as the experimental section keep accumulating with functions every year by the addition of new functionality by the GSoC students. So the question now is how can we efficiently convert these into proposed functions. I would suggest that moving the experimental functions to the proposed functions can be carried out based on a priority which can be the following
  • Number of non-pgRouting users using the experimental function
  • Number of issues related to the experimental function 
  • Dependency of a stable function on the experimental function for optimization.
Based on the priorities, we could start testing the experimental functions, find bugs and solve them. I feel that this would be an efficient way of enriching the pgRouting functionality and usage in the upcoming releases.

I tried to use the contraction function (developed by me) an experimental function, in one of my research projects and then realised that there are bugs in contraction function. I had opened issues [1], [2], [3], [4] for the same. I am interested in working on moving the contraction function to a stable function. I am currently working on solving the issues and soon will have the functionality well tested. 

I am also excited to see the rewrite of pgr_trsp with a dijkstra implementation. As Anthony mentioned his interest in using osm2pgrouting to extract turn data, I remember having a discussion on a rewrite of osm2pgrouting using osmosis. The functionality of extracting turn data can be considered in the rewrite of osm2pgrouting, so that it can easily be used with pgr_trsp rewrite. 


Regards,
Rohith Reddy.

[1] https://github.com/pgRouting/pgrouting/issues/1003
[2] https://github.com/pgRouting/pgrouting/issues/1004
[3] https://github.com/pgRouting/pgrouting/issues/1005

On Tue, Apr 10, 2018 at 3:47 AM, Aditya Pratap Singh <[hidden email]> wrote:
Hello,


When I was reading documentation I found a bug in pgr_withPointsDD and I created an issue ( https://github.com/pgRouting/pgrouting/issues/979 ) which was finally resolved but as you pointed this function still have some other bugs, So it should be our first prior to fix bugs of pgr_withPoints function.
I think it is right time to take some proposed function to official function as there are very less official functions and some experiment function to proposed function.
Seriously telling I don’t know the functionality of pgr_alphaShape but as Daniel said that there are very few non-pgRouting users, that find the AlphaShape function useful. So according to me it should be our least prior but if possible and time permit we can implement using boost in #2 road map. 
Another important function is pgr_trsp. I know the functionality of this function and as you have pointed this function is not well designed. So we will fix bugs of this function ASAP as many users are using this functions. So, I’ll also go with road map #2 as it looks more stable to me. I am going to learn lot of things in release of version 3.0 of pgRouting.

Thanks
Aditya Pratap Singh

On Tue, Apr 3, 2018 at 9:06 PM, Vicky Vergara <[hidden email]> 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: [hidden email]
 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] A roadmap

Vicky Vergara-2
Hello all,

Thanks all for your feedback.
Its difficult to know how many users are using the proposed or experimental functions.
Moving up one level the functions implies bug fixing and documentation enhancement. (we could even move down functions?)
"Priorities" is a subjective term: what is a priority to me might not be a priority to you, but in general:
bug fixing (no matter where in the classification, (official, proposed, experimental) the function is, and move them up a level as we see fit.
TRSP rewrite
What works don't fix (aka, pgr_alphaShape + pgr_pointsAsPolygons)


All your comments lead me to think that road map #2 with a twist:
Next version to be 3.0, but the alpha version on march 2019 with feature freeze, and make the release on August/September 2019

Reasons:
- Documentation can be improved between march and August/September
- Give some time for osm2pgRouting & pgRoutingLayers to work for 3.0
- Give time for the alpha to be tested and do bug fixes
- Because pgRouting is FOSS, "normally" we work on it on our free time, so making the alpha on march will give us more time to do better work on making the 3.0 happen

I would make the develop branch to be 3.0.0dev version this weekend, (unless another suggestion is made)

Vicky





On Tue, Apr 10, 2018 at 1:49 AM, Rohith Reddy <[hidden email]> wrote:
Hello ,

The road map looks great !!!! I really like the idea of moving some experimental functions to proposed functions in both the road maps. I believe that this will continue to be in all the future road maps, as the experimental section keep accumulating with functions every year by the addition of new functionality by the GSoC students. So the question now is how can we efficiently convert these into proposed functions. I would suggest that moving the experimental functions to the proposed functions can be carried out based on a priority which can be the following
  • Number of non-pgRouting users using the experimental function
  • Number of issues related to the experimental function 
  • Dependency of a stable function on the experimental function for optimization.
Based on the priorities, we could start testing the experimental functions, find bugs and solve them. I feel that this would be an efficient way of enriching the pgRouting functionality and usage in the upcoming releases.

I tried to use the contraction function (developed by me) an experimental function, in one of my research projects and then realised that there are bugs in contraction function. I had opened issues [1], [2], [3], [4] for the same. I am interested in working on moving the contraction function to a stable function. I am currently working on solving the issues and soon will have the functionality well tested. 

I am also excited to see the rewrite of pgr_trsp with a dijkstra implementation. As Anthony mentioned his interest in using osm2pgrouting to extract turn data, I remember having a discussion on a rewrite of osm2pgrouting using osmosis. The functionality of extracting turn data can be considered in the rewrite of osm2pgrouting, so that it can easily be used with pgr_trsp rewrite. 


Regards,
Rohith Reddy.

[1] https://github.com/pgRouting/pgrouting/issues/1003
[2] https://github.com/pgRouting/pgrouting/issues/1004
[3] https://github.com/pgRouting/pgrouting/issues/1005

On Tue, Apr 10, 2018 at 3:47 AM, Aditya Pratap Singh <[hidden email]> wrote:
Hello,


When I was reading documentation I found a bug in pgr_withPointsDD and I created an issue ( https://github.com/pgRouting/pgrouting/issues/979 ) which was finally resolved but as you pointed this function still have some other bugs, So it should be our first prior to fix bugs of pgr_withPoints function.
I think it is right time to take some proposed function to official function as there are very less official functions and some experiment function to proposed function.
Seriously telling I don’t know the functionality of pgr_alphaShape but as Daniel said that there are very few non-pgRouting users, that find the AlphaShape function useful. So according to me it should be our least prior but if possible and time permit we can implement using boost in #2 road map. 
Another important function is pgr_trsp. I know the functionality of this function and as you have pointed this function is not well designed. So we will fix bugs of this function ASAP as many users are using this functions. So, I’ll also go with road map #2 as it looks more stable to me. I am going to learn lot of things in release of version 3.0 of pgRouting.

Thanks
Aditya Pratap Singh

On Tue, Apr 3, 2018 at 9:06 PM, Vicky Vergara <[hidden email]> 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: [hidden email]
 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev



--
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] A roadmap

Cayetano Benavent
Thank you Vicky, and sorry for my late response. I'm sure this roadmap draws a good and solid future for pgRouting. I would like to add some thoughts from my own experience:
- CGAL dependent functions: I'm agree with you that pgr_alphaShape and pgr_pointsAsPolygon should be inside PostGIS as they are pure geometric functions and CGAL is a too big dependence. However both functions works well and they are so usefull to build geometries for catchment areas.
- Personal thoughts about TRSP and Withpoints functions: 
+ TRSP: the use of turn restrictions is critical to build real world vehicle routing applications, so I think this is a very important function. Putting the focus on this family of functions is a success due to the high level of interest it has (and will have much more). But I think there is an important weakness with TRSP: if you want to use with arbitrary points (edge fractions in this case, but without road side) you need to use old implementation that it is not very solid (performance is bad and there are some bugs). In the future, when TRSP function will be more estable, it could be interesting too to have a TRSP cost matrix function to compute big cost matrices.
+ Withpoints: When you develop a vehicle routing application you almost always get input data (source and target) as points with road side. For this reason this family of functions is so important too. It works well, but it has an importante weakness: there is no way to take control of turn restrictions and this is a big problem working with vehicles (I'm very worried about u-turns). The perfect shortest path function when you are working with vehicles would be the current Withpoint function capable of using a restrictions table.

Related to osm2pgrouting it would be interesting to continue with the experiments with Libosmium to build restrictions tables form OSM data. With real data we could test and debug in a better way TRSP functions. 

Finally I would like to take this opportunity to announce you that it has been released osm2pgrouting version 2.3.4 last week and the next Milestone (2.3.5) starts his way:


Thanks,
Cayetano


Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs

2018-04-10 19:31 GMT+02:00 Vicky Vergara <[hidden email]>:
Hello all,

Thanks all for your feedback.
Its difficult to know how many users are using the proposed or experimental functions.
Moving up one level the functions implies bug fixing and documentation enhancement. (we could even move down functions?)
"Priorities" is a subjective term: what is a priority to me might not be a priority to you, but in general:
bug fixing (no matter where in the classification, (official, proposed, experimental) the function is, and move them up a level as we see fit.
TRSP rewrite
What works don't fix (aka, pgr_alphaShape + pgr_pointsAsPolygons)


All your comments lead me to think that road map #2 with a twist:
Next version to be 3.0, but the alpha version on march 2019 with feature freeze, and make the release on August/September 2019

Reasons:
- Documentation can be improved between march and August/September
- Give some time for osm2pgRouting & pgRoutingLayers to work for 3.0
- Give time for the alpha to be tested and do bug fixes
- Because pgRouting is FOSS, "normally" we work on it on our free time, so making the alpha on march will give us more time to do better work on making the 3.0 happen

I would make the develop branch to be 3.0.0dev version this weekend, (unless another suggestion is made)

Vicky





On Tue, Apr 10, 2018 at 1:49 AM, Rohith Reddy <[hidden email]> wrote:
Hello ,

The road map looks great !!!! I really like the idea of moving some experimental functions to proposed functions in both the road maps. I believe that this will continue to be in all the future road maps, as the experimental section keep accumulating with functions every year by the addition of new functionality by the GSoC students. So the question now is how can we efficiently convert these into proposed functions. I would suggest that moving the experimental functions to the proposed functions can be carried out based on a priority which can be the following
  • Number of non-pgRouting users using the experimental function
  • Number of issues related to the experimental function 
  • Dependency of a stable function on the experimental function for optimization.
Based on the priorities, we could start testing the experimental functions, find bugs and solve them. I feel that this would be an efficient way of enriching the pgRouting functionality and usage in the upcoming releases.

I tried to use the contraction function (developed by me) an experimental function, in one of my research projects and then realised that there are bugs in contraction function. I had opened issues [1], [2], [3], [4] for the same. I am interested in working on moving the contraction function to a stable function. I am currently working on solving the issues and soon will have the functionality well tested. 

I am also excited to see the rewrite of pgr_trsp with a dijkstra implementation. As Anthony mentioned his interest in using osm2pgrouting to extract turn data, I remember having a discussion on a rewrite of osm2pgrouting using osmosis. The functionality of extracting turn data can be considered in the rewrite of osm2pgrouting, so that it can easily be used with pgr_trsp rewrite. 


Regards,
Rohith Reddy.

[1] https://github.com/pgRouting/pgrouting/issues/1003
[2] https://github.com/pgRouting/pgrouting/issues/1004
[3] https://github.com/pgRouting/pgrouting/issues/1005

On Tue, Apr 10, 2018 at 3:47 AM, Aditya Pratap Singh <[hidden email]> wrote:
Hello,


When I was reading documentation I found a bug in pgr_withPointsDD and I created an issue ( https://github.com/pgRouting/pgrouting/issues/979 ) which was finally resolved but as you pointed this function still have some other bugs, So it should be our first prior to fix bugs of pgr_withPoints function.
I think it is right time to take some proposed function to official function as there are very less official functions and some experiment function to proposed function.
Seriously telling I don’t know the functionality of pgr_alphaShape but as Daniel said that there are very few non-pgRouting users, that find the AlphaShape function useful. So according to me it should be our least prior but if possible and time permit we can implement using boost in #2 road map. 
Another important function is pgr_trsp. I know the functionality of this function and as you have pointed this function is not well designed. So we will fix bugs of this function ASAP as many users are using this functions. So, I’ll also go with road map #2 as it looks more stable to me. I am going to learn lot of things in release of version 3.0 of pgRouting.

Thanks
Aditya Pratap Singh

On Tue, Apr 3, 2018 at 9:06 PM, Vicky Vergara <[hidden email]> 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: [hidden email]
 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev



--
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] A roadmap

Maoguang Wang
Hi Vicky,

I like your roadmaps, it looks nice.
first pair of functions : I think less dependencies could improve compatibility and reduce the difficulty of future developments. But maybe use Boost::Geometry instead of CGAL will change a lot, which means a lot of work to do. In my opinion, it is not urgent for now.
pgr_trsp rewrite : I don't know this functionality much. If many users use it and it has many problems for now, I think maybe it is an important job for us developers.

Thanks,
Maoguang Wang

2018-04-11 7:51 GMT+08:00 Cayetano Benavent <[hidden email]>:
Thank you Vicky, and sorry for my late response. I'm sure this roadmap draws a good and solid future for pgRouting. I would like to add some thoughts from my own experience:
- CGAL dependent functions: I'm agree with you that pgr_alphaShape and pgr_pointsAsPolygon should be inside PostGIS as they are pure geometric functions and CGAL is a too big dependence. However both functions works well and they are so usefull to build geometries for catchment areas.
- Personal thoughts about TRSP and Withpoints functions: 
+ TRSP: the use of turn restrictions is critical to build real world vehicle routing applications, so I think this is a very important function. Putting the focus on this family of functions is a success due to the high level of interest it has (and will have much more). But I think there is an important weakness with TRSP: if you want to use with arbitrary points (edge fractions in this case, but without road side) you need to use old implementation that it is not very solid (performance is bad and there are some bugs). In the future, when TRSP function will be more estable, it could be interesting too to have a TRSP cost matrix function to compute big cost matrices.
+ Withpoints: When you develop a vehicle routing application you almost always get input data (source and target) as points with road side. For this reason this family of functions is so important too. It works well, but it has an importante weakness: there is no way to take control of turn restrictions and this is a big problem working with vehicles (I'm very worried about u-turns). The perfect shortest path function when you are working with vehicles would be the current Withpoint function capable of using a restrictions table.

Related to osm2pgrouting it would be interesting to continue with the experiments with Libosmium to build restrictions tables form OSM data. With real data we could test and debug in a better way TRSP functions. 

Finally I would like to take this opportunity to announce you that it has been released osm2pgrouting version 2.3.4 last week and the next Milestone (2.3.5) starts his way:


Thanks,
Cayetano


Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs

2018-04-10 19:31 GMT+02:00 Vicky Vergara <[hidden email]>:
Hello all,

Thanks all for your feedback.
Its difficult to know how many users are using the proposed or experimental functions.
Moving up one level the functions implies bug fixing and documentation enhancement. (we could even move down functions?)
"Priorities" is a subjective term: what is a priority to me might not be a priority to you, but in general:
bug fixing (no matter where in the classification, (official, proposed, experimental) the function is, and move them up a level as we see fit.
TRSP rewrite
What works don't fix (aka, pgr_alphaShape + pgr_pointsAsPolygons)


All your comments lead me to think that road map #2 with a twist:
Next version to be 3.0, but the alpha version on march 2019 with feature freeze, and make the release on August/September 2019

Reasons:
- Documentation can be improved between march and August/September
- Give some time for osm2pgRouting & pgRoutingLayers to work for 3.0
- Give time for the alpha to be tested and do bug fixes
- Because pgRouting is FOSS, "normally" we work on it on our free time, so making the alpha on march will give us more time to do better work on making the 3.0 happen

I would make the develop branch to be 3.0.0dev version this weekend, (unless another suggestion is made)

Vicky





On Tue, Apr 10, 2018 at 1:49 AM, Rohith Reddy <[hidden email]> wrote:
Hello ,

The road map looks great !!!! I really like the idea of moving some experimental functions to proposed functions in both the road maps. I believe that this will continue to be in all the future road maps, as the experimental section keep accumulating with functions every year by the addition of new functionality by the GSoC students. So the question now is how can we efficiently convert these into proposed functions. I would suggest that moving the experimental functions to the proposed functions can be carried out based on a priority which can be the following
  • Number of non-pgRouting users using the experimental function
  • Number of issues related to the experimental function 
  • Dependency of a stable function on the experimental function for optimization.
Based on the priorities, we could start testing the experimental functions, find bugs and solve them. I feel that this would be an efficient way of enriching the pgRouting functionality and usage in the upcoming releases.

I tried to use the contraction function (developed by me) an experimental function, in one of my research projects and then realised that there are bugs in contraction function. I had opened issues [1], [2], [3], [4] for the same. I am interested in working on moving the contraction function to a stable function. I am currently working on solving the issues and soon will have the functionality well tested. 

I am also excited to see the rewrite of pgr_trsp with a dijkstra implementation. As Anthony mentioned his interest in using osm2pgrouting to extract turn data, I remember having a discussion on a rewrite of osm2pgrouting using osmosis. The functionality of extracting turn data can be considered in the rewrite of osm2pgrouting, so that it can easily be used with pgr_trsp rewrite. 


Regards,
Rohith Reddy.

[1] https://github.com/pgRouting/pgrouting/issues/1003
[2] https://github.com/pgRouting/pgrouting/issues/1004
[3] https://github.com/pgRouting/pgrouting/issues/1005

On Tue, Apr 10, 2018 at 3:47 AM, Aditya Pratap Singh <[hidden email]> wrote:
Hello,


When I was reading documentation I found a bug in pgr_withPointsDD and I created an issue ( https://github.com/pgRouting/pgrouting/issues/979 ) which was finally resolved but as you pointed this function still have some other bugs, So it should be our first prior to fix bugs of pgr_withPoints function.
I think it is right time to take some proposed function to official function as there are very less official functions and some experiment function to proposed function.
Seriously telling I don’t know the functionality of pgr_alphaShape but as Daniel said that there are very few non-pgRouting users, that find the AlphaShape function useful. So according to me it should be our least prior but if possible and time permit we can implement using boost in #2 road map. 
Another important function is pgr_trsp. I know the functionality of this function and as you have pointed this function is not well designed. So we will fix bugs of this function ASAP as many users are using this functions. So, I’ll also go with road map #2 as it looks more stable to me. I am going to learn lot of things in release of version 3.0 of pgRouting.

Thanks
Aditya Pratap Singh

On Tue, Apr 3, 2018 at 9:06 PM, Vicky Vergara <[hidden email]> 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: [hidden email]
 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev



--
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev