park and ride in OTP?

[patge...@gmail.com]

Hello
I am working for a project in the Marseilles area where we have deployed OTP analyst and work on accessibility indicators.

In the basic OTP configuration, the transit route planner computes walk+ride and optionnaly bike+ride trips, but not car+transit trips (not necessarily using dedicated parking lots, but also on-street or private parking).
As this is quite useful in general for comparing accessibilities with the Analyst, this functionality may have been implemented already but is may be not yet documented in the Master version
Does any one know how to configure OTP files or data so as to compute P+R routes, or of any extension for doing this?

Searching in this OTP Users group, I have found a post descring the SmartCampus in Trento Italy https://github.com/smartcampuslab where the P+R functionality seems to have been implemented, but it is quite complicated to understand how to use it in OTP as it is part of a larger system http://dev.smartcampuslab.eu/doku.php?id=core:mobilityservice.

Thanks in advance
Best regards
Patrick Gendre
Cerema
Aix-en-Provence FR

[Jorden Verwer]

Park and ride support was only merged into OTP master last week, so it's a very recent addition (even though the code itself is somewhat older). Laurent Grégoire of Mecatran (the company that wrote the code) is probably the person who can explain it to you best. I believe he also reads this mailing list, so he'll probably reply in a couple of days or so.

If you already want to try it yourself, check out the latest version of the master branch, switch to the OpenLayers client and give it a try. It's not going to work without OSM data, though, but you can just run it and see what happens.

Regards,

Jorden

Op donderdag 20 februari 2014 11:40:55 UTC+1 schreef patge...@gmail.com:

[Laurent Gregoire]

Hi Patrick,

Sorry for the delay in my answer, I was at a conference all day long
yesterday.

Indeed as Jorden said the P+R development Mecatran made (based on an
older proof of concept) has been merged recently and should be available
in the master branch.

Just a few notes on the implementation:
- P+R sources are based on static OSM data (it rely on a quite precise
geometry and OSM is the easiest way to define it). By definition P+R are
static structures.
- A drivable entrance and a walkable exit has to be defined, and
*connected with a common node* to the way area defined as the P+R.
- There is no support for P+R nodes, but usually this is not a problem
as a P+R is almost always defined as an area with a surface. Sometimes
subterranean P+R are defined using only entrance/exit nodes: they have
to be translated to areas with appropriate levels. Keeping entrance/exit
nodes is harmless.
- There is also no support for P+R defined as "relations" between areas.
The case is rare though (never seen any), relation are needed only if
you have holed P+R, which is rather unusual. Anyway only the outer
polyline is needed so tagging the appropriate outer(s) way area(s)
should be enough.
- When building the graph with P+R support, the number of P+R should be
printed during the building process, unaccessible P+R are printed as
warnings.
- P+R support is enabled/disabled using the staticParkAndRide flag of
the OpenStreetMapGraphBuilderImpl class, it is enabled by default so
nothing have to be done in particular.
- Parking/walking cost is based on simple distance between entrance
location and geometric center of the P+R area location, as you do not
know in advance where your car will be parked. This distance is weighted
with a constant "convolution factor" taking into account the fact that
you have to drive alongside alleys --and not smashing 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 parkings, which can be
defined in OSM tags; this support would be straightforward to add.
- The results rely on proper weighting for car segments. Usually this is
where we lack details: if you assume car speed to be too fast you will
end-up parking to the nearest P+R of your destination and walking from
there; but this is not what you usually want, usually 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 driving
portion, as we were missing a very precise car speed estimation; since
then the car support has improved so this may be less necessary. But
this weighting is usually harmless as it only impact the generalized
cost of car vs other modes, neither the timings nor the comparisons
between same mode.

Maybe Jorden can give some feedback on the last point for the NL
project, on the impact of estimated car speed on getting reliable P+R
results.

Attached some teaser screenshots to see what it looks like.

HTH,

--
Laurent GRÉGOIRE
laurent....@gmail.com

On 21/02/14 10:08, Jorden Verwer wrote:
> Park and ride support was only merged into OTP master last week, so it's a
> very recent addition (even though the code itself is somewhat older).
> Laurent Grégoire of Mecatran (the company that wrote the code) is probably
> the person who can explain it to you best. I believe he also reads this
> mailing list, so he'll probably reply in a couple of days or so.
>
> If you already want to try it yourself, check out the latest version of the
> master branch, switch to the OpenLayers client and give it a try. It's not
> going to work without OSM data, though, but you can just run it and see
> what happens.

> Op donderdag 20 februari 2014 11:40:55 UTC+1 schreef patge...@gmail.com:

[Laurent Grégoire]

Hi again Patrick,

> Op donderdag 20 februari 2014 11:40:55 UTC+1 schreef patge...@gmail.com:

