Hi Steve,<div><br></div><div>Very good points! Actually I would even say: let's drop all wrapper functions for the beginning. Then we concentrate on core functions first. We better add tests for each algorithm before spending much time with wrapper functions.</div>
<div><br></div><div>Since many new shortest path will be added, I'm concerned that wrapper functions may contain lots of duplicate code. I hope there is a smart way to avoid this.</div><div><br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would also question, the need to return geometries. Daniel you are always pointing out the graph solution are not always about vehicle routing and that many graph solution do not have any geometries. </blockquote>
<div><br></div><div>Hmm, networks usually have geometries. But for Dijkstra lat/lon of start and end point are actually not important. But I also think that if someone doesn't need geometry information, just don't use the wrapper function. In most cases though it will help users to display the route. Especially for beginners, that might not find it so easy to build more advanced queries.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think that what this speaks to is some layering or pipelining of functions. For example, if the core function returns an ID to the geometry then is it easily joined with the geometry table. If you want trimmed first and last segments, then write a wrapper that does the join and trim should be possible.<br>
</blockquote><div><br></div><div>I thought a bit about which are the top requested and convenient "features" a wrapper could provide:</div><div><ol><li>Clipping data to load the minimum required network extent (ie. BBOX clip)</li>
<li>Accept start and end point geometries as input parameters and return a route starting/ending from/at the nearest road segment of the network.</li><li>Return a route with flipped road segments (if necessary), so they are in the right direction, and maybe add angle values, so the result can be used for driving directions for example. </li>
</ol></div><div>With (2) and (3) I would also return geometries.</div><div><br></div><div>If someone has more ideas, please share them.</div><div><br></div><div>Daniel</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Anyway, starting an RFC and will allow us all to help develop something that will make sense. I would also like to get comments from our past and current GSoC students. I think this process needs to move along pretty fast as I do not want to block the work Mario is doing on this.<br>
<br>
Mario, Can you create a page on the wiki with what you think the wrappers should look like and post the link to that for comments.<br>
<br>
Thanks,<br>
-Steve<div><br>
<br>
On 7/2/2012 3:11 AM, Daniel Kastl wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Hi Mario,<br>
<br>
In my opinion I would drop functions like the one you mentioned and<br>
reduce the number of wrappers as much as possible.<br>
<br>
I think a good and useful wrapper function is one, that selects a BBOX<br>
containing start and end point and returns records with geometries.<br>
Then everyone can modify it as needed. I don't think we should simplify<br>
those basic wrappers and make assumptions like naming the cost column<br>
"length" or so.<br>
<br>
What do you think?<br>
<br>
Daniel<br>
<br>
<br>
<br>
<br>
On Mon, Jul 2, 2012 at 9:02 AM, Mario Basa <<a href="mailto:mario.basa@gmail.com" target="_blank">mario.basa@gmail.com</a><br></div><div>
<mailto:<a href="mailto:mario.basa@gmail.com" target="_blank">mario.basa@gmail.com</a>>> wrote:<br>
<br>
Hello,<br>
<br>
The core wrapper functions have<br>
<br>
dijkstra_sp_delta_directed<br>
astar_sp_delta_directed<br>
<br>
with "length" hard coded as cost for some reason.<br>
<br>
While astar_sp_delta_cc has a cost column parameter, but all it does<br>
is call astar_sp_delta_cc_directed with<br>
reverse_cost=false,directed=<u></u>false.<br>
<br>
There is also no dijkstra_sp_delta_cc with a cost column parameter, so<br>
a user has to rename the column containing the cost value to "length"<br>
to use this clipping function. Etc....<br>
<br>
Personally I am getting confused with all these functions and would<br>
like to just trim it down to dijkstra_sp_delta and astar_sp_delta with<br>
a cost column parameter along with reverse_cost and directed<br>
parameters.<br>
<br>
Opinions?<br>
<br>
Mario.<br>
______________________________<u></u>_________________<br>
pgrouting-dev mailing list<br></div>
<a href="mailto:pgrouting-dev@lists.osgeo.org" target="_blank">pgrouting-dev@lists.osgeo.org</a> <mailto:<a href="mailto:pgrouting-dev@lists.osgeo.org" target="_blank">pgrouting-dev@lists.<u></u>osgeo.org</a>><div>
<br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/pgrouting-dev</a><br>
<br>
<br>
<br>
<br>
--<br>
Georepublic UG & Georepublic Japan<br></div>
eMail: <a href="mailto:daniel.kastl@georepublic.de" target="_blank">daniel.kastl@georepublic.de</a> <mailto:<a href="mailto:daniel.kastl@georepublic.de" target="_blank">daniel.kastl@<u></u>georepublic.de</a>><br>
Web: <a href="http://georepublic.de" target="_blank">http://georepublic.de</a> <<a href="http://georepublic.de/" target="_blank">http://georepublic.de/</a>><div><br>
<br>
<br>
______________________________<u></u>_________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org" target="_blank">pgrouting-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/pgrouting-dev</a><br>
<br>
</div></blockquote><div><div>
<br>
<br>
______________________________<u></u>_________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org" target="_blank">pgrouting-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/pgrouting-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">Georepublic UG & Georepublic Japan<br>eMail: <a href="mailto:daniel.kastl@georepublic.de" style="color:rgb(66,99,171)" target="_blank">daniel.kastl@georepublic.de</a><br>
Web: <a href="http://georepublic.de/" style="color:rgb(66,99,171)" target="_blank">http://georepublic.de</a></span><br>
</div>