<div dir="ltr">Hello ,<br><br>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<br><ul><li><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Number of non-pgRouting users using the experimental function</span><br></li><li>Number of issues related to the experimental function </li><li>Dependency of a stable function on the experimental function for optimization.</li></ul>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.<br><br>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. <br><br>I am also excited to see the rewrite of pgr_trsp with a dijkstra implementation. <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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. </span><br><br><br>Regards,<br>Rohith Reddy.<br><br><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">[1] <a href="https://github.com/pgRouting/pgrouting/issues/1003">https://github.com/pgRouting/pgrouting/issues/1003</a></span><br>[2] <a href="https://github.com/pgRouting/pgrouting/issues/1004">https://github.com/pgRouting/pgrouting/issues/1004</a><br>[3] <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><a href="https://github.com/pgRouting/pgrouting/issues/1005">https://github.com/pgRouting/pgrouting/issues/1005</a></span><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">[4] <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><a href="https://github.com/pgRouting/pgrouting/issues/1006">https://github.com/pgRouting/pgrouting/issues/1006</a></span></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 10, 2018 at 3:47 AM, Aditya Pratap Singh <span dir="ltr"><<a href="mailto:adityapratap.singh28@gmail.com" target="_blank">adityapratap.singh28@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<br><b style="font-weight:normal" id="m_-1237438595118405342gmail-docs-internal-guid-b411c806-ac79-1adf-ebaf-88f505949054"><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><br></p></b><div class="gmail_extra"><div class="gmail_extra">When I was reading documentation I found a bug in pgr_withPointsDD and I created an issue ( <a href="https://github.com/pgRouting/pgrouting/issues/979" target="_blank">https://github.com/pgRouting/<wbr>pgrouting/issues/979</a> ) 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.</div><div class="gmail_extra">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.</div><div class="gmail_extra">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. </div><div class="gmail_extra">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.</div><div><br></div><div>Thanks</div><div>Aditya Pratap Singh<br><br></div><div class="gmail_quote"><span class="">On Tue, Apr 3, 2018 at 9:06 PM, Vicky Vergara <<a href="mailto:vicky@georepublic.de" target="_blank">vicky@georepublic.de</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<br><br> Hello fellow developers,<br><br> As you know we are rewriting pgRouting, since v2.1, to remove all "bugs",<br> like the non standard way of constructing a graph, and using more C++<br> features.<br><br> The rewrite is "almost done":<br><br> **First pair of functions**<br><br></span>    - pgr_alphaShape - Alpha shape computation<br>    - pgr_pointsAsPolygon - Polygon around a set of points<div><div class="h5"><br><br> Both functions are tightly dependant, and I believe that they should be a<br> postGIS function as is a geometry function, and the closest one that<br> resembles this pair of functions is  ST_ConcaveHull [1] Some time ago I<br> compared both functions on [2]<br><br> I went to see how to add that function to postGIS, and for the moment that<br> is not possible, it sould be done first in GEOS, and  GEOS is so big, right<br> now I dont feel is the time to do that, but rewriting to use boost:Geometry<br> would eliminate the need of CGAL, so one less pre-requisite to build<br> pgRouting would be needed. or they can stay as they are now.<br><br> **The other function is pgr_trsp**<br><br> Which has so many problems at postgres level [4], Last year on GSoC,<br> Vidham tried to do a rewrite, confirming that the problem is much harder<br> than expected for the 3 month program. But as far as I know many people use<br> them because it has the "points" version.<br> The C++ code is not well designed [5], just a look at that, my_dijkstra<br> calls my_dijkstra and that calls my_dijkstra, it still uses pointers, so<br> great chance of memory leaks, etc.<br> Basically is **Use at your own risk**<br><br><br> Beside those functions mentioned above, now we are in the moment where<br> there are  more proposed functions [7] than official functions. and a lot<br> of deprecated functions that have to be maintained and tested because of<br> backwards compatibility.<br><br> ** So, here is my road map #1 **<br> Version 2.7 to be released on September 2018 where fix bug of<br> pgr_withPoints [8] is a must have, and the possibilities of what other<br> things it could have:<br> - New functionality done by GSoC students on "experimental section"<br> - Write a substitution (with a different name maybe pgr_dijkstraTR) for<br> pgr_trsp (one vertex to one vertex) based on dijkstra<br> - Rewrite pgr_alphaShape to use boost:graph instead of CGAL<br> - move some experimental functions up to proposed<br><br> Version 3.0 I would like it to be on September 2019<br> Where a complete cleanup of the deprecated functions would be done,<br> Move proposed functions to official pgRouting functions.<br><br> ** So, here is my road map #2 **<br><br> Version 3.0 to be released on March 2019 where fix bug of pgr_withPoints<br>[8] and Complete cleanup of the deprecated functions are a must have, and<br> the possibilities of what other things it could have:<br> - New functionality done by GSoC students on "experimental section"<br> - Write a substitution (with a different name maybe pgr_dijkstraTR) for<br>   pgr_trsp (one vertex to one vertex) based on dijkstra<br> - Rewrite pgr_alphaShape to use boost:graph instead of CGAL<br> - move some experimental functions up to proposed<br> - Move proposed functions to official pgRouting functions.<br><br> Probably this second road map will make the second version of the<br> pgRouting book a little easier to write, (please Robe, comment on this)<br><br><br> We would like comments from the community about both road maps and if<br> possible  to test proposed functions and experimental functions to help<br> decide which proposed functions can go up one level. (don't forget to open<br> issues)<br><br> Regards<br> pgRouting team<br><br><br> [1] <a href="https://postgis.net/docs/ST_ConcaveHull.html" rel="noreferrer" target="_blank">https://postgis.net/docs/ST_Co<wbr>ncaveHull.html</a><br> [2] <a href="https://github.com/cvvergara/pgrouting/issues/57" rel="noreferrer" target="_blank">https://github.com/cvvergara/p<wbr>grouting/issues/57</a><br> [3] <a href="https://github.com/pgRouting/pgrouting/blob/master/sql/" rel="noreferrer" target="_blank">https://github.com/pgRouting/p<wbr>grouting/blob/master/sql/</a><br> alpha_shape/alpha_shape.sql#<wbr>L62<br> [4] <a href="https://github.com/pgRouting/pgrouting/tree/master/doc/trsp" rel="noreferrer" target="_blank">https://github.com/pgRouting/p<wbr>grouting/tree/master/doc/trsp</a><br> [​5] <a href="https://github.com/pgRouting/pgrouting/blob/master/include/" rel="noreferrer" target="_blank">https://github.com/pgRouting/p<wbr>grouting/blob/master/include/</a>t<wbr>rsp/GraphDefinition.h#L94​<br> [​6] <a href="https://github.com/pgRouting/pgrouting/tree/master/sql/pickDeliver" rel="noreferrer" target="_blank">https://github.com/pgRouting/p<wbr>grouting/tree/master/sql/pickD<wbr>eliver</a>​<br> [​7] <a href="http://docs.pgrouting.org/latest/en/proposed.html" rel="noreferrer" target="_blank">http://docs.pgrouting.org/late<wbr>st/en/proposed.html</a><br> [8] <a href="https://github.com/pgRouting/pgrouting/issues/760" rel="noreferrer" target="_blank">https://github.com/pgRouting/p<wbr>grouting/issues/760</a>​<br><br> --<br><br> Georepublic UG (haftungsbeschränkt)<br> Salzmannstraße 44,<br> 81739 München, Germany<br><br> Vicky Vergara<br> Operations Research<br><br> eMail: <a href="mailto:vicky@georepublic.de" target="_blank">vicky@georepublic.de</a><br> Web: <a href="https://georepublic.info" rel="noreferrer" target="_blank">https://georepublic.info</a><br><br> Tel: +49 (089) 4161 7698-1<br> Fax: +49 (089) 4161 7698-9<br><br> Commercial register: Amtsgericht München, HRB 181428<br> CEO: Daniel Kastl<br>
</div></div></blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org">pgrouting-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/pgrouting-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/pgrouting-dev</a><br></blockquote></div><br></div>