[pgrouting-dev] redundant core sql functions

Mario_Basa · July 2, 2012, 7:02am

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.

dkastl · July 2, 2012, 7:11am

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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

Mario_Basa · July 2, 2012, 7:28am

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@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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

Christophe_Damour · July 2, 2012, 7:41am

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@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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

dkastl · July 2, 2012, 7:45am

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_ (,<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__bbox (<…>, <the_geom>, )

Daniel

On Mon, Jul 2, 2012 at 9:28 AM, Mario Basa <mario.basa@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@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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

dkastl · July 2, 2012, 8:09am

On Mon, Jul 2, 2012 at 9:41 AM, “Christophe Damour (SIGéal)” <sigeal@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@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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

Mario_Basa · July 2, 2012, 8:21am

On Mon, Jul 2, 2012 at 4:41 PM, "Christophe Damour (SIGéal)"
<sigeal@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@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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

Christophe_Damour · July 2, 2012, 9:19am

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@sigeal.com <mailto:sigeal@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@georepublic.de <mailto:daniel@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@gmail.com <mailto:mario.basa@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@lists.osgeo.org
                <mailto:pgrouting-dev@lists.osgeo.org>
                http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

            --
            Georepublic UG & Georepublic Japan
            eMail: daniel.kastl@georepublic.de
            <mailto:daniel.kastl@georepublic.de>
            Web: http://georepublic.de

            _______________________________________________
            pgrouting-dev mailing list
            pgrouting-dev@lists.osgeo.org
            <mailto:pgrouting-dev@lists.osgeo.org>
            http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

        _______________________________________________
        pgrouting-dev mailing list
        pgrouting-dev@lists.osgeo.org
        <mailto:pgrouting-dev@lists.osgeo.org>
        http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

    _______________________________________________
    pgrouting-dev mailing list
    pgrouting-dev@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
    http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

Stephen_Woodbridge1 · July 2, 2012, 1:28pm

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@gmail.com
<mailto:mario.basa@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@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
    http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

dkastl · July 2, 2012, 11:52pm

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:

Clipping data to load the minimum required network extent (ie. BBOX clip)
Accept start and end point geometries as input parameters and return a route starting/ending from/at the nearest road segment of the network.
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@gmail.com

mailto:[mario.basa@gmail.com](mailto:mario.basa@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@lists.osgeo.org mailto:[pgrouting-dev@lists.osgeo.org](mailto:pgrouting-dev@lists.osgeo.org)

http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

–
Georepublic UG & Georepublic Japan

eMail: daniel.kastl@georepublic.de mailto:[daniel.kastl@georepublic.de](mailto:daniel.kastl@georepublic.de)
Web: http://georepublic.de <http://georepublic.de/>

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de