[pgrouting-dev] redundant core sql functions

[Mario Basa]

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

You can find a lot of useful functions in core/sql/matching.sql to
find nearest nodes from a given x,y coordinates.

Most of them will break though for PostGIS 2.0, although I am in the
process of clean them up.

Regards,

Mario.


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