[pgrouting-dev] redundant core sql functions

[Stephen Woodbridge]

Hi Mario, Daniel,

I think a rationalization of the wrapper is a great idea. I would like 
to see an RFC and comments of what these will look like so that we can 
review and approve them. This is our best changes to come up with a 
simple clean implementation that will work across the widest range of 
algorithms that we know have implemented.

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

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.

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.

Thanks,
   -Steve

On 7/2/2012 3:11 AM, Daniel Kastl 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
> <mailto: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 <mailto:pgrouting-dev at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
>
>
>
> --
> Georepublic UG & Georepublic Japan
> eMail: daniel.kastl at georepublic.de <mailto:daniel.kastl at georepublic.de>
> Web: http://georepublic.de <http://georepublic.de/>
>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>