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)
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
> 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
I also have quite a few comments on the report, which I'll try and
share sometime today.
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.
> 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.
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
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.