[pgrouting-dev] redundant core sql functions

[Daniel Kastl]

On Mon, Jul 2, 2012 at 9:41 AM, "Christophe Damour (SIGéal)" <
sigeal at sigeal.com> wrote:

> 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...
>

This is indeed an often requested "feature". But it can be more tricky than
it initially looks like.
There is some example you can start with:
https://github.com/pgRouting/pgrouting-contrib/tree/master/wrapper

For wrappers "shipped" we should define some criteria. As more we have as
more needs to be documented and maintained. Instead a tutorial or a
few recipes to help users to write and modify their own custom wrappers
might make more sense.

Daniel








>
> 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<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<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<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<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>



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