[pgrouting-dev] redundant core sql functions
"Christophe Damour (SIGéal)"
sigeal at sigeal.com
Mon Jul 2 00:41:23 PDT 2012
Hi,
I totally agree with both of you, Daniel and Mario.
I too was a bit confused by existing wrappers when I began to use pgrouting.
Wrappers should add extra functionalities.
A function that accept source and target x/y would indeed be usefull,
especially if it can return the first and last edge cut at the actual
projection of source and target x/y. I will need such a function soon,
so I will have to work on it...
Any hints appreciated.
--
Christophe
Le 02/07/2012 09:28, Mario Basa a écrit :
> Daniel,
>
> I agree. Right now it really is quite confusing which function to use,
> and the description of each function is not also very helpful.
>
> I am curious though why is it that there is no sp function that
> accepts source_x,source_y and target_x,target_y parameters similar to
> that of driving_distance. This I think, will be very useful.
>
> Mario.
>
>
> On Mon, Jul 2, 2012 at 4:11 PM, Daniel Kastl <daniel at georepublic.de> wrote:
>> Hi Mario,
>>
>> In my opinion I would drop functions like the one you mentioned and reduce
>> the number of wrappers as much as possible.
>>
>> I think a good and useful wrapper function is one, that selects a BBOX
>> containing start and end point and returns records with geometries.
>> Then everyone can modify it as needed. I don't think we should simplify
>> those basic wrappers and make assumptions like naming the cost column
>> "length" or so.
>>
>> What do you think?
>>
>> Daniel
>>
>>
>>
>>
>> On Mon, Jul 2, 2012 at 9:02 AM, Mario Basa <mario.basa at gmail.com> wrote:
>>> Hello,
>>>
>>> The core wrapper functions have
>>>
>>> dijkstra_sp_delta_directed
>>> astar_sp_delta_directed
>>>
>>> with "length" hard coded as cost for some reason.
>>>
>>> While astar_sp_delta_cc has a cost column parameter, but all it does
>>> is call astar_sp_delta_cc_directed with
>>> reverse_cost=false,directed=false.
>>>
>>> There is also no dijkstra_sp_delta_cc with a cost column parameter, so
>>> a user has to rename the column containing the cost value to "length"
>>> to use this clipping function. Etc....
>>>
>>> Personally I am getting confused with all these functions and would
>>> like to just trim it down to dijkstra_sp_delta and astar_sp_delta with
>>> a cost column parameter along with reverse_cost and directed
>>> parameters.
>>>
>>> Opinions?
>>>
>>> Mario.
>>> _______________________________________________
>>> pgrouting-dev mailing list
>>> pgrouting-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>
>>
>>
>> --
>> Georepublic UG & Georepublic Japan
>> eMail: daniel.kastl at georepublic.de
>> Web: http://georepublic.de
>>
>> _______________________________________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
More information about the pgrouting-dev
mailing list