Minor changes in departure position forcing a travel in the opposite direction

[barslett]

Hi folks, here in Oslo, our travel planner for the whole of Southeastern Norway is running on OTP in production since four weeks ago. After some performance tuning, everything seems to run pretty stable and well. We are now trying to solve some issues in the journey routing that we don't quite understand.

This actual issue is that, in some cases, a journey search from a point within few (< 50 m) to a stop point where a public transport service exists in the proper direction, doesn't give you this as an option. Instead, you are required to do a detour, either to the other side of the street, where you are told to board a vehicle in the opposite direction, take it one or two stops, change, and go back, passing the place where you started, and continue to your final destination - or to walk to a stop some 500 m away and board another service, with some interchange later on, before the destination is reached.

If we then move the starting point just a few meters, suddenly it snaps properly.

Please see the illustration, from the stop Rådhuset (Oslo city hall), where we want to take bus 30 to Bygdøy. Even though stop points here are placed a bit wrongly, it should give a good clue about what happens. Green spots indicate where you will be taken to the right stop point (at the tip of the blue arrow, red spots indicate where you are taken to the wrong on (yellow arrow). This gives us an invisible wall (painted in red :)) which separate lucky riders from the ones having to do considerable detours....

Anyone who has a clue about what is going on here?

[abyrd]

Hi @barslett, I'm looking at this now. This may because of a long-standing problem where pedestrian ways are given too low a preference in choosing starting points (#1077).

[barslett]

You might have a good point here. The (known) three locations in Oslo where we have this problem, all have a lot of walk paths surrounded by roads.

Sendt fra min Samsung-enhet

-------- Opprinnelig melding -------- Fra: Andrew Byrd notifications@github.com Dato: 09.02.2016 18:05 (GMT+01:00) Til: opentripplanner/OpenTripPlanner OpenTripPlanner@noreply.github.com Ko: Barslett Torbjørn Torbjorn.Barslett@ruter.no Emne: Re: [OpenTripPlanner] Minor changes in departure position forcing a travel in the opposite direction (#2204)

Hi @barsletthttps://github.com/barslett, I'm looking at this now. This may because of a long-standing problem where pedestrian ways are given too low a preference in choosing starting points (#1077https://github.com/opentripplanner/OpenTripPlanner/issues/1077).

Reply to this email directly or view it on GitHubhttps://github.com/opentripplanner/OpenTripPlanner/issues/2204#issuecomment-181959068.

[hannesj]

@barslett, we noticed some similar issues here in Helsinki. It seems most of them were fixed with this patch. You could see how it affects your environment. The change makes the comments above make more sense about only snapping with car mode, but I'm not really sure how they should be interpreted.

[abyrd]

@hannesj I was just looking at this chunk of code as your message came in. I see that a platform preference is already being applied a few lines earlier before we hit this section, which according to the comments is supposed to only apply when cars are in use. So I do believe your grouping with parentheses is the intended one. I can certainly see how this would adversely affect results. I don't really understand why we'd give double preference to platforms when cars are in use, but this whole section looks like it could use a rethink and a lot more comments. Whatever the case may be, this expression deserves some parentheses. I don't like having to check operator precedence tables to figure out what code is doing.

@barslett if this or some other change to the endpoint-scoring code in CandidateEdge.calcScore() improves your results, we'll certainly update it.

[hannesj]

After taking a second look at the code, I think my commit is actually wrong as it might break car routing as cars might be snapped to un-routeable street edges. Rather the whole || (edge.getStreetClass() & platform) != 0 should be removed and the PLATFORM_PREFERENCE should be tweaked.

[hannesj]

Just for reference, this is related to getting routing to snap to platforms when starting a search near them (probably a bit too agressively) by commits 1 2

[barslett]

Thank you both! We should try to apply this patch when our Java guy @kirkhus is back in the office week 8.

[barslett]

Closing, as this is working as it should.