[pgrouting-dev] redundant core sql functions

[Daniel Kastl]

Hi Mario,

The reason why these wrappers are there is, that they were committed to the
SVN repository long time ago.
According to Anton they were there for convenience, probably for some
certain use case ... well, no more comment ;-)

I think so far core functions have a good design, taking an SQL statement
as the first parameter and other parameters later.

PGR_<function name> (<SQL>,<parameter 1>, <parameter 2>, ...)


For wrapper functions, that are part of the library, something similar
would be good, too.
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.

Maybe we could think about a naming convention for this as well, for
example:

PGR_<function name>_bbox (<...>, <the_geom>, <bbox buffer>)



Daniel


On Mon, Jul 2, 2012 at 9:28 AM, Mario Basa <mario.basa at gmail.com> wrote:

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



-- 
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/c59e697f/attachment.html>