[pgrouting-dev] A roadmap

Tue Apr 3 20:05:38 PDT 2018

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 at 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 at lists.osgeo.org] *On
> Behalf Of *Vicky Vergara
> *Sent:* Tuesday, April 03, 2018 11:37 AM
> *To:* pgRouting developers mailing list <pgrouting-dev at 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 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
>

-- 
Georepublic UG & Georepublic Japan
eMail: daniel.kastl at georepublic.de
Web: https://georepublic.info
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20180404/2a176995/attachment-0001.html>