[pgrouting-dev] How many people use the wrapper functions?
Stephen Woodbridge
woodbri at swoodbridge.com
Mon May 13 07:48:55 PDT 2013
On 5/13/2013 6:17 AM, Marco Quaggiotto wrote:
> Hi everybody,
> thank you very much for the work you are doing with pgrouting. I can't
> wait for the upcoming 2.0.
>
> My experience with the wrapper functions is fairly identical to Worth Lutz:
> I'm also using one of the 'smart' wrapper functions that enable edge to
> edge with the A* algorithm. I also chose just because the wrapper let me
> choose a point and it split the nearest edge for routing. I heavily
> modified the wrapper to provide all the fields I need from the edges
> table, to join it with other tables, to return the edges in the correct
> order and to reverse the two-way edges that were used in the opposite
> direction.
> I also thank you for the suggestion to look into TRSP, I've been wanting
> to reevaluate the different algorithms once the GSOC get merged (if they
> will), and TRSP seems like a good match, even if I don't actually use
> turn restrictions. (OT: Any idea on the performance in relation to
> bidirectional A* and two_q?)
This code is now available in the release branch I would be interesting
to get some feedback on the relative performance of the various
algorithms. I have not integrated two_q, because while it worked fine,
it did not improve performance over the existing algorithms. I would be
happy to have someone redo this and any other tests and report back on
their findings.
When we developed trsp, I compared it to dijkstra, astar, and shooting
star and for point to point routes they fell into the following
performance ratings:
1. astar
2. trsp
3. dijkstra
4. shootingstar
The first three were all very close together and shootingstar was about
5x slower.
This was without using turn restrictions. But you should also know that
of the cost to generate a route, over 50% of the time in most cases is
related to just loading the edges and building a graph. The solving of
the graph is fast in most cases.
> I also learned what I know of PL/pgSQL by modifying the wrappers and I
> would have had a really hard time implementing the 'edge splitting' on
> my own. So I'm really grateful I found the wrappers. On the other hand
> the wrapper I used wasn't even included in pgrouting, so I guess we'd be
> safe to have them outside the distribution, either in the docs or as an
> external download.
Daniel and I have discussed adding a contrib directory, but then we get
a lot of stuff, that we don't know if it work with the current release.
I think we would be more inclined to have a wiki page that links to 3rd
party github projects or have a tips and tricks wiki page. The ideal
situation is that we link to a page the you maintain because that
de-clutters the pgrouting maintained pages and files.
> On the other hand it would be great to have some solutions for the
> fairly common request to have the result of the routing returned with a
> 'order_id' to be able to join it easily without losing order information
> (see
> http://lists.osgeo.org/pipermail/pgrouting-dev/2013-May/000924.html) and
> to reverse the edges that have been visited in reverse (to be able to
> draw them, etc.). I don't know where this fits best, if in a basic
> wrapper to be customized, or in the core functions themselves.
Yeah, Daniel raised this to me also. It can be done and it is not had to
do it is just a lot of work because:
1. all the C api code needs a minor change
2. all the types, and C wrappers need to be updated
3. all the docs need to be updated
4. all the test results need to be updated
So basically I have to touch 90% of the files. That said, I am still
thinking about potentially doing this and abstracting our types. I turns
out that we only have two major types:
seq | id1 | id2 | cost
seq | id1 | id2 | geom
This would greatly simplify things and it would be up to the algorithm
to decide what is put into id1 and id2, these could be node_id or
edge_id or a mix.
So I could make this change and add the seq number all at the same time.
I'll see if I can work this in, but no promises.
Thank you for your feedback.
-Steve
> Thanks again for you work.
>
> Marco Quaggiotto (bikedistrict.org <http://bikedistrict.org>)
>
>
>
>
> On Sun, May 12, 2013 at 3:41 PM, Stephen Woodbridge
> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.com>> wrote:
>
> Worth,
>
> Thanks, this is good to know and validates our thoughts on the need
> for a chapter in the doc on how to write wrapper functions.
>
> I write a lot code in plpgsql for the same reasons. It also tends to
> be much faster to process stuff in the database. I write trivial
> 10-20 lines PHP scripts the do nothing more than:
>
> 1. take user input
> 2. connect to the database
> 3. issue a query to a stored procedure
> 4. format the results as XML or JSON
>
> to then access these functions from web clients and other client
> scripts and programs.
>
> We actually will be adding some new plpgsql function as part of 2.0
> for example you might find these interesting:
>
> pgr_analyzeGraph - analyze a topology and mark dead ends
> pgr_analyzeOneway - analyze a topology and look for impossible oneways
> pgr_nodeNetwork - utility that will node all intersections
>
> Those can be useful determining issues with a road network that
> might cause problems when routing and nodeNetwork is a tool to
> potentally solve one class of problem where the road segments are
> not split at intersections.
>
> pgr_isColumnInTable - utility to see if a column exists in a table
> pgr_isColumnIndexed - utility to see if a column is indexed
>
> And I'm sure there will be a few others as the release progresses.
>
> Thanks,
> -Steve
>
>
> On 5/12/2013 7:52 AM, Worth Lutz wrote:
>
> Steve,
>
> Thanks for the suggestion on TSRP. I'll look at it as soon as I
> finish my
> current project.
>
> I'll like to add that I learned to write PL/pgSQl from reading
> the pgRouting
> wrappers. I usually write in PHP but find that moving stuff to
> SQL and
> PL/pgSQl can simplify my application. At least once I figure out the
> intricacies of the particular query.
>
> Having the wrapper examples is helpful to someone learning. I
> found that you
> have to figure out how they work though because as you pointed
> out there
> were problems and hard-coded stuff which may cause problems. I
> had a type
> problem when I was figuring out my application.
>
> Simple wrappers as examples to explain to someone how to set up
> their own
> wrapper are helpful.
>
> Worth
>
> -----Original Message-----
> From: pgrouting-dev-bounces at lists.__osgeo.org
> <mailto:pgrouting-dev-bounces at lists.osgeo.org>
> [mailto:pgrouting-dev-bounces at __lists.osgeo.org
> <mailto:pgrouting-dev-bounces at lists.osgeo.org>] On Behalf Of Stephen
> Woodbridge
> Sent: Saturday, May 11, 2013 10:00 PM
> To: pgRouting developers mailing list
> Subject: Re: [pgrouting-dev] How many people use the wrapper
> functions?
>
> Hi Worth,
>
> Thank you for the feedback. It is really important the people
> speak up
> on this because our current thinking is that we will probably
> take most
> of the wrapper functions and dump them into a depreciated
> pgrouting-legacy.sql file that will get copied to the server,
> but not
> installed when you CREATE EXTENSION pgrouting;
>
> I have talked with Daniel about improving the documentation and
> may be
> adding a chapter that explains how to write your own wrapper
> function.
> Our thought is that if we had fewer functions that were better
> documented that it would be easier for people to make sense of
> how to
> use from the beginning.
>
> Regarding shooting star, you should just start using TRSP. In
> fact it
> has the ability to specify an edge and a percentage along the
> edge for
> the start and end locations. It also about 5 times faster than
> shooting
> start.
>
> With regards to the parallel edge problem. We have this in
> dijkstra and
> astar and it is on my list of things to fix before the release.
> I am not
> sure if trsp has this or not, but if you can make a test for it
> I would
> be interested in the results.
>
> Thanks,
> -Steve
>
> On 5/11/2013 7:51 PM, Worth Lutz wrote:
>
> Hi Steve,
>
> I used one of the wrappers, shootingstar_sp_smart I think,
> but had to
>
> modify
>
> it due to problems. I think that it is the one which uses
> shooting star
> which I've since heard doesn't work.
>
> I think that it works for us as all we are using is length
> as cost to find
> the length from a to b. No turn restrictions or anything.
>
> I chose it because the wrapper let me choose a point and it
> split the
> nearest edge and hooked up the point to that edge at the split.
>
> Another reason I chose it was that it worked for the
> following situation:
>
> ----------\
> / \
> / \
> A -----/ B
> |_____________________/
>
>
> Other algorithms would choose the upper edge because that is
> what was
>
> found
>
> first as they tried to go from A to B. I was just learning
> about routing
>
> and
>
> did not want to go figure out how to modify my network to
> split the long
> path where there were multiple paths between nodes.
>
> I've been following your work lately as I will be upgrading
> our situation
>
> to
>
> Postgres 9 and PostGIS 2 at some point. I was waiting for
> you to get
>
> things
>
> settled out before asking which algorithm I should look at
> to replace
> shootingstar.
>
> Thanks for your work on this project.
>
> Worth Lutz
>
>
> -----Original Message-----
> From: pgrouting-dev-bounces at lists.__osgeo.org
> <mailto:pgrouting-dev-bounces at lists.osgeo.org>
> [mailto:pgrouting-dev-bounces at __lists.osgeo.org
> <mailto:pgrouting-dev-bounces at lists.osgeo.org>] On Behalf Of
> Stephen
> Woodbridge
> Sent: Saturday, May 11, 2013 4:21 PM
> To: pgRouting Users List; pgRouting Dev List
> Subject: [pgrouting-dev] How many people use the wrapper
> functions?
>
> Hi all,
>
> Daniel and I have been wondering if people use the wrapper
> function
> versus the core functions directly? Or if you have written
> your own
> wrapper functions? etc.
>
> The core functions are the low level function that directly
> call the
> internal library functions.
>
> The wrapper functions are all the additional plpgsql convenience
> functions that generate more complex SQL queries and then
> call the core
> functions.
>
> I know that I never use the wrapper functions because I
> found them to
> messy and inconsistent and have hard coded values in them,
> etc. So I
> wrote my own high level wrapper functions that made it easy
> for me to
> work with the core functions.
>
> So I thought it would be wise to ask our users what they
> use? and how
> they use pgRouting, so we do not may a decision like "Throw
> out the
> wrapper functions" without some input from the user community.
>
> PLEASE TAKE ACTION and let us know!
>
> Thanks,
> -Steve
> _________________________________________________
> 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
> <http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2013.0.3336 / Virus Database: 3162/6317 - Release
> Date: 05/11/13
>
> _________________________________________________
> 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
> <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
> <http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2013.0.3336 / Virus Database: 3162/6317 - Release Date:
> 05/11/13
>
> _________________________________________________
> 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
> <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
> <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
>
More information about the pgrouting-dev
mailing list