[pgrouting-dev] redundant core sql functions

["Christophe Damour (SIGéal)"]

Thanks for the hints Mario and Daniel,

I'll have look and let you know as soon as I can put my hands on it.

--
Christophe


Le 02/07/2012 10:09, Daniel Kastl a écrit :
>
>
> On Mon, Jul 2, 2012 at 9:41 AM, "Christophe Damour (SIGéal)" 
> <sigeal at sigeal.com <mailto: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 <mailto: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 <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
>
>             _______________________________________________
>             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
>
>         _______________________________________________
>         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
>
>
>     _______________________________________________
>     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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20120702/907c0a8b/attachment.html>