Re: [OpenTripPlanner] OTP webapp won't let me change the bike speed or maximum bike distance

[Stefan de Konink]

On Wed, 8 May 2013, jorden...@goabout.com wrote:

> It appears that the ability to change the bike speed or maximum bike
> distance in the OTP webapp hasn't actually been implemented.

Check the Dutch OTP fork, I invested quite some time to make this
configurable.

Stefan

[Thomas Koch]

Stefan, those where commited. I think Jorden is right, there is something weird about bicycles in that patch. It's working for transit+bicycle but not for bicycle only.

https://github.com/StichtingOpenGeo/OpenTripPlanner/commit/6175504f799f00e29ac60605dc879f1924550f50

Is bicycleSpeed a different parameter to the API? For transit+bicycle it modifies the walkSpeed parameter.

Op woensdag 8 mei 2013 23:18:46 UTC+2 schreef Stefan de Konink het volgende:

[Andrew Byrd]

On 05/09/2013 12:13 AM, Thomas Koch wrote:
> Stefan, those where commited. I think Jorden is right, there is
> something weird about bicycles in that patch. It's working for
> transit+bicycle but not for bicycle only.
> https://github.com/StichtingOpenGeo/OpenTripPlanner/commit/6175504f799f00e29ac60605dc879f1924550f50
>
> Is bicycleSpeed a different parameter to the API? For transit+bicycle it
> modifies the walkSpeed parameter.

Yes, there is a separate bikeSpeed parameter. See RoutingResource.java
line 87. This is copied into the RoutingRequest at line 263, and
referenced in RoutingRequest.getSpeed(TraverseMode).

-Andrew

[Jorden Verwer]

Yes, bikeSpeed (not bicycleSpeed) is a different parameter. I had to fix that for GoAbout, because the original implementation would do the exact same thing as the webapp - modify walkSpeed. I had no idea where that came from and apparently neither did the original author, but if the OTP webapp does it the same then maybe the API documentation was incorrect until recently? Or the API itself changed, of course...

 

By the way, I don't think there's a cycling equivalent to maxWalkDistance, unless it's hidden somewhere. Anyway, cycling speed is the real issue here. The similar issue of maximum cycling distance is just something I noticed when I went through the code.

 

I should probably know this, but does opentripplanner.nl run the Dutch fork? I tested it there (as well as locally) before sending my initial email.

 

Jorden

[Thomas Koch]

It runs the Dutch fork, but the particular fix is also in the OpenPlans master branch.

Things that need to be done ->

https://github.com/StichtingOpenGeo/OpenTripPlanner/commit/6175504f799f00e29ac60605dc879f1924550f50#L0R364

Add bicycle speed values to locale files.

https://github.com/StichtingOpenGeo/OpenTripPlanner/commit/6175504f799f00e29ac60605dc879f1924550f50#L2R57

Replicate anything in this patch to implement bikespeed but than with bikeSpeed

https://github.com/StichtingOpenGeo/OpenTripPlanner/commit/6175504f799f00e29ac60605dc879f1924550f50#L3R99

And the logic here needs to be replaced, and fixed to show the bikeSpeed form in bicycle only.

Op donderdag 9 mei 2013 14:05:59 UTC+2 schreef Jorden Verwer het volgende:

[Andrew Byrd]

On 05/08/2013 11:59 AM, jorden...@goabout.com wrote:
> I understand that the entire webapp is going to be replaced by Something
> Better in the (near?) future, so I don't know if this is worth fixing in
> the current webapp, but I thought it would be worth mentioning.

Yes, David Emory has been working on a complete rewrite of the
Javascript OTP client. I was just experimenting with it and it seems to
be coming along nicely. You can find it in this branch:

https://github.com/openplans/OpenTripPlanner/tree/leaflet-ui

The new Maven sub-module is called opentripplanner-leaflet-webapp.

I'm afraid changes made to the 'classic' webapp might fall into disuse
within a few weeks. On the other hand I imagine David wants to get the
new app in a stable state before people start making patches.

David E, is it conceivable to merge your new webapp into master some
time soon, or would you like to do some more work on it first?

If so I'm thinking we should revise the names of our Maven sub-projects.
We've been somewhat confusingly using 'webapp' to mean both 'servlet'
and 'Javascript client'. Something like:

opentripplanner-api-servlet
opentripplanner-web-client

-Andrew

[jorden...@goabout.com]

I'm thinking out loud here and I'm not sure if this is relevant to anybody else, but it might be a good idea if one (or more) of the Dutch OTP guys explains to me the difference between the Dutch fork and the regular version, as well as how everything comes together. I'm a bit puzzled about what seem, to me, to be strange results. For instance, OSM doesn't know about the Schildersstraat in Schipluiden, but the geocoder does. So apparently, the geocoder has yet another source of information, but I don't know what it is. Of course I could figure all this out myself in theory, but I doubt that's the most efficient way of doing things - and I'd probably miss something important.

Obviously, if someone else at GoAbout already knows all these things and can tell me instead, that's fine too. I'm not at the office today so I can't ask right now.

Jorden

[Thomas Koch]

I checked the git commits, the only things different at this stage between the NL fork and  master branch are:

- We haven't brought the localization to the newer wayproperties localization 

https://github.com/skywave/OpenTripPlanner/blob/master/opentripplanner-graph-builder/src/main/resources/WayProperties_nl.properties

- Fyra/HST blocking in the webinterface, which is a quick hack specific to NL and shouldn't be brought to master.

- We're using the C42  BAG42 OTP geocoder @ http://bag42.nl/api/v0/geocode/otp?address=Alchemilla%20Utrecht Which shouldn't be brought over to master either.

Op donderdag 9 mei 2013 15:15:50 UTC+2 schreef jorden...@goabout.com het volgende: