-
Notifications
You must be signed in to change notification settings - Fork 1.1k
GTFS flex support: flag stops, deviated-route service, call-and-ride #2603
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
2b24881
6fcb2f7
cd2fd80
386fbb3
2d7dda1
adfe204
b23c195
d02e969
c51284d
ab4eba4
d0c503a
d3c3e9c
71f81e6
b69d79c
31ae808
f41e94b
cd3784b
b323a12
38b510c
286827d
50c826b
6c4b5fd
448e994
c8e9ee2
2482097
158d829
bbc8d47
869b83c
4300b7e
ee876dc
2858390
9c2587f
0c99c8a
83b5946
03ca5b6
d4d8b41
7efa78f
a6fa013
f499f81
7d10b41
40d6dfd
e27bd2e
d07c74f
09f91d2
332f285
642a890
0751290
a054f5a
58f4039
743dc75
3d6b9ef
976e697
2e7e258
6ec4e74
45c8687
2f1463b
7be83fd
f28c516
7618658
755b9ca
0e89443
c6a77a5
4526b76
7052036
63f1550
092ab19
128f8d0
0144010
e109d40
6d444d4
7bb01f0
2e54b25
f0e2960
16f5bbf
f80c290
3986cf5
77d8bec
e31eaa4
02b23da
78df530
e575758
77c8c1b
9645718
1c64c41
dd9db06
e7f3c06
2202d4d
4165ac6
b5e9086
9682204
64db083
fdad9cb
db87705
a03786b
956f9b9
825f1f8
538fbc2
cc172a7
4f3061d
e387b8c
7b3f78e
a90022e
42ef52e
5fcdcf8
e1e5dc5
264ac13
552017c
7d88625
ebcd083
60992ad
d3423e0
d58881f
bdae118
33c85a1
dc515ef
911019f
d64b89c
8e66a1b
8f3a7da
882e18a
6100d71
fe0bd45
8b80ed5
fb4bd28
4e84448
4eb8864
e655f98
a674369
be67f47
34ba84e
91b09f3
97862fe
65dab1f
de9c3d2
09d72db
db261d5
480cf43
cc17df8
b11a3a4
6a942c5
8be3812
71b637a
c3a4de7
2b34e57
a109081
e7fa912
157ca1a
54168ad
bc11857
f5a2413
a9b460b
c06ee74
c4d01fc
7225b74
238d4ba
049e20d
dea212b
78dd03e
e3a32da
cf552b6
5166629
7ca5e2a
94bc480
9721d12
6476854
ef963bb
508c0bd
c41e87e
8c91900
e309139
625078c
61f887c
20dad97
6000b5b
ec70774
a2654e0
5bf48c2
a925199
87601e0
57794b1
305d3c4
1af18a8
0737f93
e5d5399
5810367
b798103
b0b4853
bc74cf9
64df0a0
128defa
ede216c
04e90eb
49de7eb
0c43736
7bd093b
e2fca76
b37b0a2
96e019a
1d1e904
676b6ea
c718f9d
37ae200
9ca8209
ca94075
f58f592
b323dbd
cf79f98
4a848fd
ea5573f
0f2b097
6dfccf5
e3f4202
14e3c66
dc3a737
5587b10
f168f51
48ef4f4
21bd7c9
b0629b2
0891b8b
c021473
cce248d
f3a6b09
f46c326
e4f4d34
7d448c4
eb87c5d
c877cbb
92d3395
d936b7b
e08b50b
303cf56
3b8802b
12968e6
84b098b
0ebf3d0
1feca7f
a275257
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,70 @@ | ||
| # GTFS-Flex routing | ||
|
|
||
| Many agencies run flexible services to complement their fixed-route service. "Flexible" service does | ||
| not follow a strict timetable or route. It may include any of the following features: boardings | ||
| or alightings outside its scheduled timetable and route; booking and scheduling in advance; or | ||
| transit parameters which depend on customer requests ("demand-responsive transit" or DRT). These | ||
| services are typically used in rural areas or for mobility-impaired riders. | ||
|
|
||
| A GTFS extension called [GTFS-Flex](https://github.com/MobilityData/gtfs-flex/blob/master/spec/reference.md) defines | ||
| how to model some kinds of flexible transit. A subset of GTFS-Flex has been implemented in | ||
| OpenTripPlanner as part of US DOT's [Mobility-on-Demand Sandbox Grant](https://www.transit.dot.gov/research-innovation/fiscal-year-2016-mobility-demand-mod-sandbox-program-projects). | ||
|
|
||
| In particular, OTP now has support for these modes of GTFS-Flex: | ||
|
|
||
| - "flag stops", in which a passenger can flag down the a vehicle along its route to board, or | ||
| alight in between stops | ||
| - "deviated-route service", in which a vehicle can deviate from its route within an area or radius to | ||
| do a dropoff or pickup | ||
| - "call-and-ride", which is an entirely deviated, point-to-point segment. | ||
|
|
||
| These modes can co-exist with fixed-route transit, and with each other. For example, some agencies | ||
| have fixed-route services that start in urban areas, where passengers must board at designated | ||
| stops, but end in rural areas where passengers can board and alight wherever they please. A | ||
| fixed-route service may terminate in an defined area where it can drop off passengers anywhere -- | ||
| or have such an area at the beginning or middle of its route. A vehicle may be able to deviate a | ||
| certain radius outside its scheduled route to pick up or drop off passengers. If both a pickup and | ||
| dropoff occur in between scheduled timepoints, from the passenger's perspective, the service may | ||
| look like a call-and-ride trip. Other call-and-ride services may operate more like taxis, in which | ||
| all rides are independently scheduled. | ||
|
|
||
| ## Configuration | ||
|
|
||
| In order to use flexible routing, an OTP graph must be built with a GTFS-Flex dataset and | ||
| OpenStreetMap data. The GTFS data must include `shapes.txt`. | ||
|
|
||
| In addition, the parameter `useFlexService: true` must be added to `router-config.json`. | ||
|
|
||
| A number of routing parameters can be used to control aspects of flexible service. These parameters | ||
| typically change the relative cost of using various flexible services relative to fixed-route | ||
| transit. All flex-related parameters begin with the prefix "flex" and can be found in the Javadocs | ||
| for `RoutingRequest.java`. | ||
|
|
||
| The following example `router-config.json` enables flexible routing and sets some parameters: | ||
|
|
||
| { | ||
| "useFlexService": true, | ||
| "routingDefaults": { | ||
| "flexCallAndRideReluctance": 3, | ||
| "flexMaxCallAndRideSeconds": 7200, | ||
| "flexFlagStopExtraPenalty": 180 | ||
| } | ||
| } | ||
|
|
||
| ## Implementation | ||
|
|
||
| The general approach of the GTFS-Flex implementation is as follows: prior to the main graph search, | ||
| special searches are run around the origin and destination to discover possible flexible options. | ||
| One search is with the WALK mode, to find flag stops, and the other is in the CAR mode, to find | ||
| deviated-route and call-and-ride options. These searches result in the creation of temporary, | ||
| request-specific vertices and edges. Then, the graph search proceeds as normal. Temporary graph | ||
| structures are disposed at the end of the request's lifecycle. | ||
|
|
||
| For flag stops and deviated-route service, timepoints in between scheduled locations are determined | ||
| via linear interpolation. For example, say a particular trip departs stop A at 9:00am and arrives | ||
| at stop B at 9:30am. A passenger would be able to board 20% of the way in between stop A and stop B | ||
| at 9:06am, since 20% of 30 minutes is 6 minutes. | ||
|
|
||
| For deviated-route service and call-and-ride service, the most pessimistic assumptions of vehicle | ||
| travel time are used -- e.g. vehicle travel time is calculated via the `drt_max_travel_time` | ||
| formula in the GTFS-Flex (see the spec [here](https://github.com/MobilityData/gtfs-flex/blob/master/spec/reference.md#defining-service-parameters)). |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,27 @@ | ||
| package org.opentripplanner.api.model; | ||
t2gran marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| /** | ||
| * Distinguish between special ways a passenger may board or alight at a stop. The majority of | ||
| * boardings and alightings will be of type "default" -- a regular boarding or alighting at a | ||
| * regular transit stop. Currently, the only non-default types are related to GTFS-Flex, but this | ||
| * pattern can be extended as necessary. | ||
| */ | ||
| public enum BoardAlightType { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What does "default" mean here? Please add documentation. The name "BoardAlightType" seems very general - in fact this is highly specific to handling flex transit. |
||
|
|
||
| /** | ||
| * A regular boarding or alighting at a fixed-route transit stop. | ||
| */ | ||
| DEFAULT, | ||
|
|
||
| /** | ||
| * A flag-stop boarding or alighting, e.g. flagging the bus down or a passenger asking the bus | ||
| * driver for a drop-off between stops. This is specific to GTFS-Flex. | ||
| */ | ||
| FLAG_STOP, | ||
|
|
||
| /** | ||
| * A boarding or alighting at which the vehicle deviates from its fixed route to drop off a | ||
| * passenger. This is specific to GTFS-Flex. | ||
| */ | ||
| DEVIATED; | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,6 +8,7 @@ | |
| import org.opentripplanner.util.Constants; | ||
|
|
||
| import com.fasterxml.jackson.databind.annotation.JsonSerialize; | ||
| import org.opentripplanner.util.model.EncodedPolylineBean; | ||
|
|
||
| /** | ||
| * A Place is where a journey starts or ends, or a transit stop along the way. | ||
|
|
@@ -91,6 +92,19 @@ public class Place { | |
| */ | ||
| public String bikeShareId; | ||
|
|
||
| /** | ||
| * This is an optional field which can be used to distinguish among ways a passenger's | ||
| * boarding or alighting at a stop can differ among services operated by a transit agency. | ||
| * This will be "default" in most cases. Currently the only non-default values are for | ||
| * GTFS-Flex board or alight types. | ||
| */ | ||
| public BoardAlightType boardAlightType; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please expand the Javadoc a bit. Does this distinguish between different flexible transit modes, or between flexible modes and fixed route modes? This field name should probably be prefixed / scoped to indicate that it only applies to flex situations. In non-flex responses perhaps it should just be null (left out).
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added some documentation for this. The intention was that this would be "BoardAlightType.default" in the vast majority of cases, and if the boarding or alighting is nonstandard in some way, it would be another value. Right now, the only nonstandard cases are for GTFS-Flex, but that won't necessarily always be the case. I added documentation to that effect. But another approach could be to make this flex specific and leave null otherwise. Any drawbacks/benefits to switching approaches?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I still find that the name "BoardAlightType" is very general, and the documentation here and on the enum is basically tautological: it's a "type of board or alight". There is still not much information about what this field means or what it is used for. |
||
|
|
||
| /** | ||
| * Board or alight area for flag stops | ||
| */ | ||
| public EncodedPolylineBean flagStopArea; | ||
|
|
||
| /** | ||
| * Returns the geometry in GeoJSON format | ||
| * @return | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.