Merge branch 'dev-2.x' into fix-added-trip-on-service-date

.github/workflows/prune-container-images.yml

@@ -0,0 +1,22 @@
+name: 'Prune container images'
+
+on:
+  schedule:
+    - cron: '0 12 * * 1'
+  workflow_dispatch:
+
+jobs:
+  container-image:
+    if: github.repository_owner == 'opentripplanner'
+    runs-on: ubuntu-latest
+    steps:
+      - name: Delete unused container images
+        env:
+          CONTAINER_REPO: opentripplanner/opentripplanner
+          CONTAINER_REGISTRY_USER: otpbot
+          CONTAINER_REGISTRY_PASSWORD: ${{ secrets.DOCKERHUB_PASSWORD }}
+        run: |
+          # remove all snapshot container images that have not been pulled for over a year
+          # --keep-semver makes sure that any image with a x.y.z version scheme is unaffected by this
+          pip install prune-container-repo==0.0.4
+          prune-container-repo -u ${CONTAINER_REGISTRY_USER} -r ${CONTAINER_REPO} --days=365 --keep-semver --activate

doc-templates/StopConsolidation.md

@@ -30,7 +30,7 @@ This has the following consequences
 
     However, this feature has also severe downsides:
 
-    - It makes realtime trip updates referencing a stop id much more complicated and in many cases 
+    - It makes real-time trip updates referencing a stop id much more complicated and in many cases 
       impossible to resolve. 
       You can only reference a stop by its sequence, which only works in GTFS-RT, not Siri.
     - Fare calculation and transfers are unlikely to work as expected.

docs/BuildConfiguration.md

