[pgrouting-users] Pgrouting

Stephen Woodbridge woodbri at swoodbridge.com
Sat Nov 24 20:32:31 PST 2012


Hi Tom,

I'm putting this on the mailing list. You are asking good questions and 
I think others can benefit from my responses. Also, there are some devs 
that might be on the list that have more information on your exact 
problem, which is multi-modal route planning. We have had some Google 
Summer of Code (GSoC) projects that implement exactly these issues. The 
down side of these projects is at there is less documentation, examples 
and general experience to help.

http://www.google-melange.com/gsoc/project/google/gsoc2011/justjkk/16001

http://www.google-melange.com/gsoc/project/google/gsoc2011/jaymahadeokar/7001


More inline below ...

On 11/24/2012 3:23 PM, Tom Kessler wrote:
> Hi Stephen,
>
> Thanks.  This is helpful info.   Apart from getting basic implementation
> going, the issue I'm having is properly abstracting proper application
> in the case of public or private transit routes overlaid across road
> networks.
>
> Here's what's clear:
>
> - You have a data set, as OSM or Shapfile data; that needs to be
> converted to a pgrouting format of polylines.

I use shp2pgsql for this.

> - To those polylines, you have to add nodal topology data.

There is a stored procedure that does this.

> - At that point, you have a routable network, usually of roads.
>   Querying a route is going to return you a series of segments, which
> can be expressed as driving directions, etc.

Right.

> Here's what's not clear.
>
> - We have a series of transit routes, which overlay over roads.

 From a routing perspective there are a couple a few ways to think about 
these problems. What the GSoC projects do is allow you to model the 
transit routes as more links in the network. The tricky part is the 
transit networks typically work on a schedule so you have to add some 
smarts to the network and the solver. To work with schedules, you need 
to specify a start time and what networks are allowed. You might have a 
list a travel modes like, car, walking, bicycle, train, etc and then as 
you traverse the network in the solver you have to keep track of the 
time as you move. When you get to a station you have compare the arrival 
time + some wait time, like for buying tickets, getting to the platform 
parking your car or bicycle, etc, with the departure time for the train 
or bus as you continue on the leg of the journey.

> - To find a transit route, we have to derive a routable network as well.
> -  Which means what?  Expressing the  transit polylines, stations, and
> crossings into a routable network.

yup exactly as I explained above. You can add more or less complexity to 
your model. The easiest was to model this is to have a edge the 
represents the station, and when you get to that edge it calls a 
function to calculate the cost(s) as above. So for example the station 
cost to get on train A can be different from the cost of the station to 
get onto train B because they have different departure times.

> - The public routes don't go everywhere, so maybe a trip planner starts
> with an origin on the street map, routes to the nearest public transit
> point, then on the transit network and back to the street map network?

Yes, the two networks are linked by the stations or bus stops and each 
one needs a schedule. You might need to include the additional 
information in the start time like day or date, week day, weekend, of 
holiday so you can select the correct schedule and for route the cross 
24 hr clock deals with the day changing.

> - Or maybe the public transit routes are expressed as attributes of the
> nodal street map segments?

You could do this if you want to build a very simplistic model to start 
with. You might want to just start with this first to see it working. 
Just take the transit routes and add them to the network just as if they 
were road segments but ONLY connect them to the road network at the 
stations or stops.

> This is what I'm struggling with.  Your driving direction code might be
> useful to us - likely not much difference between driving directions and
> other types of transit directions.

Adding code to the driving directions to handle explicating transit 
directions should not be that hard. I have a concept of a maneuver and 
we could just extend that to include maneuvers like:

1. At station ... take bus/train ... to ....
2. At station ... exit at stop ...
3. etc

Hope this helps,
   -Steve