>> In the basic OTP configuration, the transit route planner computes
>> walk+ride and optionnaly bike+ride trips, but not car+transit trips (not
>> necessarily using dedicated parking lots, but also on-street or private
>> parking).

Just a quick note, as in your message you said on-street/private parking: the P+R implementation in it's present state assume dedicated P+R spots where the mode change occurs (walk>car). Even though theorically you can add multiple mode change locations (one for each parking spot in a city), I could see two issues:

1) Possible negative impact in term of performance. Even though normally most of the new mode changes would create states that would be "dominated" by other ones, so the total number of states would not increase that much, only the number of edges in the graph would grow significantly,

2) Fiability of results. You would need a quite precise database of parking spot location, with availability data, otherwise you would easily end-up with the best itinerary making you park nearby your destination, in a crowded city center at peak hours where you have absolutely no chance of finding an empty spot... Even though some weighting could be added (average or mean time to find a place per zone per hour) to mitigate this, but this again would rely on statistical data which could be hard to get (and reliably map). 

HTH,

--Laurent

[Laser Mark]

Hi

is it possible to get a list of park&ride nodes in a router? I'm using 0.11 version.

Thanks

Manuela

[Marko Burjek]

Hi

I think it isn't possible to get list of park&ride nodes in a router.

Based on https://groups.google.com/forum/#!topic/opentripplanner-dev/JkQe8rTx378 and https://github.com/opentripplanner/OpenTripPlanner/wiki/Park-and-Ride my guess is that Park & Ride is work in progress. (It works but it is not so polished yet).

You can add a bug to a bugtracker if you have Github account for missing park&ride nodes. I can add it if you don't have it.

You can get park & ride nodes with a help of XAPI which would get all Park & ride nodes and areas:

<!--
This has been generated by the overpass-turbo wizard.
The original search was:
“park_ride!=no and amenity=parking”
-->
<osm-script output="json" timeout="25">
  <!-- gather results -->
  <union>
    <!-- The park_ride tag has any value other than "no" (preferred), -->
    <query type="node">
      <has-kv k="park_ride" modv="not" v="no"/>
      <has-kv k="park_ride"/>
      <bbox-query {{bbox}}/>
    </query>
    <query type="way">
      <has-kv k="park_ride" modv="not" v="no"/>
      <has-kv k="park_ride"/>
      <bbox-query {{bbox}}/>
    </query>

   
    <!-- The amenity tag has the value "parking" and the parking tag has a value containing the text "park_and_ride" (deprecated OSM convention). -->
    <query type="node">
      <has-kv k="parking" v="park_and_ride"/>
      <has-kv k="amenity" v="parking"/>
      <bbox-query {{bbox}}/>
    </query>
    <query type="way">
      <has-kv k="parking" v="park_and_ride"/>
      <has-kv k="amenity" v="parking"/>
      <bbox-query {{bbox}}/>
    </query>
  </union>
  <!-- print results -->
  <print mode="body"/>
  <recurse type="down"/>
  <print mode="skeleton" order="quadtile"/>
</osm-script>

You can copy & paste this to http://overpass-turbo.eu/. Move a map to where you want to get park and nodes and press run. Be careful that you aren't selecting to much data. But park & rides are usually rare.

You can then export data as GeoJSON, JSON, GPX, KML... Or even export query as normal overpass query which you can use from other programs or command line. But it should not be used for every request. It is meant to be called as frequently as you update your map. (Weekly or monthly). More about overpass api:
http://wiki.openstreetmap.org/wiki/Overpass_API

"Both servers have a total capacity of about 1.000.000 requests per day. You can safely assume that you don't disturb other users when you do less than 10.000 queries per day or download less than 5 GB data per day."

I hope that helps.

--
You received this message because you are subscribed to the Google Groups "OpenTripPlanner Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opentripplanner-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Laser Mark]

Thanks for the answer, I'll try with XAPI as you suggest.

At the moment I don't have a Github account, could you add the bug for me?

Thanks so much!

Manuela

[Laurent Gregoire]

Hi Manuela,

On 22/05/14 14:31, Laser Mark wrote:
> is it possible to get a list of park&ride nodes in a router? I'm using 0.11
> version.

Currently it's not possible through a web-service, as there is none for
P+R "stations". But in the code itself you can easily get a list of all
park and ride vertices by running this kind of code on a Graph object:

for (ParkAndRideVertex prv : IterableLibrary.filter(
graph.getVertices(), ParkAndRideVertex.class)) {
System.out.println(String.format("%s: %f,%f",
prv.getName(), prv.getX(), prv.getY());
... etc ...
}

There is currently no P+R station object (unlike what we have for bike
rental for example), as P+R do not use for the time being any real-time
information.

HTH,

--Laurent