Dt 6111 Update OTP2 information to Digitransit.fi

src/pages/en/developers/apis/1-routing-api/0-graphql/index.md

@@ -2,7 +2,7 @@
 title: GraphQL
 # replit:
 #   title: "Examples"
-#   note: "The examples below send a GraphQL query using HTTP POST to <code>https://api.digitransit.fi/routing/v1/routers/hsl/index/graphql</code>. This example query asks the server to find a stop with the ID <i>HSL:1040129</i> and return its name, latitude and longitude coordinates, and whether is is accessible by wheelchair.<br/><b>Note:</b> If the examples provided do not return expected results, the stop id  may not be in use any more and you should try again with an existing id."
+#   note: "The examples below send a GraphQL query using HTTP POST to <code>https://api.digitransit.fi/routing/v2/hsl/gtfs/v1</code>. This example query asks the server to find a stop with the ID <i>HSL:1040129</i> and return its name, latitude and longitude coordinates, and whether is is accessible by wheelchair.<br/><b>Note:</b> If the examples provided do not return expected results, the stop id  may not be in use any more and you should try again with an existing id."
 #   embeds:
 #     -
 #       title: "Content-Type: application/graphql"
@@ -76,11 +76,11 @@ Global IDs in the Routing API are defined by [Relay](https://facebook.github.io/
 
 ### Interfaces
 
-GraphQL supports interfaces, which objects can implement by including fields required by the interface. Two interfaces used in the Routing API are **Node** (which has the field `id` used for global IDs) and **PlaceInterface**.
+GraphQL supports interfaces, which objects can implement by including fields required by the interface.
 
 If a query type returns an interface, [inline fragments](https://graphql.org/learn/queries/#inline-fragments) have to be used to access fields defined by the object implementing the interface.
 
-For example, query type **nearest** returns a list of **PlaceInterfaces** and types **BikePark** and **Stop** implement **PlaceInterface**.<br/>
+For example, query type **nearest** returns a list of **PlaceInterfaces** and types **VehicleParking** and **Stop** implement **PlaceInterface**.<br/>
 The following query returns field `spacesAvailable` for bike parks and field `code` for stops.
 ```graphql
 {
@@ -95,10 +95,10 @@ The following query returns field `spacesAvailable` for bike parks and field `co
               gtfsId
               code
             }
-            ...on BikePark {
+            ...on VehicleParking {
+              vehicleParkingId
               name
-              bikeParkId
-              spacesAvailable
+              bicyclePlaces
             }
           }
           distance
@@ -158,11 +158,11 @@ If the request includes multiple queries with same type, they must be renamed us
 
 ```graphql
 {
-  route1: route(id: "HSL:2550") {
+  route1: route(id: "HSL:1020") {
     shortName
     longName
   }
-  route2: route(id: "HSL:2551") {
+  route2: route(id: "HSL:1009") {
     shortName
     longName
   }

src/pages/en/developers/apis/1-routing-api/1-graphiql/index.md

@@ -13,9 +13,11 @@ order: 20
 
 ### There are a few options for using GraphiQL:
 
-1. Using our hosted browser versions for the three available regions. The browser versions have the correct endpoints configured already.
+1. Using our hosted browser versions for the five available regions. The browser versions have the correct endpoints configured already.
    * [Helsinki region](https://api.digitransit.fi/graphiql/hsl)
    * [Waltti regions](https://api.digitransit.fi/graphiql/waltti)
+   * [Waltti-Opas regions](https://api.digitransit.fi/graphiql/waltti-alt)
+   * [Seutu+ regions](https://api.digitransit.fi/graphiql/varely)
    * [Entire Finland](https://api.digitransit.fi/graphiql/finland)
 2. A browser extension like [ChromeiQL](https://chrome.google.com/webstore/detail/chromeiql/fkkiamalmpiidkljmicmjfbieiclmeij) (see regional endpoints below)
 3. For Mac OSX you can use [the desktop GraphiQL app](https://github.com/skevy/graphiql-app) (see regional endpoints below)
@@ -28,11 +30,13 @@ All options work similarly and their UI looks more or less like this (ChromeiQL
 
 1. If you are using the GraphiQL app or a browser extension, set the GraphQL Endpoint to one of the following:
 
-| Region          | Endpoint                                                             |
-|-----------------|----------------------------------------------------------------------|
-| Helsinki region | `https://api.digitransit.fi/routing/v1/routers/hsl/index/graphql`     |
-| Waltti regions  | `https://api.digitransit.fi/routing/v1/routers/waltti/index/graphql`  |
-| Entire Finland  | `https://api.digitransit.fi/routing/v1/routers/finland/index/graphql` |
+| Region              | Endpoint                                                                 |
+|---------------------|--------------------------------------------------------------------------|
+| Helsinki region     | `https://api.digitransit.fi/routing/v2/hsl/gtfs/v1`        |
+| Waltti regions      | `https://api.digitransit.fi/routing/v2/waltti/gtfs/v1`     |
+| Waltti-Opas region  | `https://api.digitransit.fi/routing/v2/waltti-alt/gtfs/v1` |
+| Seutu+ region       | `https://api.digitransit.fi/routing/v2/varely/gtfs/v1`     |
+| Entire Finland      | `https://api.digitransit.fi/routing/v2/finland/gtfs/v1`    |
 
 2. Click [this link](https://api.digitransit.fi/graphiql/hsl?query=%7B%0A%20%20stop(id%3A%20%22HSL%3A1040129%22)%20%7B%0A%20%20%20%20name%0A%20%20%20%20lat%0A%20%20%20%20lon%0A%20%20%20%20wheelchairBoarding%0A%20%20%7D%0A%7D) to run the query below in GraphiQL.
 

src/pages/en/developers/apis/1-routing-api/3-realtime-arrival-prediction/index.md

@@ -11,7 +11,9 @@ Basically real-time means prediction of arrival times. We know vehicle's planned
 ## How do I know when data is real-time?
 Real-time estimates are enabled by default when making itinerary planning requests. Availability of real-time estimates is not guaranteed, but field `realTime` (*true* / *false*) in each leg of the itinerary will indicate whether that leg's arrival / departure time is using real-time or static timetables. When using real-time, it means that uncertainty for arrival time is less than for purely static timetable data.
 
-Real-time estimates for itinerary planning can be turned off by using argument `ignoreRealtimeUpdates` of **plan** query. Setting this to true will only return times based on static timetables.
+Real-time estimates for itinerary planning can be turned off by using arguments `preferences: {transit: {timetable: {excludeRealTimeUpdates: true}}}` of **planConnection** query. Setting this to true will only return times based on static timetables.
+
+Departures that have been cancelled through a real-time feed can be included using the arguments `preferences: {transit: {timetable: {includeRealTimeCancelations: true}}}` of **planConnection**. This means that an itinerary can include a cancelled departure while some other alternative that contains no cancellations could be filtered out as the alternative containing a cancellation would normally be better.
 
 For stop timetables and route timetables, real-time estimates are available from fields `realtimeArrival` and `realtimeDeparture`. Note that these fields will have the static arrival / departure time by default and field `realtime` indicates whether the values of those fields have been updated from a real-time source.