Merge remote-tracking branch 'upstream/dev-2.x' into plan-connection

README.md

@@ -1,7 +1,7 @@
 ## Overview
 
 [![Join the chat at https://gitter.im/opentripplanner/OpenTripPLanner](https://badges.gitter.im/opentripplanner/OpenTripPlanner.svg)](https://gitter.im/opentripplanner/OpenTripPlanner)
-[![Matrix](https://img.shields.io/matrix/opentripplanner%3Amatrix.org?label=Matrix%20chat)](https://matrix.to/#/#opentripplanner_OpenTripPlanner:gitter.im)
+[![Matrix](https://img.shields.io/matrix/opentripplanner%3Amatrix.org?label=Matrix%20chat&?cacheSeconds=172800)](https://matrix.to/#/#opentripplanner_OpenTripPlanner:gitter.im)
 [![codecov](https://codecov.io/gh/opentripplanner/OpenTripPlanner/branch/dev-2.x/graph/badge.svg?token=ak4PbIKgZ1)](https://codecov.io/gh/opentripplanner/OpenTripPlanner)
 [![Commit activity](https://img.shields.io/github/commit-activity/y/opentripplanner/OpenTripPlanner)](https://github.com/opentripplanner/OpenTripPlanner/graphs/contributors)
 [![Docker Pulls](https://img.shields.io/docker/pulls/opentripplanner/opentripplanner)](https://hub.docker.com/r/opentripplanner/opentripplanner)
@@ -60,16 +60,7 @@ the world.
 
 ## Getting in touch
 
-The fastest way to get help is to use our [Gitter chat room](https://gitter.im/opentripplanner/OpenTripPlanner)
-where most of the core developers are. You can also send questions and comments to the 
-[mailing list](http://groups.google.com/group/opentripplanner-users).
-
-Changes and extensions to OTP are debated in issues on [GitHub](https://github.com/opentripplanner/OpenTripPlanner/issues)
-and in the  [Gitter chat room](https://gitter.im/opentripplanner/OpenTripPlanner). More general 
-questions and announcements of interest to non-developer OTP users should be directed to
-the [opentripplanner-users](https://groups.google.com/forum/#!forum/opentripplanner-users) list.
-Other details of [project governance](http://docs.opentripplanner.org/en/dev-2.x/Governance/) can be
-found in the main documentation.
+The fastest way to get help is to use our [Gitter chat room](https://gitter.im/opentripplanner/OpenTripPlanner) where most of the core developers are. Bug reports may be filed via the Github [issue tracker](https://github.com/openplans/OpenTripPlanner/issues). The OpenTripPlanner [mailing list](http://groups.google.com/group/opentripplanner-users) is used almost exclusively for project announcements. The mailing list and issue tracker are not intended for support questions or discussions. Please use the chat for this purpose. Other details of [project governance](http://docs.opentripplanner.org/en/dev-2.x/Governance/) can be found in the main documentation.
 
 ## OTP Ecosystem
 

client-next/package.json

@@ -21,35 +21,35 @@
     "bootstrap": "5.3.3",
     "graphql": "16.8.1",
     "graphql-request": "6.1.0",
-    "maplibre-gl": "4.1.2",
-    "react": "18.2.0",
+    "maplibre-gl": "4.2.0",
+    "react": "18.3.1",
     "react-bootstrap": "2.10.2",
-    "react-dom": "18.2.0",
+    "react-dom": "18.3.1",
     "react-map-gl": "7.1.7"
   },
   "devDependencies": {
     "@graphql-codegen/cli": "5.0.2",
     "@graphql-codegen/client-preset": "4.2.5",
     "@graphql-codegen/introspection": "4.0.3",
     "@parcel/watcher": "2.4.1",
-    "@testing-library/react": "15.0.2",
-    "@types/react": "18.2.79",
-    "@types/react-dom": "18.2.25",
-    "@typescript-eslint/eslint-plugin": "7.7.0",
-    "@typescript-eslint/parser": "7.7.0",
+    "@testing-library/react": "15.0.7",
+    "@types/react": "18.3.1",
+    "@types/react-dom": "18.3.0",
+    "@typescript-eslint/eslint-plugin": "7.8.0",
+    "@typescript-eslint/parser": "7.8.0",
     "@vitejs/plugin-react": "4.2.1",
-    "@vitest/coverage-v8": "1.5.0",
+    "@vitest/coverage-v8": "1.6.0",
     "eslint": "8.57.0",
     "eslint-config-prettier": "9.1.0",
     "eslint-plugin-import": "2.29.1",
     "eslint-plugin-jsx-a11y": "6.8.0",
     "eslint-plugin-react": "7.34.1",
-    "eslint-plugin-react-hooks": "4.6.0",
+    "eslint-plugin-react-hooks": "4.6.2",
     "eslint-plugin-react-refresh": "0.4.6",
     "jsdom": "24.0.0",
     "prettier": "3.2.5",
     "typescript": "5.4.5",
-    "vite": "5.2.8",
-    "vitest": "1.5.0"
+    "vite": "5.2.11",
+    "vitest": "1.6.0"
   }
 }

doc-templates/BuildConfiguration.md

@@ -140,22 +140,6 @@ The mechanism is that for any two identical tags, OTP will use the first one.
 }
 ```
 
-### Custom naming
-
-You can define a custom naming scheme for elements drawn from OSM by defining an `osmNaming` field
-in `build-config.json`, such as:
-
-```JSON
-// build-config.json
-{
-  "osmNaming": "portland"
-}
-```
-
-There is currently only one custom naming module called `portland` (which has no parameters).
-
-
-
 ## Elevation data
 
 OpenTripPlanner can "drape" the OSM street network over a digital elevation model (DEM). This allows

doc-templates/Flex.md

@@ -10,8 +10,19 @@
 
 To enable this turn on `FlexRouting` as a feature in `otp-config.json`.
 
-The GTFS feeds should conform to the 
-[GTFS-Flex v2 draft PR](https://github.com/google/transit/pull/388)
+The GTFS feeds must conform to the final, approved version of the draft which has been 
+merged into the [mainline specification](https://gtfs.org/schedule/reference/) in March 2024.
+
+### Experimental features
+
+This sandbox feature also has experimental support for the following fields:
+
+- `safe_duration_factor`
+- `safe_duration_offset`
+
+These features are currently [undergoing specification](https://github.com/MobilityData/gtfs-flex/pull/79) 
+and their definition might change. OTP's implementation will be also be changed so be careful
+when relying on this feature.
 
 ## Configuration
 

doc-templates/VehicleParking.md

@@ -3,7 +3,7 @@
 ## Contact Info
 
 - For HSL Park and Ride updater: Digitransit team, HSL, Helsinki, Finland
-- For Bikely and NOI updater: Leonard Ehrenfried, [[email protected]](mailto:[email protected])
+- For Bikely, NOI and Bikeep updater: Leonard Ehrenfried, [[email protected]](mailto:[email protected])
 
 
 ## Documentation
@@ -44,6 +44,9 @@ All updaters have the following parameters in common:
 
 <!-- INSERT: noi-open-data-hub -->
 
+## Bikeep
+
+<!-- INSERT: bikeep -->
 
 ## Changelog
 

doc-templates/sandbox/siri/SiriAzureUpdater.md

@@ -1,7 +1,8 @@
 # Siri Azure Updater
 
-It is sandbox extension developed by Skånetrafiken that allows OTP to fetch Siri ET & SX messages through *Azure Service Bus*.
-IT also OTP to download historical data from en HTTP endpoint on startup.
+This is a sandbox extension developed by Skånetrafiken that allows OTP to fetch Siri ET & SX messages 
+through *Azure Service Bus*.
+It also enables OTP to download historical data from en HTTP endpoint on startup.
 
 ## Contact Info
 

docs/Accessibility.md

@@ -2,10 +2,16 @@
 
 ## Preamble
 
-GTFS and Netex define accessibility primarily in terms of binary access for wheelchair users: it's
-either on or off. Whilst it is the desire of the OTP developers to broaden the scope of
-accessibility the lack of data limits us to use this definition in the implementation and in this
-document.
+In this document and in OTP, the term "accessibility" is used with its most common 
+meaning: design of products, devices, services, vehicles, or environments to ensure they are usable by 
+people with disabilities. If you have reached this page looking for cumulative opportunities 
+accessibility indicators (access to opportunities metrics) please see the [Analysis](Analysis.md) page.
+
+While accessibility is a complex subject, at this point GTFS and Netex mostly represent it very
+simply as a yes/no possibility of wheelchair use. While OTP developers hope to broaden the
+scope and nuance of accessibility support in OTP, the lack of detailed data from data producers
+currently limits implementation and discussion in this document to this binary
+"wheelchair accessible" definition.
 
 ## Unknown data
 

docs/Analysis.md

@@ -0,0 +1,21 @@
+# Travel Time Analysis
+
+## Background
+
+Since the beginning of the project, many OTP contributors and users have been primarily interested in research, spatial analysis, and urban planning use cases. They have prototyped many ideas within or on top of the OTP codebase, including one-to-many searches producing travel time grids, isochrones, and access-to-opportunities indicators (see Terminology Note below). This has historically been a major area of application for OpenTripPlanner and has helped popularize cumulative opportunities metrics in urban planning. For example, the University of Minnesota Accessibility Observatory used OpenTripPlanner for [Access Across America](https://www.cts.umn.edu/programs/ao/aaa). 
+
+Although we consider these use cases quite important, most work of this kind has long since shifted to separate projects focused on urban planning and analytics. As of version 2, OTP has chosen to focus entirely on passenger information rather than analytics.
+
+## Travel Time Analysis in OTP1
+
+Much of the analysis code present in the v1.x legacy branch of OTP is essentially an unmaintained and unsupported early prototype for later projects, specifically [R5](https://github.com/conveyal/r5/) and the [Conveyal Analysis](https://conveyal.com/learn) system built upon it. OTP1 seems to have gained popularity for analysis uses due to the existence of documentation and an active user community, but has significant technical shortcomings. One of these is simply speed: OTP1 can be orders of magnitude slower (and more memory-intensive) than the approaches used in R5. The other is the requirement to search at a single specific time. Travel times and especially wait times on scheduled transit vary greatly depending on when you depart. Accounting for variation over a time window requires repeated independent searches at each possible departure time, which is very inefficient. R5 is highly optimized to capture variations in travel time across time windows and account for uncertainty in waiting times on frequency-based routes.
+
+## Travel Time Analysis in OTP2
+
+OTP2's new transit router is quite similar to R5 (indeed it was directly influenced by R5) and would not face the same technical problems. Nonetheless, we have decided not to port the OTP1 analysis features over to OTP2 since it would broaden the scope of OTP2 away from passenger information and draw the finite amount of available attention and resources away from existing open source analytics tools. If you would like to apply the routing innovations present in OTP2 in analytics situations, we recommend taking a look at projects like R5 or the R and Python language wrappers for it created by the community.
+
+Some analytics features may still be available as optional "sandbox" features in OTP2 (such as [Travel Time](sandbox/TravelTime.md)), but these do not work in the same way as the features you may have used or read about in OTP1. They are unmaintained and unsupported, and may be removed in the near future.
+
+## Terminology Note
+
+In OpenTripPlanner, we usually use the term "accessibility" with its most common meaning: design of products, devices, services, vehicles, or environments to ensure they are usable by people with disabilities. The term "accessibility" has a completely separate, unrelated definition in the fields of spatial analysis, urban transportation planning, and associated social sciences, where it refers to quantitative indicators of how well-connected a particular location is to people or opportunities. OTP has been widely used in research and planning settings for the calculation of such indicators. Although this meaning of the term dates back many decades, it is less well known and has become a source of confusion, so the academic and planning communities are gradually shifting to the expression "access to opportunities", often shortened to "access".

docs/BuildConfiguration.md

@@ -35,7 +35,7 @@ Sections follow that describe particular settings in more depth.
 | maxTransferDuration                                                      |  `duration` | Transfers up to this duration with the default walk speed value will be pre-calculated and included in the Graph.                                              | *Optional* | `"PT30M"`                         |  2.1  |
 | [multiThreadElevationCalculations](#multiThreadElevationCalculations)    |  `boolean`  | Configuring multi-threading during elevation calculations.                                                                                                     | *Optional* | `false`                           |  2.0  |
 | [osmCacheDataInMem](#osmCacheDataInMem)                                  |  `boolean`  | If OSM data should be cached in memory during processing.                                                                                                      | *Optional* | `false`                           |  2.0  |
-| osmNaming                                                                |   `string`  | A custom OSM namer to use.                                                                                                                                     | *Optional* |                                   |  2.0  |
+| [osmNaming](#osmNaming)                                                  |    `enum`   | A custom OSM namer to use.                                                                                                                                     | *Optional* | `"default"`                       |  1.5  |
 | platformEntriesLinking                                                   |  `boolean`  | Link unconnected entries to public transport platforms.                                                                                                        | *Optional* | `false`                           |  2.0  |
 | [readCachedElevations](#readCachedElevations)                            |  `boolean`  | Whether to read cached elevation data.                                                                                                                         | *Optional* | `true`                            |  2.0  |
 | staticBikeParkAndRide                                                    |  `boolean`  | Whether we should create bike P+R stations from OSM data.                                                                                                      | *Optional* | `false`                           |  1.5  |
@@ -238,22 +238,6 @@ The mechanism is that for any two identical tags, OTP will use the first one.
 }
 ```
 
-### Custom naming
-
-You can define a custom naming scheme for elements drawn from OSM by defining an `osmNaming` field
-in `build-config.json`, such as:
-
-```JSON
-// build-config.json
-{
-  "osmNaming": "portland"
-}
-```
-
-There is currently only one custom naming module called `portland` (which has no parameters).
-
-
-
 ## Elevation data
 
 OpenTripPlanner can "drape" the OSM street network over a digital elevation model (DEM). This allows
@@ -536,6 +520,14 @@ deployment depending on your infrastructure. Set the parameter to `true` to cach
 data, and to `false` to read the stream from the source each time.
 
 
+<h3 id="osmNaming">osmNaming</h3>
+
+**Since version:** `1.5` ∙ **Type:** `enum` ∙ **Cardinality:** `Optional` ∙ **Default value:** `"default"`   
+**Path:** /   
+**Enum values:** `default` | `portland` | `sidewalks`
+
+A custom OSM namer to use.
+
 <h3 id="readCachedElevations">readCachedElevations</h3>
 
 **Since version:** `2.0` ∙ **Type:** `boolean` ∙ **Cardinality:** `Optional` ∙ **Default value:** `true`   
@@ -744,7 +736,7 @@ but we want to calculate the transfers always from OSM data.
 Should there be some preference or aversion for transfers at stops that are part of a station.
 
 This parameter sets the generic level of preference. What is the actual cost can be changed
-with the `stopTransferCost` parameter in the router configuration.
+with the `stopBoardAlightDuringTransferCost` parameter in the router configuration.
 
 
 <h3 id="islandPruning_adaptivePruningDistance">adaptivePruningDistance</h3>
@@ -993,7 +985,7 @@ but we want to calculate the transfers always from OSM data.
 Should there be some preference or aversion for transfers at stops that are part of a station. Overrides the value specified in `gtfsDefaults`.
 
 This parameter sets the generic level of preference. What is the actual cost can be changed
-with the `stopTransferCost` parameter in the router configuration.
+with the `stopBoardAlightDuringTransferCost` parameter in the router configuration.
 
 
 <h3 id="tf_1_groupFilePattern">groupFilePattern</h3>

docs/Changelog.md

@@ -13,6 +13,14 @@ based on merged pull requests. Search GitHub issues and pull requests for smalle
 - Discourage instead of ban cycling on use_sidepath ways and do the same for walking on foot=use_sidepath [#5790](https://github.com/opentripplanner/OpenTripPlanner/pull/5790)
 - Prune islands with mode-less stop vertices [#5782](https://github.com/opentripplanner/OpenTripPlanner/pull/5782)
 - Overwrite default WALK directMode when it is not set in the request, but modes is set [#5779](https://github.com/opentripplanner/OpenTripPlanner/pull/5779)
+- Fix trip duplication in Graph Builder DSJ mapping [#5794](https://github.com/opentripplanner/OpenTripPlanner/pull/5794)
+- Optionally abort startup when unknown configuration parameters were detected [#5676](https://github.com/opentripplanner/OpenTripPlanner/pull/5676)
+- Fix bug in heuristics cost calculation for egress legs [#5783](https://github.com/opentripplanner/OpenTripPlanner/pull/5783)
+- Fix handling of implicit access and egress mode parameters. [#5821](https://github.com/opentripplanner/OpenTripPlanner/pull/5821)
+- Add prettier:write to docs and rephrase slightly [ci skip] [#5831](https://github.com/opentripplanner/OpenTripPlanner/pull/5831)
+- Make naming of stopTransferCosts/stopBoardAlightCosts consistent [#5822](https://github.com/opentripplanner/OpenTripPlanner/pull/5822)
+- Namer for applying street names to nearby sidewalks [#5774](https://github.com/opentripplanner/OpenTripPlanner/pull/5774)
+- Implement GTFS Flex safe duration spec draft [#5796](https://github.com/opentripplanner/OpenTripPlanner/pull/5796)
 [](AUTOMATIC_CHANGELOG_PLACEHOLDER_DO_NOT_REMOVE)
 
 ## 2.5.0 (2024-03-13)

docs/Codestyle.md

@@ -14,14 +14,21 @@ it takes a bit of time, but reformat the entire codebase. Only code you have cha
 formatted, since the existing code is already formatted. The second way is to set up prettier and
 run it manually or hick it into your IDE, so it runs every time a file is changed.
 
-### How to run Prittier with Maven
+### How to run Prettier with Maven
 
-Format all code is done in the validate phase (run before test, package, install)
+Prettier will automatically format all code in the Maven "validate" phase, which runs before the test, package, and install phases. So formatting will happen for example when you run:
 
 ```
 % mvn test
 ```
 
+You can manually run _only_ the formatting process with:
+
+```
+% mvn prettier:write
+
+```
+
 To skip the prettier formating use profile `prettierSkip`:
 
 ```
@@ -31,7 +38,7 @@ To skip the prettier formating use profile `prettierSkip`:
 The check for formatting errors use profile `prettierCheck`:
 
 ```
-% mvn test -P prettierSkip
+% mvn test -P prettierCheck
 ```
 
 The check is run by the CI server and will fail the build if the code is incorrectly formatted.

docs/Frontends.md

@@ -32,7 +32,7 @@ While the "classic" (i.e. old) debug frontend is enabled by default as of this w
 // otp-config.json
 {
   "otpFeatures": {
-    "DebugClient": true,
+    "DebugUi": true,
     "SandboxAPIGeocoder": true
   }
 }