[pgrouting-dev] redundant core sql functions

[Daniel Kastl]

Hi Steve,

Very good points! Actually I would even say: let's drop all wrapper
functions for the beginning. Then we concentrate on core functions first.
We better add tests for each algorithm before spending much time with
wrapper functions.

Since many new shortest path will be added, I'm concerned that wrapper
functions may contain lots of duplicate code. I hope there is a smart way
to avoid this.

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.


Hmm, networks usually have geometries. But for Dijkstra lat/lon of start
and end point are actually not important. But I also think that if someone
doesn't need geometry information, just don't use the wrapper function. In
most cases though it will help users to display the route. Especially for
beginners, that might not find it so easy to build more advanced queries.



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

I thought a bit about which are the top requested and convenient "features"
a wrapper could provide:

   1. Clipping data to load the minimum required network extent (ie. BBOX
   clip)
   2. Accept start and end point geometries as input parameters and return
   a route starting/ending from/at the nearest road segment of the network.
   3. Return a route with flipped road segments (if necessary), so they are
   in the right direction, and maybe add angle values, so the result can be
   used for driving directions for example.

With (2) and (3) I would also return geometries.

If someone has more ideas, please share them.

Daniel




>
> 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<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 <mailto:daniel.kastl@**georepublic.de<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<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/20120703/cdbd492f/attachment.html>