> Your thoughts?
>
> regards,
>
> Tom
>
>
>
>
>
>
>
> On Sat, Nov 24, 2012 at 10:34 AM, Stephen Woodbridge
> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.com>> wrote:
>
>     On 11/23/2012 9:59 PM, Stephen Woodbridge wrote:
>
>         On 11/23/2012 7:32 PM, Tom Kessler wrote:
>
>             Hi Steven,
>
>             I saw your website referenced from pgrouting site.   I'm
>             looking for a
>             little expert advice on pgrouting.   For many years, I've
>             been working
>             on travel planning and dynamic ridesharing in
>             postgis/postgres for
>             Latin America.   Our latest website is rutafacil.info
>             <http://rutafacil.info>
>             <http://rutafacil.info>.
>
>             The route algorithm is we developed in pure pgsql - but based in
>             pgrouting would be better.
>
>             We have not been able to get osm2pgsql running properly, and
>             we're
>             having some issuings properly conceptualizing how we ought to
>             integrate pgrouting into our site.   Currently we good
>             capture of
>             public transit routes and stops.   We can certainly get
>             street map
>             data.   But its just not so clear yet how we should process
>             that and
>             integrate pgroute.  Ideally we'd have php and pgsql code to
>             do that.
>
>             I'm think an hour on the phone with you might be very
>             helpful, and
>             maybe we could afford some consulting.  I pay for rutafacil
>             out of my
>             own pocket with the hope of someday having revenue!!
>
>             best regards,
>
>             Tom Kessler
>
>         Hi Tom,
>
>         Thank you for your inquiry. I'm not sure how much help I will be
>         as I
>         typically do not use OSM data. I normally use shapefile data. I have
>         played with OSM data on a few occasions, but I find the lack of
>         structure and standardization of attributes very frustrating to work
>         with. That said, I do understand the pgRouting side of things
>         pretty well.
>
>         You might want to look at this:
>         ftp://ftp.remotesensing.org/__pgrouting/forum/pgrouting.__postlbs.org/browser/tools/__osm2pgrouting/tags/release-0.__html
>         <ftp://ftp.remotesensing.org/pgrouting/forum/pgrouting.postlbs.org/browser/tools/osm2pgrouting/tags/release-0.html>
>
>     You should probably read this page first:
>     http://pgrouting.org/docs/__howto/osmdata.html
>     <http://pgrouting.org/docs/howto/osmdata.html>
>
>
>         It might work better for you than osm2psgl. I would also get on the
>         pgrouting mail list as I answer questions there but there are other
>         people that can provide advice also and some of them work with
>         OSM data.
>
>         For the big picture on building a site that works with pgrouting
>         look at:
>         http://gis.imaptools.com/__routing/leaddog/?zoom=11&lat=__33.86651&lon=35.51184&layers=__B0TTTF&start=35.493583%2033.__826664&stop=35.565174%2033.__864285&method=STS&lang=eng
>         <http://gis.imaptools.com/routing/leaddog/?zoom=11&lat=33.86651&lon=35.51184&layers=B0TTTF&start=35.493583%2033.826664&stop=35.565174%2033.864285&method=STS&lang=eng>
>
>         This is a pretty simple page with just the basics. You can make it
>         fancier like adding drag and drop for the start and end markers. The
>         connection between pgrouting running in the database is a
>         trivial php
>         ajax script that you pass the input args to and it connects to the
>         database and issues some queries, then formats the results as
>         xml and
>         returns to the html where they are parsed into the table and the
>         route
>         is extracted into a feature that is added to the OpenLayers map.
>
>         Oh and a heads up, pgrouting does not generate driving instructions.
>         What you see on my page is done by a lot of additional code that
>         I wrote
>         and license as part of my consulting practice. I have discussed
>         on the
>         list how that works so you can search for "driving directions"
>
>         Print out the page source, and run it in firebug to see the ajax
>         requests and responses.
>
>         If you want to chat or talk, you can contact me on skype:
>         stephen.woodbridge
>
>         Best regards,
>             -Steve
>
>
>



More information about the Pgrouting-users mailing list