Hi Mario,<div><br></div><div>The reason why these wrappers are there is, that they were committed to the SVN repository long time ago.</div><div>According to Anton they were there for convenience, probably for some certain use case ... well, no more comment ;-)</div>
<div><br></div><div>I think so far core functions have a good design, taking an SQL statement as the first parameter and other parameters later.</div><div><br></div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div><font face="'courier new', monospace">PGR_<function name> (<SQL>,<parameter 1>, <parameter 2>, ...)</font></div></blockquote></div><div><br></div><div>For wrapper functions, that are part of the library, something similar would be good, too.</div>
<div>IMO these wrappers shouldn't make assumptions about column names and shouldn't set parameters to default values. If users want to do this later, that shouldn't be a problem. So one wrapper function for each core function to take into account a BBOX, and a result containing a list of geometries should be fine. Since we need to know the name of the geometry column for that, we probably need to have a parameter then if it shouldn't be hard-coded.</div>
<div><br></div><div>Maybe we could think about a naming convention for this as well, for example:</div><div><br></div><div><div><blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:40px;border-top-style:none;border-right-style:none;border-bottom-style:none;border-left-style:none;border-width:initial;border-color:initial;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px">
<font face="'courier new', monospace">PGR_<function name>_bbox (<...>, <the_geom>, <bbox buffer>)</font></blockquote></div></div><div><br></div><div><br></div><div>Daniel</div><div><br><br>
<div class="gmail_quote">On Mon, Jul 2, 2012 at 9:28 AM, Mario Basa <span dir="ltr"><<a href="mailto:mario.basa@gmail.com" target="_blank">mario.basa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Daniel,<br>
<br>
I agree. Right now it really is quite confusing which function to use,<br>
and the description of each function is not also very helpful.<br>
<br>
I am curious though why is it that there is no sp function that<br>
accepts source_x,source_y and target_x,target_y parameters similar to<br>
that of driving_distance. This I think, will be very useful.<br>
<span class="HOEnZb"><font color="#888888"><br>
Mario.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, Jul 2, 2012 at 4:11 PM, Daniel Kastl <<a href="mailto:daniel@georepublic.de">daniel@georepublic.de</a>> wrote:<br>
> Hi Mario,<br>
><br>
> In my opinion I would drop functions like the one you mentioned and reduce<br>
> 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">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=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>
>> _______________________________________________<br>
>> pgrouting-dev mailing list<br>
>> <a href="mailto:pgrouting-dev@lists.osgeo.org">pgrouting-dev@lists.osgeo.org</a><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Georepublic UG & Georepublic Japan<br>
> eMail: <a href="mailto:daniel.kastl@georepublic.de">daniel.kastl@georepublic.de</a><br>
> Web: <a href="http://georepublic.de" target="_blank">http://georepublic.de</a><br>
><br>
> _______________________________________________<br>
> pgrouting-dev mailing list<br>
> <a href="mailto:pgrouting-dev@lists.osgeo.org">pgrouting-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-dev</a><br>
><br>
_______________________________________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org">pgrouting-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" target="_blank">http://lists.osgeo.org/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>