@@ -28,7 +28,6 @@ Sections follow that describe particular settings in more depth.
 | [graph](#graph)                                                          |    `uri`    | URI to the graph object file for reading and writing.                                                                                                          | *Optional* |                                   |  2.0  |
 | [gsCredentials](#gsCredentials)                                          |   `string`  | Local file system path to Google Cloud Platform service accounts credentials file.                                                                             | *Optional* |                                   |  2.0  |
 | [includeEllipsoidToGeoidDifference](#includeEllipsoidToGeoidDifference)  |  `boolean`  | Include the Ellipsoid to Geoid difference in the calculations of every point along every StreetWithElevationEdge.                                              | *Optional* | `false`                           |  2.0  |
-| matchBusRoutesToStreets                                                  |  `boolean`  | Based on GTFS shape data, guess which OSM streets each bus runs on to improve stop linking.                                                                    | *Optional* | `false`                           |  1.5  |
 | maxAreaNodes                                                             |  `integer`  | Visibility calculations for an area will not be done if there are more nodes than this limit.                                                                  | *Optional* | `150`                             |  2.1  |
 | [maxDataImportIssuesPerFile](#maxDataImportIssuesPerFile)                |  `integer`  | When to split the import report.                                                                                                                               | *Optional* | `1000`                            |  2.0  |
 | maxElevationPropagationMeters                                            |  `integer`  | The maximum distance to propagate elevation to vertices which have no elevation.                                                                               | *Optional* | `2000`                            |  1.5  |

docs/Data-Sources.md

@@ -5,7 +5,7 @@
 At the core of OpenTripPlanner is a library of Java code that finds efficient paths through
 multi-modal transportation networks built
 from [OpenStreetMap](http://wiki.openstreetmap.org/wiki/Main_Page)
-and [GTFS](https://developers.google.com/transit/gtfs/) data. It can also receive GTFS-RT (realtime)
+and [GTFS](https://developers.google.com/transit/gtfs/) data. It can also receive GTFS-RT (real-time)
 data.
 
 In addition to GTFS, OTP can also load data in the Nordic Profile of Netex, the EU-standard transit

docs/Deployments.md

@@ -6,7 +6,7 @@ The following are known deployments of OTP in a government- or agency-sponsored
 
 * **Norway (nationwide)** Since November 2017, the national integrated ticketing agency Entur has
   prodvided a [national journey planner](https://en-tur.no/) which consumes schedule data in the EU
-  standard NeTEx format with SIRI realtime updates. Entur has contributed greatly to the OTP2 effort
+  standard NeTEx format with SIRI real-time updates. Entur has contributed greatly to the OTP2 effort
   and primarily uses OTP2 in production, handling peak loads in excess of 20 requests per second. 
   Most regional agencies in Norway, like **Ruter, Oslo area** uses OTP as a service provided by Entur.
 * **Finland (nationwide)** The [Helsinki Regional Transport Authority](https://www.reittiopas.fi/),
@@ -22,7 +22,7 @@ The following are known deployments of OTP in a government- or agency-sponsored
   service [Matkahuolto](https://en.wikipedia.org/wiki/Matkahuolto)
   has [developed a trip planner in partnership with Kyyti](https://www.kyyti.com/matkahuoltos-new-app-brings-real-travel-chains-within-the-reach-of-citizens-in-addition-to-coach-travel-hsl-tickets-are-also-available/).
 * **Skåne, Sweden**, the JourneyPlanner and mobile app for the regional transit agency [Skånetrafiken](https://www.skanetrafiken.se/)
-  uses OTP2 with the nordic profile of NeTEx and SIRI for realtime updates.
+  uses OTP2 with the nordic profile of NeTEx and SIRI for real-time updates.
 * [**Northern Colorado**](https://discover.rideno.co/)
 * [**Philadelphia and surrounding areas**](https://plan.septa.org)
 * **Portland, Oregon** TriMet is the agency that originally started the OpenTripPlanner project.

docs/Netex-Norway.md

@@ -85,11 +85,11 @@ using OTP's built in testing web client. Try some long trips like Oslo to Bergen
 get long distance trains and flights as alternatives. You might need to increase the walking limit
 above its very low default value.
 
-## Adding SIRI Realtime Data
+## Adding SIRI Real-time Data
 
 Another important feature in OTP2 is the ability to
-use [SIRI realtime data](https://en.wikipedia.org/wiki/Service_Interface_for_Real_Time_Information).
-Within the EU data standards, SIRI is analogous to GTFS-RT: a way to apply realtime updates on top
+use [SIRI real-time data](https://en.wikipedia.org/wiki/Service_Interface_for_Real_Time_Information).
+Within the EU data standards, SIRI is analogous to GTFS-RT: a way to apply real-time updates on top
 of schedule data. While technically a distinct specification from Netex, both Netex and SIRI use the
 Transmodel vocabulary, allowing SIRI messages to reference entities in Netex schedule data. Like
 GTFS-RT, SIRI is consumed by OTP2 using "graph updaters" which are configured in
@@ -143,6 +143,6 @@ Note that between these SIRI updaters and the GTFS-RT Websocket updater, we now
 and streaming examples of GTFS-RT "incrementality" semantics, so should be able to finalize that
 part of the specification.
 
-The final updater regularly performs a copy of the realtime data into a format suitable for use by
-OTP2's new Raptor router. Without this updater the realtime data will be received and cataloged, but
+The final updater regularly performs a copy of the real-time data into a format suitable for use by
+OTP2's new Raptor router. Without this updater the real-time data will be received and cataloged, but
 not visible to the router.

docs/RouteRequest.md

@@ -47,7 +47,7 @@ and in the [transferRequests in build-config.json](BuildConfiguration.md#transfe
 | elevatorHopTime                                                                                              |        `integer`       | How long does it take to advance one floor on an elevator?                                                                                     | *Optional* | `20`             |  2.0  |
 | escalatorReluctance                                                                                          |        `double`        | A multiplier for how bad being in an escalator is compared to being in transit for equal lengths of time                                       | *Optional* | `1.5`            |  2.4  |
 | geoidElevation                                                                                               |        `boolean`       | If true, the Graph's ellipsoidToGeoidDifference is applied to all elevations returned by this query.                                           | *Optional* | `false`          |  2.0  |
-| ignoreRealtimeUpdates                                                                                        |        `boolean`       | When true, realtime updates are ignored during this search.                                                                                    | *Optional* | `false`          |  2.0  |
+| ignoreRealtimeUpdates                                                                                        |        `boolean`       | When true, real-time updates are ignored during this search.                                                                                   | *Optional* | `false`          |  2.0  |
 | [intersectionTraversalModel](#rd_intersectionTraversalModel)                                                 |         `enum`         | The model that computes the costs of turns.                                                                                                    | *Optional* | `"simple"`       |  2.2  |
 | locale                                                                                                       |        `locale`        | TODO                                                                                                                                           | *Optional* | `"en_US"`        |  2.0  |
 | [maxDirectStreetDuration](#rd_maxDirectStreetDuration)                                                       |       `duration`       | This is the maximum duration for a direct street search for each mode.                                                                         | *Optional* | `"PT4H"`         |  2.1  |

docs/RouterConfiguration.md

@@ -46,7 +46,7 @@ A full list of them can be found in the [RouteRequest](RouteRequest.md).
 |          [logKey](#server_traceParameters_0_logKey)                                       |        `string`       | The log event key used.                                                                               | *Optional* |               |  2.4  |
 | timetableUpdates                                                                          |        `object`       | Global configuration for timetable updaters.                                                          | *Optional* |               |  2.2  |
 |    [maxSnapshotFrequency](#timetableUpdates_maxSnapshotFrequency)                         |       `duration`      | How long a snapshot should be cached.                                                                 | *Optional* | `"PT1S"`      |  2.2  |
-|    purgeExpiredData                                                                       |       `boolean`       | Should expired realtime data be purged from the graph. Apply to GTFS-RT and Siri updates.             | *Optional* | `true`        |  2.2  |
+|    purgeExpiredData                                                                       |       `boolean`       | Should expired real-time data be purged from the graph. Apply to GTFS-RT and Siri updates.            | *Optional* | `true`        |  2.2  |
 | [transit](#transit)                                                                       |        `object`       | Configuration for transit searches with RAPTOR.                                                       | *Optional* |               |   na  |
 |    [iterationDepartureStepInSeconds](#transit_iterationDepartureStepInSeconds)            |       `integer`       | Step for departure times between each RangeRaptor iterations.                                         | *Optional* | `60`          |   na  |
 |    [maxNumberOfTransfers](#transit_maxNumberOfTransfers)                                  |       `integer`       | This parameter is used to allocate enough memory space for Raptor.                                    | *Optional* | `12`          |   na  |

docs/SandboxExtension.md

@@ -15,8 +15,8 @@ provided "as is".
 - [Transfer analyser](sandbox/transferanalyzer.md) - Module used for analyzing the transfers between 
 nearby stops generated by routing via OSM data.
 - [Transmodel API](sandbox/TransmodelApi.md) - Enturs GraphQL Transmodel API.
-- [SIRI Updater](sandbox/SiriUpdater.md) - Update OTP with realtime information from a Transmodel SIRI data source.
-- [SIRI Azure Updater](sandbox/SiriAzureUpdater.md) - fetch SIRI realtime data through *Azure Service Bus*
+- [SIRI Updater](sandbox/SiriUpdater.md) - Update OTP with real-time information from a Transmodel SIRI data source.
+- [SIRI Azure Updater](sandbox/SiriAzureUpdater.md) - fetch SIRI real-time data through *Azure Service Bus*
 - [VehicleRentalServiceDirectory](sandbox/VehicleRentalServiceDirectory.md) - GBFS service directory endpoint.
 - [Smoove Bike Rental Updator Support](sandbox/SmooveBikeRental.md) - Smoove Bike Rental Updator(HSL)
 - [Mapbox Vector Tiles API](sandbox/MapboxVectorTilesApi.md) - Mapbox Vector Tiles API

docs/System-Requirements.md

@@ -10,7 +10,7 @@ OTP is relatively memory-hungry as it includes all the required data in memory.
 
 Single thread performance is an important factor for OTP's performance. Additionally, OTP benefits from larger CPU cache as reading from memory can be a bottleneck.
 
-OTP's performance scales with the number of available CPU cores. OTP processes each request in a separate thread and usually one request doesn't utilize more than one thread, but with some requests and configurations, it's possible that multiple threads are used in parallel for a small part of a request or to process multiple queries within one request. How much parallel processing we utilize in requests might change in the future. Realtime updates also run in a separate thread. Therefore, to have a good performance, it makes sense to have multiple cores available. How OTP uses parallel processing also depends on the available cores (<= 2 cores vs >2 cores) in some cases. Therefore, load testing should be done against a machine that doesn't differ too much from production machines.
+OTP's performance scales with the number of available CPU cores. OTP processes each request in a separate thread and usually one request doesn't utilize more than one thread, but with some requests and configurations, it's possible that multiple threads are used in parallel for a small part of a request or to process multiple queries within one request. How much parallel processing we utilize in requests might change in the future. Real-time updates also run in a separate thread. Therefore, to have a good performance, it makes sense to have multiple cores available. How OTP uses parallel processing also depends on the available cores (<= 2 cores vs >2 cores) in some cases. Therefore, load testing should be done against a machine that doesn't differ too much from production machines.
 
 Entur and the Digitransit project have found that the 3rd generation AMD processors have a slightly better performance for OTP2 than the Intel 3rd generation CPUs (and especially better than the 2nd generation CPUs).
 

docs/examples/entur/build-config.json

@@ -5,7 +5,6 @@
   "embedRouterConfig": true,
   "areaVisibility": true,
   "platformEntriesLinking": true,
-  "matchBusRoutesToStreets": false,
   "staticParkAndRide": true,
   "staticBikeParkAndRide": true,
   "maxDataImportIssuesPerFile": 1000,

docs/examples/skanetrafiken/Readme.md

@@ -35,13 +35,13 @@ To reduced graph size, only data for southern part of Sweden is used.
 OSM data is downloaded from `http://download.geofabrik.de/europe/denmark-latest.osm.pbf`.
 To reduce graph size, only data for northern part of Denmark is used.
 
-## Realtime
+## Real-time
 
-The **Azure Service Bus** is used to propagate SIRI SX and ET realtime messages to OTP.
+The **Azure Service Bus** is used to propagate SIRI SX and ET real-time messages to OTP.
 This is solved through Siri Azure updaters that Skånetrafiken had implemented in OTP. There are
 separate updaters for SIRI SX and ET.
 Those updaters are used to provide data for Swedish traffic (NeTEx). Right now, there is no
-connection to any realtime source for danish traffic (GTFS data).
+connection to any real-time source for danish traffic (GTFS data).
 
 Except for receiving messages from **Service Bus** there are two endpoints through which historical
 ET and SX messages can be downloaded at OTP startup.
@@ -54,8 +54,8 @@ the subscription.
 Once the updaters are done with processing of history messages they will change their status to
 primed,
 and the system will start channeling request to this OTP instance.
-This ensures that no realtime message is omitted and all OTP instance that ran in the
-cluster does have exact same realtime data.
+This ensures that no real-time message is omitted and all OTP instance that ran in the
+cluster does have exact same real-time data.
 Thi means that no matter which instance the client is hitting it will always get the same search
 results.
 

docs/examples/skanetrafiken/router-config.json

@@ -33,7 +33,7 @@
       "fuzzyTripMatching": false,
       "history": {
         "url": "<history_endpoint_url>",
-        // Get all realtime history for current operating day date
+        // Get all real-time history for current operating day date
         "fromDateTime": "-P0D",
         "timeout": 300000
       }

docs/sandbox/MapboxVectorTilesApi.md

@@ -80,7 +80,7 @@ The feature must be configured in `router-config.json` as follows
       "minZoom": 14,
       "cacheMaxSeconds": 600
     },
-    // Contains just stations and realtime information for them
+    // Contains just stations and real-time information for them
     {
       "name": "realtimeRentalStations",
       "type": "VehicleRentalStation",
@@ -90,7 +90,7 @@ The feature must be configured in `router-config.json` as follows
       "cacheMaxSeconds": 60
     },
     // This exists for backwards compatibility. At some point, we might want
-    // to add a new realtime parking mapper with better translation support
+    // to add a new real-time parking mapper with better translation support
     // and less unnecessary fields.
     {
       "name": "stadtnaviVehicleParking",
@@ -101,7 +101,7 @@ The feature must be configured in `router-config.json` as follows
       "cacheMaxSeconds": 60,
       "expansionFactor": 0.25
     },
-    // no realtime, translatable fields are translated based on accept-language header
+    // no real-time, translatable fields are translated based on accept-language header
     // and contains less fields than the Stadtnavi mapper
     {
       "name": "vehicleParking",
@@ -190,4 +190,4 @@ key, and a function to create the mapper, with a `Graph` object as a parameter,
   * Translatable fields are now translated based on accept-language header
   * Added DigitransitRealtime for vehicle rental stations
   * Changed old vehicle parking mapper to be Stadtnavi
-  * Added a new Digitransit vehicle parking mapper with no realtime information and less fields
+  * Added a new Digitransit vehicle parking mapper with no real-time information and less fields

docs/sandbox/StopConsolidation.md

@@ -30,7 +30,7 @@ This has the following consequences
 
     However, this feature has also severe downsides:
 
-    - It makes realtime trip updates referencing a stop id much more complicated and in many cases 
+    - It makes real-time trip updates referencing a stop id much more complicated and in many cases 
       impossible to resolve. 
       You can only reference a stop by its sequence, which only works in GTFS-RT, not Siri.
     - Fare calculation and transfers are unlikely to work as expected.