Otp2 redesign api modes - #3011
Conversation
… to use its own class
|
I would like to help test this PR. Is there already some layering in place, for example that a train or metrostation is preferred over a bus or tram stop when accessing or egressing transit by bike? |
Great! For now I'm mostly working on getting the structure in place, and then I will start working on the modes one by one. The priority will be on the access/egress modes that start/end with walking, and then bringing the bike with you on transit will be a later step. It should be possible to favor specific stations using cost. |
9693505 to
d40f0c8
Compare
d40f0c8 to
eec7006
Compare
|
After the last commit it is working, but the travel advices I retrieve is on foot and not with the bicycle. |
What does your request look like? I tested with the OTP client and it does give you a bike-only result if your origin/destination are close enough so it does not go over the distance limit. |
This is what I tried, should I specify a maximum walk distance? {
trip(
dateTime: "2020-04-18T11:14:00Z",
from: {coordinates: {latitude: 51.907708, longitude:4.454966 }},
to: {coordinates: {latitude: 52.053137, longitude:4.328905}},
modes: {accessMode:bicycle, egressMode:bicycle}
)
{
tripPatterns {
startTime
duration
walkDistance
legs {
mode
distance
line {
id
publicCode
presentation {
textColour
colour
}
}
aimedEndTime
aimedStartTime
expectedEndTime
expectedStartTime
realtime
fromPlace {
name
vertexType
}
toPlace {
name
vertexType
}
pointsOnLink{
points
}
realtime
}
}
}
} |
|
@sven4all Taking the bike with you on public transport is currently not supported. Look at the StreetMode enum to have a look at the supported combinations. As you can see in RequestModes class, it will default to null if the mode is not supported for that part of the trip. Making the bike->transit->bike functionality available should be possible, but it requires separate pre-calculated edges for biking (assuming you actually bike during the transfers). Some combinations that I have tested between two coordinates: {accessMode:bike_rental, egressMode:foot} Most of these will also work as egressMode, and in any combination with accessMode. There is still work to be done to get all modes working properly. For example taxi should include walking at both ends in order to be used as both access and egress mode. Also, we need to decide what to do when doing a search that does not start with walking from a stop that is only connected by walk-only streets. This is a search I have been testing with on the Oslo graph. |
|
I this as a fist step it would be nice to support bike-transit(walk transfers)-bike. I see it is not correct, but it is better than not supporting it at all. The long term fix is then to precalculate bike transfers the same way we do walking - this should be toggled on/off for those who need it. |
|
There is no harm in leaving it in, but as you said, it will only support walk transfers. The fix is as simple as access/egress on the bike element in StreetMode and add some documentation. Also, as long as the transfers aren't too long, this will still be quite useful. |
|
I just noticed that this breaks arriveBy-routing. I don't know whether it worked that well previously, but in this branch it fails with error 500 and the following stack trace. |
t2gran
left a comment
t2gran
left a comment
There was a problem hiding this comment.
There is 5 classes in OTP2 (after this is merged) that represent modes in slightly different scopes with overlapping types - like TransitMode and TraverseMode, witch both include mode like BUS. I think this is confusing. I will not insist that we change this, just express a bit of concern about it.
If we make two sub-types for itinerary Leg, a TransitLeg and a StreetLeg, then maybe we could get rid of the TraverseMode. But are modes really static structures? In StreetMode there is more than one CAR and BIKE mode, to me this is a signal that we are missing something? The set (RENTED, BIKE, FOR_ACCESS) is not a mode. The mode is BIKE, the fact that it is rented and used for access tells us that the next mode transition is going to happen in a place where we can park the bike. Modes are in many contexts a hierarchical structure (e.g. NeTEx), so maybe it would be better to represent them in another way. I do not have a complete overview of what we use modes for - so it is hard to suggest something concrete.
| - `searchWindow` Limit the departure window or arrival window for the routing search. | ||
| - `boardSlackByMode` How much time boarding a vehicle takes for each given mode. | ||
| - `alightSlackByMode` How much time alighting a vehicle takes for each given mode. | ||
| - `modes` The REST API is unchanged, but is mapped into a new structure in the RoutingRequest. This means not all combinations of non-transit modes that was available in OTP1 is available in OTP2. |
There was a problem hiding this comment.
We try to keep all lines 100 characters wide, but I am not sure if we should apply it on markdown files. From what I see in the IDE and here on GitHub, it probably better to not do it (both wraps nicely, and Intelij do NOT wrap lines when I try to do auto reformatting). You can do as you like on this one, but we should state something in the developer guideline - I will do that.
Someone from another organization needs to approve this, sorry for hitting the wrong button.
I agree that StreetMode is not a mode in the same sense as the others, but I'm struggling to find a good name for it. In some ways it represents a state-machine with modes and allowed transitions. |
Maybe I do not understand it correctly. But what I try to do is plan a trip where the user cycles to the station, then parks it's bike at the station, take the train and afterwards take a bicycle again. (maybe it's a very dutch way to use public transport that causes some misunderstanding) |
This is also a Norwegian way to use public transport (but probably not to the same extent as the Dutch). You can use bike_park as access mode, and then foot as egress mode (because you don't have your bike with you anymore). This requires there to be a bike parking point defined. As this pull request has been merged, I think you should create a new issue if you wish to discuss this further. |
5 participants
To be completed by pull request submitter:
To be completed by @opentripplanner/plc:
This is a first step in reimplementing and improving how street routing works in OTP2. This builds on #3010, and should be merged after.
I have done the following:
org.opentripplanner.routing.requestpackage.WALKorBIKE_RENTALwhich may include several smaller transitions. (Walk -> bike -> walk with bike -> bike).TraverseModeSetfield is kept in the RoutingRequest, but it is only set by thegetStreetSearchRequestmethod. This should be refactored so we have a separate request object for the street routing.RaptorPathToItineraryMapper.