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