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@swoodbridge.com <mailto:woodbri@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.woodbridgeBest regards,
-Steve