Park and Ride

As of version 1.0 OpenTripPlanner will contain support for drive-to-transit trips, where the user would like to leave a vehicle at a park and ride facility before public transport is taken.

Park-and-ride areas are created from OpenStreetMap nodes and areas under the following conditions:

1. The park_ride tag has any value other than "no" (preferred), or
2. The amenity tag has the value "parking" and the parking tag has a value containing the text "park_and_ride" (deprecated OSM convention).

For more information on OpenStreetMap tags for park-and-ride see here. As OSM tagging practices/conventions change OTP can be adapted to reflect alternative scenarios.

A park-and-ride trip is made by setting the mode query paramter to "WALK,CAR". This is analogous to the use of "WALK,BICYCLE" for use of a rented bicycle which must be parked before using transit. Special mode combinations are not an ideal way to indicate a need for parking before using transit, but the API extension to express these cases more clearly is not yet finalized.

---

Additional details:

• P+R sources are based on static OSM data. By definition P+R are static structures.

• A drivable entrance and a walkable exit to the P+R must be defined, and both the entrance and exit must share a node with the same P+R area way.

• There is no support for P+R nodes, but usually this is not a problem as P+Rs are almost always defined as areas. Sometimes subterranean P+Rs are defined using only entrance and exit nodes. These must be covnerted to areas with appropriate levels. Keeping the entrance/exit nodes in place is harmless.

• There is also no support for P+Rs defined using "relations" between areas. The case is rare though (we have never seen any), as relations are only needed if you have a P+R with holes or fragments, which would be rather unusual. Tagging the outermost area ways should be sufficient.

• When building the graph with P+R support, the number of P+R should be logged during the building process. Inaccessible P+Rs are also logged as warnings.

• P+R support is enabled/disabled using the staticParkAndRide flag of the OpenStreetMapGraphBuilderImpl class. It is enabled by default.

• Parking/walking cost is based on the distance between the entrance location and the geometric center of the P+R area, as we do not know in advance where the car will be parked. This distance is weighted with a constant "obstruction factor" taking into account the fact that you have to drive alongside alleys, not smashing through other cars to go directly to some empty spot. We do not take into account in this computation the number of levels for multi-storey parking lots, which can be defined in OSM tags; this support would be straightforward to add.

• The results depend on proper speed for car segments. Usually this is where we lack detail. If you assume car speeds are too fast you will end-up parking to the nearest P+R to your destination and walking from there. This is not what you usually want, since the aim of P+R is favoring transit over driving in urban areas. We solved this in our early prototype using a constant large coefficient for weighting the driving portion, as we were lacking precise car speeds. Since that time OTP car support has improved so this may be less necessary. But this weighting is usually harmless as it only impacts the generalized cost of the car vs. other modes, not timings or different alternatives within the same mode.

---

Note that many park and ride facilities are not properly tagged in OSM. The most common errors, in decreasing order of severity, are:

• P+R area way does not exist at all
• P+R area is not tagged as P+R (perhaps as a normal parking lot rather than P+R)
• P+R lacks car or pedestrian access ways
• P+R has access ways, but they do not share nodes with the P+R area.