Research report on OpenTripPlanner, OpenStreetMap, GTFS now available
Sean Barbeau
Our research group recently wrapped up a research project studying the
current state of the art in open-source software and open data in
multimodal trip planning. Luckily for us, OpenTripPlanner came along
around the same time that the project started, so we spent much of our
time looking at OTP in the context of OpenStreetMap and GTFS data,
including creating our own OTP instance to work with (http://
opentripplanner.usf.edu/).
The report discusses many different issues, including some pedestrian
intersection improvements we think are important starting on page 47
(PDF page 67):
http://www.nctr.usf.edu/2011/05/enabling-cost-effective-multimodal-trip-planners-through-open-transit-data-2/
We also created an OpenTripPlanner wiki page on the OpenStreetMap site
to help bridge the two communities:
http://wiki.openstreetmap.org/wiki/OpenTripPlanner
Please feel free to edit/improve at will, as this is a starting
version that we hope to improve over time.
We are following up the project with several proposals to improve OTP
documentation and support a local organization in moving beyond this
feasibility study to full implementation. Our center is grant-funded,
so although we will continue to follow progress in our spare time,
significant follow-up work will depend on our ability to get proposals
funded.
Please feel free to contact me if you have any questions about the
project or report. And, thanks to all of you involved with the
project for your hard work!
Thanks,
Sean
Sean J. Barbeau, M.S. Comp.Sci.
Research Associate - Location-Aware Information Systems
Center for Urban Transportation Research
University of South Florida
813.974.7208
bar...@cutr.usf.edu
Smartrip
David Turner
Here are some random notes:
I actually think routing based on shade and lighting would be awesome.
We could trivially do that if the data were in OSM -- it would be about
ten lines of code.
OTP actually supports the GTFS bicycle extension and two versions of the
wheelchair accessibility data.
I'm actually a bit confused by how the sidewalk and crossing network
works in OSM. I would love to support a full sidewalk model where it's
available, and I don't think it would be that hard. The only major
model change is representing which side of the street the user is on.
Could you link me to a section of OSM which has this tagging?
How should traffic signals be used for routing? Do they indicate that
an intersection is a good place to cross, or that the streets are busy
streets and thus should be avoided?
(Also, I updated that OSM wiki page a bit -- thanks for putting it up; I
hope it will attract new users and developers to OTP)
David Turner
all the thought you all have put into OTP and multi-modal routing.
Reading this paper is really inspiring!
Josh Doe
> I'm actually a bit confused by how the sidewalk and crossing network
> works in OSM. I would love to support a full sidewalk model where it's
> available, and I don't think it would be that hard. The only major
> model change is representing which side of the street the user is on.
> Could you link me to a section of OSM which has this tagging?
There are two ways sidewalks are represented in OSM. One which I
prefer to use (at least in rural/suburban areas) is to create separate
ways for the sidewalks. This has the advantage that it's physically
correct, it's easy to add details about barriers/curbs/etc, however
it's complicated to associate the sidewalk with a street (need to use
a relation, or do some parallel-way analysis). The other is to add to
the road a tag sidewalk=left/right/both/none. This is simpler to
implement but not as robust. I tend to think this is a more
appropriate solution for cities which typically have sidewalks along
most streets and usually have curb cuts at crossings. You can read
more here:
http://wiki.openstreetmap.org/wiki/Sidewalk
> How should traffic signals be used for routing? Do they indicate that
> an intersection is a good place to cross, or that the streets are busy
> streets and thus should be avoided?
I think traffic signals should be weighted to provide a safer, yet
longer route. It should be up to the user how they want to weight
safety, time, and distance. For a origin/destination near me, all
routers that I've tried always send me along a residential road
crossing a secondary road that's 40MPH, which is quite unsafe, rather
than an extra hundred feet or so to a signalized intersection. I'd
much rather take that safer route, especially if I'm walking with the
children.
I also have quite a few comments on the report, which I'll try and
share sometime today.
Great work!
-Josh
Sean Barbeau
generating discussion. Please keep the comments coming! We view the
report as a starting point for discussion, not an authoritative
mandate for what is correct, so we welcome any feedback/constructive
criticism for any included material.
> > I'm actually a bit confused by how the sidewalk and crossing network
> > works in OSM. I would love to support a full sidewalk model where it's
> > available, and I don't think it would be that hard. The only major
> > model change is representing which side of the street the user is on.
> > Could you link me to a section of OSM which has this tagging?
intersection tagging methodology, including the intersection of Fowler
and Leroy Collins Boulevard (main entrance of USF):
http://www.openstreetmap.org/?lat=28.054466&lon=-82.412984&zoom=18&layers=M
Its important to note that the satellite imagery at this location is
actually outdated, so the coded data represents the current
infrastructure, not the infrastructure visible in the imagery.
> There are two ways sidewalks are represented in OSM. One which I
> prefer to use (at least in rural/suburban areas) is to create separate
> ways for the sidewalks.
our general preference as well since it allows more detailed modeling
of intersections, and was part of a recently approved (April 2011)
update to these coding conventions.
If you look at the main entrance of USF example, there are separate
ways representing the sidewalk/crosswalk that cross the road ways.
This sidewalk way is coded with the values "highway=footway" (the
normal sidewalk tag) and "footway=crossing" to indicate that it
crosses a road. At the intersection of the sidewalk way and road way,
there is a node. This node is coded with the tag "highway=crossing"
to indicate the crosswalk, as well as the attributes for the crossing,
including tags such as "crossing=pedestrian_signals", "marking=zebra",
"wheelchair=yes".
The main obstacle we see to OTP routing using this OSM intersection
coding system is that the important crossing information is coded on
the node, and OTP uses information from the edges (i.e. ways) to make
routing decisions.
So, we propose that in OTP Graph Builder software we should look for
ways that are coded with "footway=crossing," and then copy the
attribute tags off the intersecting node (the node coded with
"highway=crossing") to the edge representing the "footway=crossing"
way. This should put all the "crossing=pedestrian_signals",
"marking=zebra", etc. information onto the edge crossing a street so
it can be used in pedestrian routing.
As I say above, though, this is just a starting point, so we welcome
alternate takes on this.
> I think traffic signals should be weighted to provide a safer, yet
> longer route.
categorizations of intersection infrastructure, from best to worst:
1) traffic and pedestrian signalization (i.e., walk/don't walk
signals)
2) traffic light signalization, but no pedestrian signalization
3) no traffic light or pedestrian signalization
For example, at USF there is a traffic signal at an intersection with
a pedestrian island that does not have a pedestrian signal. I've
actually almost gotten hit here before leaving the pedestrian island
(at my own fault), since it can be difficult to judge the state of the
light cycle when you don't have the visible pedestrian signal telling
you "walk/don't walk." So, when routing, I think we should prefer
crossing streets at #1 first, then at #2, then at #3.
Ed Hillsman is our in-house OpenStreetMap expert, and he says that the
pedestrian signal coding ("crossing=pedestrian_signals") actually
isn't in the official OSM tags, so we need to propose this tag and
methodology in OSM. The normal traffic signal tag is
"crossing=traffic_signals". Our current assumption is that if a
crosswalk has a pedestrian signal is also has a traffic signal
(otherwise, how is traffic stopped?), but let us know if you think
there would be any exceptions to this.
Also, Ed can chime in if I got any of this OSM coding wrong :).
> OTP actually supports the GTFS bicycle extension and two versions of the
> wheelchair accessibility data.
> share sometime today.
discussion (including some on the OSM lists) by linking to all of them
at our project page:
http://www.locationaware.usf.edu/ongoing-research/open-transit-data/
I've already posted a link to this discussion thread, and we'll be
adding more shortly. Please keep the discussion going!
David - do you have a better URL for the GTFS bike extension than what
I just added to our website? I couldn't find an exact spec, just the
discussion on the GTFS Changes list.
On Jun 16, 8:28 am, Josh Doe <j...@joshdoe.com> wrote:
Josh Doe
> We've coded certain portions of the USF campus with the updated
> intersection tagging methodology, including the intersection of Fowler
> and Leroy Collins Boulevard (main entrance of USF):
> http://www.openstreetmap.org/?lat=28.054466&lon=-82.412984&zoom=18&layers=M
Excellent! Might I suggest that you look into using kerb=* instead of
sloped_curb=*. Both are proposed features, but I prefer (and have been
using) kerb=* since it uses the British English spelling, and it
(sensibly) allows for other types of kerbs/curbs, such as flush (such
as at a traffic island) and rolled (allowing vehicles to mount). If
you or Ed could add your feedback to those pages, perhaps we could
push one or the other to be approved.
http://wiki.openstreetmap.org/wiki/Proposed_features/kerb
http://wiki.openstreetmap.org/wiki/Proposed_features/sloped_curb
> This coding system ("Proposed features/Sidewalk as separate way") is
> our general preference as well since it allows more detailed modeling
> of intersections, and was part of a recently approved (April 2011)
> update to these coding conventions.
Glad to hear it, as I prefer it myself (I helped with the proposal). I
would appreciate feedback on how to support narrative directions with
this scheme, as that is its greatest drawback. To associate a sidewalk
with a street name requires some sort of ugly parallel way analysis,
or the use of a "street" relation to tie the segments of the street
and sidewalk together. This is obviously something that OTP would need
to handle if it wishes to provide directions like "Follow the sidewalk
along Main Street".
> The main obstacle we see to OTP routing using this OSM intersection
> coding system is that the important crossing information is coded on
> the node, and OTP uses information from the edges (i.e. ways) to make
> routing decisions.
>
> So, we propose that in OTP Graph Builder software we should look for
> ways that are coded with "footway=crossing," and then copy the
> attribute tags off the intersecting node (the node coded with
> "highway=crossing") to the edge representing the "footway=crossing"
> way. This should put all the "crossing=pedestrian_signals",
> "marking=zebra", etc. information onto the edge crossing a street so
> it can be used in pedestrian routing.
Sounds good to me!
> Ed Hillsman is our in-house OpenStreetMap expert, and he says that the
> pedestrian signal coding ("crossing=pedestrian_signals") actually
> isn't in the official OSM tags, so we need to propose this tag and
> methodology in OSM. The normal traffic signal tag is
> "crossing=traffic_signals". Our current assumption is that if a
> crosswalk has a pedestrian signal is also has a traffic signal
> (otherwise, how is traffic stopped?), but let us know if you think
> there would be any exceptions to this.
Yes indeed, I'm sure there are several proposals that can come out of
this report. The pedestrian_signals one should be fairly
straightforward however, as it's only adding a value to an already
existing key, and is well defined.
-Josh
David Turner
> I also agree. I think its important to recognize three different
> categorizations of intersection infrastructure, from best to worst:
> 1) traffic and pedestrian signalization (i.e., walk/don't walk
> signals)
> 2) traffic light signalization, but no pedestrian signalization
> 3) no traffic light or pedestrian signalization
>
> For example, at USF there is a traffic signal at an intersection with
> a pedestrian island that does not have a pedestrian signal. I've
> actually almost gotten hit here before leaving the pedestrian island
> (at my own fault), since it can be difficult to judge the state of the
> light cycle when you don't have the visible pedestrian signal telling
> you "walk/don't walk." So, when routing, I think we should prefer
> crossing streets at #1 first, then at #2, then at #3.
My worry about prioritizing routes with signals is that those are
usually busier roads. On quieter, more residential streets, there are
simply stop signs. At least, that's how it works in Brooklyn NY and
Portland OR.
Of course, if we also had road traffic levels tagged, we could still
prioritize lower traffic roads in general but prefer pedestrian crossing
when busy streets need to be crossed. That would be the optimal case.
I'm going to create a ticket for this, so that we remember it.
> David - do you have a better URL for the GTFS bike extension than what
> I just added to our website? I couldn't find an exact spec, just the
> discussion on the GTFS Changes list.
As I recall, that discussion is what we used -- I don't think there was
a more precise spec than that.
Ed Hillsman
> Thanks Josh, David, and Filip! . . .
> The main obstacle we see to OTP routing using this OSM intersection
> coding system is that the important crossing information is coded on
> the node, and OTP uses information from the edges (i.e. ways) to make
> routing decisions.
information about crossings on the edges (ways), because it is more
intuitive and aligns better with edge-based routing algorithms, which
are most common. However, I checked the OSM Taginfo, and, as we noted
in the report, virtually all of the features tagged with
highway=crossing in OSM were these intersection nodes (and about half
of the exceptions were ways that I had coded around the USF campus). I
did not think we could get consensus to change it and, even if we
could, it would be a real mess to go back and change existing coding.
I think any automated effort would find a lot of unanticipated
exceptions and create havoc.So, the footway=crossing convention is an
excellent "second best" solution.
Ed
Ed Hillsman
On Jun 16, 1:36 pm, Josh Doe <j...@joshdoe.com> wrote:
> Excellent! Might I suggest that you look into using kerb=* instead of
> sloped_curb=*. Both are proposed features, but I prefer (and have been
> using) kerb=* since it uses the British English spelling, and it
> (sensibly) allows for other types of kerbs/curbs, such as flush (such
> as at a traffic island) and rolled (allowing vehicles to mount). If
> you or Ed could add your feedback to those pages, perhaps we could
> push one or the other to be approved.http://wiki.openstreetmap.org/wiki/Proposed_features/kerbhttp://wiki.openstreetmap.org/wiki/Proposed_features/sloped_curb
extended the sloped_curb tagging to handle a few strange situations on
campus, but I've not been happy with it, because of the flush case you
mention (which seems to be becoming increasingly common) and a few
cased where an asphalt ramp has been built out from an existing curb/
kerb into a parking lot, rather than replacing and lowering the curb.
The sloped area is the same but it is in a different place. My guess
is that these were because it was cheaper, but from the looks of them
I wouldn't want to run a wheelchair up them (down them, maybe). I have
some photos and will find one to add to one or the other of these
proposals.
>
> Yes indeed, I'm sure there are several proposals that can come out of
> this report. The pedestrian_signals one should be fairly
> straightforward however, as it's only adding a value to an already
> existing key, and is well defined.
Ed
Sean Barbeau
> usually busier roads. On quieter, more residential streets, there are
> simply stop signs. At least, that's how it works in Brooklyn NY and
> Portland OR.
>
> Of course, if we also had road traffic levels tagged, we could still
> prioritize lower traffic roads in general but prefer pedestrian crossing
> when busy streets need to be crossed. That would be the optimal case.
and I left this out of the priority list. So, I guess this is the
full list of crossings we need to prioritize:
signals)
2) traffic light signalization, but no pedestrian signalization
sign
4) no traffic light or pedestrian signalization, and no stop sign
Also agreed, having some kind of traffic level for roads would be
optimal for providing pedestrian directions at crossings. The
difficultly of crowd-sourcing traditional road traffic metrics is
another item we discuss in the report that we feel needs
improvement.
More broadly, we need better objective metrics to define bike and walk
"level-of-service" (i.e., how "good" an OSM way is for walking or
biking) that can easily be recorded by a casual observer in OSM
without special equipment (e.g., traffic counting equipment) or a
large time commitment. For biking especially, in the trip planner we
also need to be able to translate these easily crowd-sourceable
objective metrics into somewhat subjective judgements for whether a
cyclist would be comfortable riding on a specific road. This
obviously changes based on the cyclist, since based on experience (and
level of insanity ;)) some expert cyclist would be comfortable riding
on high traffic roads where other beginner cyclists would not.
Sean