wiki: describe the address search, the merged result list and the routing of the TREK services

This commit is contained in:
Maurice
2026-10-30 16:16:10 +01:00
parent deb125bedc
commit b98e530ffc
9 changed files with 73 additions and 34 deletions
+2 -2
View File
@@ -33,7 +33,7 @@ The trip addons are: **Lists**, **Costs**, **Documents**, **Collab** and **Tours
Each sub-toggle can be disabled independently while the parent addon remains enabled.
**Road trip** plans a trip as one continuous drive: search along the route, driving limits, daily travel times, via points and avoidance of toll roads, motorways and ferries. **Disabled by default.** It needs no key: routing runs on the public OSRM and Valhalla servers until you set your own under **User Defaults** (**Own routing engine**, **Own Valhalla instance**, restart required). See [Road-Trip](Road-Trip).
**Road trip** plans a trip as one continuous drive: search along the route, driving limits, daily travel times, via points and avoidance of toll roads, motorways and ferries. **Disabled by default.** It needs no key: routing runs on the Valhalla of the TREK services, with the public OSRM servers for a day it cannot answer (the public OSRM and Valhalla servers on an installation without the TREK services), until you set your own under **User Defaults** (**Own routing engine**, **Own Valhalla instance**, restart required). See [Road-Trip](Road-Trip).
**Tours** plans hikes, bike rides, ski tours, paddle tours (kayak, canoe, SUP) and other tours as tours of their own and adds them to the days of a trip. **Enabled by default.** Underneath its tile are four switches that decide which outside services Tours may use:
@@ -120,7 +120,7 @@ Some addons require credentials or environment variables before they are functio
- **Journey**: works without any external integration. To embed photos from Immich or Synology Photos, enable the corresponding photo-provider toggle listed under Journey, then configure credentials per-user in **Settings → Integrations**. See [Photo-Providers](Photo-Providers).
- **MCP**: requires `APP_URL` to be set so OAuth redirect URIs resolve correctly.
- **AI Assistant** and **AI Parsing**: need a connection, either one shared for everyone under **Set up AI** or one per person in **Settings → Integrations**.
- **Road trip**: works out of the box on the public routing servers. To use your own OSRM or Valhalla, set **Own routing engine** or **Own Valhalla instance** under **Admin → User Defaults**, then restart the server and reload the page. See [Road-Trip](Road-Trip#routing-engines).
- **Road trip**: works out of the box on the TREK services' Valhalla and the public routing servers. To use your own OSRM or Valhalla, set **Own routing engine** or **Own Valhalla instance** under **Admin → User Defaults**, then restart the server and reload the page. See [Road-Trip](Road-Trip#routing-engines).
- **Tours**: hikes need nothing more. For the obstacles on paddle tours, add the regions you paddle in under **Paddle water data** (see above), or let TREK load them.
## On a phone
+2 -2
View File
@@ -51,11 +51,11 @@ The address of an OSRM instance of your own, for example `https://osrm.example.o
Which Valhalla TREK asks, and with it how much of the routing Valhalla does.
- **Automatic** (nothing chosen): the TREK services, or **Own Valhalla instance** when one is set. If only **Own routing engine** is set, no Valhalla is asked.
- **TREK services**: the Valhalla at `valhalla.liketrek.com` (or `TREK_VALHALLA_URL`), a planet with elevation data. It calculates every route: the days of the planner and the road trip on foot, by bike and by car, driving around toll roads, motorways and ferries, and the routes, heights and ways of tours. This server asks it with the installation key, so the browser never talks to it and no restart is needed. Where it cannot answer (no key yet, the day's allowance spent, the service down or slow to answer, a shared page without a sign-in, or no way for one of the day's legs), OSRM calculates that day as it did before, without a message; a day is always calculated by one engine, never one leg by each, because the two estimate travel times differently. What only Valhalla can answer (avoiding road classes, tours) goes to the public FOSSGIS Valhalla instead. After such an answer TREK leaves the service alone for a while: a minute after an error or a question that took longer than ten seconds, as long as the service says when the allowance is spent (an hour at most). Each user may ask 60 routing questions a minute through this server, and the whole installation 100.
- **TREK services**: the Valhalla at `valhalla.liketrek.com` (or `TREK_VALHALLA_URL`), a planet with elevation data. It calculates every route: the days of the planner and the road trip on foot, by bike and by car, driving around toll roads, motorways and ferries, and the routes, heights and ways of tours. This server asks it with the installation key, so the browser never talks to it and no restart is needed. Where it cannot answer (no key yet, the day's allowance spent, the service unreachable or failing, a question that runs out its ten-second deadline, a shared page without a sign-in, or no way for one of the day's legs), OSRM calculates that day as it did before, without a message; a day is always calculated by one engine, never one leg by each, because the two estimate travel times differently. What only Valhalla can answer (avoiding road classes, tours) goes to the public FOSSGIS Valhalla instead, except a question that only ran out its deadline, which FOSSGIS would take as long over. Such a slow question, a very long bike route for example, is answered 504 and changes nothing for anyone else: the next question goes to the TREK services again. Only a host that cannot be reached or answers with a server error is left alone, for a minute on the server and ten minutes in a browser tab, and a spent allowance for as long as the service says (an hour at most). Each user may ask 60 routing questions a minute through this server, and the whole installation 100.
- **Public Valhalla (FOSSGIS)**: `valhalla1.openstreetmap.de`, as before: OSRM calculates the routes, and Valhalla only answers what OSRM cannot (driving around toll roads, motorways and ferries, and tours). This is also what an installation without the TREK services gets.
- **Own Valhalla instance**: the address below. Like the TREK services it calculates every route, with OSRM taking over a day it cannot answer.
A day longer than one request may carry is asked in pieces that share a stop: twenty stops a piece on the TREK services and an own Valhalla, ten on FOSSGIS.
A day longer than one request may carry is asked in pieces that share a stop: twenty stops a piece on the TREK services and an own Valhalla, one after another without a pause, and ten on FOSSGIS, paced to its one request a second. A day cut for the TREK services that ends up at FOSSGIS is cut again into pieces of ten.
Routes the browser has kept on the device are kept per engine, so switching the routing service never shows a day calculated by the other engine.
+1 -1
View File
@@ -66,7 +66,7 @@ See the [[Development Environment|Development-environment]] page for the full se
| Real-time | WebSocket (ws) |
| Database | SQLite with WAL mode |
| Auth | JWT (HS256), bcrypt, TOTP MFA, passkeys (WebAuthn), OIDC |
| Maps | Leaflet + react-leaflet (default, OpenFreeMap vector basemap via maplibre-gl-leaflet), MapLibre GL 5, Mapbox GL 3, OSRM, Nominatim |
| Maps | Leaflet + react-leaflet (default, OpenFreeMap vector basemap via maplibre-gl-leaflet), MapLibre GL 5, Mapbox GL 3, Valhalla, OSRM, Photon, Nominatim |
| i18n | 27 languages, EN canonical (locale directories live in shared/src/i18n/) |
Documentation changes go to `wiki/`. The same pages ship inside the app: the in-app help reads them (served under `/api/help`) and links into them, and the MCP help tools search them, so a wiki edit reaches users with the next release as well as the GitHub wiki.
+3 -3
View File
@@ -394,7 +394,7 @@ TREK's own place index, the [TREK Places API](TREK-Places-API), answers the sugg
| `TREK_SERVICES` | `auto` lets the installation register itself with the TREK services on first use and keep its key in the database; `off` sends no key, and searches use the shared pool. See [Installation key and daily allowance](TREK-Places-API#installation-key-and-daily-allowance). | `auto` |
| `TREK_SERVICES_KEY` | A key issued to you for this installation. Wins over the stored key and turns self-registration off. A value that is not a key aborts startup. | none |
| `TREK_SERVICES_HOSTS` | Comma-separated hosts that receive the installation key over https. | `places.liketrek.com,photon.liketrek.com,valhalla.liketrek.com` |
| `TREK_PHOTON_URL` | The address search of the TREK services, a [Photon](https://github.com/komoot/photon) instance. Once the installation holds a key, the OpenStreetMap search and the reverse lookups ask it before Nominatim and fall back to Nominatim whenever it does not answer. It is never asked with `TREK_SERVICES=off`, without a key, or when `NOMINATIM_URL` is set. See [Address search](TREK-Places-API#address-search). | `https://photon.liketrek.com` |
| `TREK_PHOTON_URL` | The address search of the TREK services, a [Photon](https://github.com/komoot/photon) instance. Once the installation holds a key it is the geocoder in place of Nominatim: the OpenStreetMap half of search and suggestions, import geocoding, the right-click on the map and pasted map links, matching a Google place to its OpenStreetMap record and naming an opened OpenStreetMap place. An empty answer is the answer, and so is a miss (an error, a timeout, a refused key or a spent allowance): Nominatim is not asked in its place. It is never asked with `TREK_SERVICES=off`, without a key, or when `NOMINATIM_URL` is set. See [Address search](TREK-Places-API#address-search). | `https://photon.liketrek.com` |
| `TREK_VALHALLA_URL` | The Valhalla of the TREK services. Routes, elevation and the description of a line go there unless the admin picks another routing service under Admin, Default user settings; this server relays them with the installation key, so the browser never talks to it. A trailing slash is stripped, and a value that is not a full URL aborts startup. | `https://valhalla.liketrek.com` |
On Helm these go under `env:` in `values.yaml`, except `TREK_SERVICES_KEY`, which goes under `secretEnv:`. The chart passes `TREK_PLACES_ENABLED` through whenever it is set at all, so an unquoted `false` or `--set env.TREK_PLACES_ENABLED=false` reaches the container as well.
@@ -508,14 +508,14 @@ next key rotation or admin reset would quietly switch the file back to WAL.
| Variable | Description | Default |
|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------|
| `IDEMPOTENCY_TTL_SECONDS` | How long (in seconds) stored idempotency keys are kept before garbage collection. The offline client replays queued mutations with their `X-Idempotency-Key` on reconnect, so this must exceed the longest expected offline window or a replay could create a duplicate. Invalid values abort startup. | `2592000` (30 days) |
| `NOMINATIM_URL` | Custom HTTP(S) Nominatim base URL for every geocoding call the server makes: place search, reverse lookup, place details and the Atlas region fill. When set it **replaces** the public OpenStreetMap service for all of them, with no fallback, so point it at an instance whose import covers the places your users plan and that speaks the Nominatim API (`/search`, `/reverse`, `/lookup`). Photon, Geoapify and LocationIQ are not drop-in replacements. TREK keeps its client-side spacing of roughly one request a second whichever instance answers, so this changes where the requests go, not how fast they are sent. Unset or blank uses the default. With the TREK Places API on, suggestions while typing come from the TREK API's own OpenStreetMap layer and reach Nominatim only when the TREK API has nothing. Set, it also keeps search and reverse lookups off the TREK services' Photon (see `TREK_PHOTON_URL`). | `https://nominatim.openstreetmap.org` |
| `NOMINATIM_URL` | Custom HTTP(S) Nominatim base URL for every geocoding call the server makes: place search, reverse lookup, place details and the Atlas region fill. When set it **replaces** the public OpenStreetMap service for all of them, with no fallback, so point it at an instance whose import covers the places your users plan and that speaks the Nominatim API (`/search`, `/reverse`, `/lookup`). Photon, Geoapify and LocationIQ are not drop-in replacements. TREK keeps its client-side spacing of roughly one request a second whichever instance answers, so this changes where the requests go, not how fast they are sent. Unset or blank uses the default, which is then asked only by an installation without the TREK services (no key yet, or `TREK_SERVICES=off`) and for a search the TREK services' address search does not answer at all: with a key, that address search geocodes instead (see `TREK_PHOTON_URL`). Set, it keeps every geocoding call off the address search and on your Nominatim, as before. With the TREK Places API on, suggestions while typing come from the TREK API, beside the address search where the installation has a key; without a key they reach Nominatim only when the TREK API has nothing. | `https://nominatim.openstreetmap.org` |
| `OVERPASS_URL` | Custom [Overpass API](https://wiki.openstreetmap.org/wiki/Overpass_API) endpoint(s), comma-separated, for the map's category buttons, the Road trip search along the drive and the `search_pois` MCP tool whenever the TREK Places API has no answer or is switched off. When set it **replaces** the bundled public mirrors: point it at an internal or self-hosted Overpass instance when the public mirrors are unreachable from your network (e.g. firewalled/locked-down egress in a Kubernetes cluster). Entries that aren't valid `http(s)` URLs are ignored. If you don't run your own Overpass but the public mirrors throttle TREK, first make sure `APP_URL` (or `ALLOWED_ORIGINS`) is set: that alone gives outbound Overpass/Nominatim requests a unique User-Agent, which the public mirrors rate-limit far less. One request is not covered: the tag lookup behind an OpenStreetMap place's details (website, phone, Wikidata) still goes to `overpass-api.de` whatever this is set to, and where that host is unreachable those details fall back to the tags Nominatim returns. | bundled public mirrors |
| `OVERPASS_TIMEOUT_MS` | Per-endpoint timeout (in milliseconds) for Overpass POI requests. Endpoints race in parallel and one that hasn't answered within this window is abandoned so a faster mirror can win. The query itself gives Overpass 20 seconds of work, so a lower value hangs up on answers that were still coming; that is why the default rose from `12000` in 4.3.0. Drop any lower value you set by hand, and raise it only for a slow self-hosted Overpass instance. The Tours search along a tour does not read it: it gives Overpass 10 seconds of work and waits 12, because someone is waiting for the list. Invalid values abort startup. | `25000` |
| `LLM_TIMEOUT_MS` | How long (in milliseconds) one AI-parsing call may take before it is abandoned. One ceiling for every provider, applied to the abort signal and to the underlying HTTP client alike. The default is generous so heavier parsing work fits without a code change; lower it if you use a cloud provider and would rather fail fast. Invalid values abort startup. | `900000` (15 min) |
| `LLM_MAX_OUTPUT_TOKENS` | The longest answer (in tokens) one AI-parsing call may ask the model for, sent to every provider. A document with many bookings needs a long answer; when the model hits the cap the import says so and names this variable. Raise it for such documents, but keep prompt plus cap inside the context your model has, or the server refuses the request. Unset keeps each provider's own cap. A whole number from 256 to 1000000, anything else aborts startup. | `4096` (OpenAI-compatible), `8192` (Anthropic) |
| `GOOGLE_LIST_DATA_BASE` | HTTP(S) base URL of a list-data service. A pasted URL starting with this base is fetched and parsed directly; the URL's origin must also match the base so a lookalike host cannot bypass the URL guard. A failed direct import reports an error without falling back to Google. Unset or a nonmatching URL uses the original Google flow. | Unset |
> **Routing is not set here.** The routing engines behind the planner and the [Road-Trip](Road-Trip) addon (OSRM for routes, Valhalla for avoiding toll roads, motorways and ferries) have no environment variable. An admin sets them under **Admin → User Defaults** as **Own routing engine** and **Own Valhalla instance**, and they take effect after a restart. `OVERPASS_URL` and `OVERPASS_TIMEOUT_MS` above also apply to the road trip's search along the route.
> **Routing is mostly not set here.** With the TREK services, their Valhalla calculates every route TREK draws and OSRM takes over a day it cannot answer; `TREK_VALHALLA_URL` only points at another copy of it. Engines of your own are set by an admin under **Admin → User Defaults** as **Routing service**, **Own routing engine** and **Own Valhalla instance**, and they take effect after a restart. `OVERPASS_URL` and `OVERPASS_TIMEOUT_MS` above also apply to the road trip's search along the route.
---
+3 -3
View File
@@ -61,7 +61,7 @@ Markers that [plugins](Places-and-Search#categories-from-plugins) put on the map
A day's route is drawn as a solid blue line, a bright core over a darker casing in the look Apple Maps uses, through that day's stops in the order you arranged them. It is not on automatically: switch it on with **Route** in the route bar of the selected day (see [Day Plans and Notes](Day-Plans-and-Notes#the-route-bar)), or in the day sheet on a phone. The choice is remembered per trip in your browser, and the phone's map turns it on by default the first time you open a trip you have not decided on.
A straight line is drawn immediately, then upgraded to real road geometry from a public OSRM router (or from a plugin route profile), each leg routed in the travel mode that leg carries: driving, walking or cycling. If routing fails, that leg stays a straight line between the two stops.
A straight line is drawn immediately, then upgraded to real road geometry from the router, or from a plugin route profile, each leg routed in the travel mode that leg carries: driving, walking or cycling. With the TREK services the router is their [Valhalla](TREK-Places-API#routing), and OSRM draws only a day it cannot answer; without them it is a public OSRM router. See [Road-Trip](Road-Trip#routing-engines). If routing fails, that leg stays a straight line between the two stops.
A leg you walk is drawn as a dotted line in the same colour, without the casing, so the drive stands apart from the stretches on foot.
@@ -105,14 +105,14 @@ Travel times are not drawn on the map; they sit in the day plan. Switch a day's
Each leg carries its own mode, so a day routed by car can still have one leg you walk. If you may edit the day, clicking a connector (*Change travel mode*) opens the mode menu for that leg alone, with **Public transit** on a trip with dates. See [Route Optimization](Route-Optimization#route-calculation).
Car, foot and bicycle times come from a public OSRM router, so they follow real roads, footpaths and cycle routes instead of straight-line estimates. A plugin route profile is answered by the plugin's own route provider instead, which is what lets it fold in things like charging stops; those legs can add a short note next to the distance. When routing is unavailable the leg falls back to a straight line and shows no time.
Car, foot and bicycle times come from the same router as the route line (the Valhalla of the TREK services, OSRM for a day it cannot answer or without them), so they follow real roads, footpaths and cycle routes instead of straight-line estimates. A plugin route profile is answered by the plugin's own route provider instead, which is what lets it fold in things like charging stops; those legs can add a short note next to the distance. When routing is unavailable the leg falls back to a straight line and shows no time.
## Reservation and transport overlay
Flights, trains, cars, cruises and other bookings with a start and an end point can be drawn as routes between those points. Booking routes are **off by default**. Switch one on with the route button of its row in the days column (*Show booking routes*), or on its badge under the place it is pinned to, or use one of the bulk options below. **On map** in the booking's detail does the same and opens the plan on the booking's day; pressed again, it switches the route off. The selection is remembered per trip in your browser.
- **Flights, cruises and ferries:** geodesic great-circle arcs.
- **Cars, buses, taxis and bicycles:** real routed lines that follow actual roads, fetched on demand from a public OSRM router (driving for car, bus and taxi, cycling for bicycle). A straight line is shown while the route loads, and kept if routing fails or the trip is very long (about 2,000 km or more).
- **Cars, buses, taxis and bicycles:** real routed lines that follow actual roads, fetched on demand from the same router as the day's route (driving for car, bus and taxi, cycling for bicycle). A straight line is shown while the route loads, and kept if routing fails or the trip is very long (about 2,000 km or more).
- **Trains:** a straight line between the endpoints; a multi-leg train draws its whole station chain (from, stop, to).
- **Cable cars and gondolas**, and bookings of the type **Other**: a straight line between the endpoints.
- **Automated public transit:** a journey added from the transit search draws its real rail and bus alignment instead of a straight line: each ride leg in its line's own colour over a white casing, walking transfers as a dotted grey line. A journey whose provider sent no shape falls back to a straight line. Unlike every other type it has no route button of its own in the days column. It is drawn when the day's own **Route** is on and the journey runs on that day, and independently of that by the bulk button, the account-wide default, or **On map** in its detail. Because those are two separate gates, **Hide all booking routes** does not clear a transit journey while that day's **Route** is still on.
+21 -4
View File
@@ -104,15 +104,15 @@ Deleting the place deletes its linked expenses too, the same way deleting a book
## Searching for a place
Place search needs no API key. Two sources answer it together: the **TREK API**, TREK's own index of 73.6 million places, and **OpenStreetMap**. The index is strongest on businesses such as restaurants, shops and hotels; OpenStreetMap is where the temples, bridges, viewpoints and stations are. What the index is, where its data comes from and what TREK sends to it is on its own page: [TREK Places API](TREK-Places-API).
Place search needs no API key. Two sources answer it together: the **TREK API**, TREK's own index of 73.6 million places, and **OpenStreetMap**, asked through the address search of the TREK services where the installation has a key and through Nominatim where it has none (see [Address search](TREK-Places-API#address-search)). The index is strongest on businesses such as restaurants, shops and hotels; OpenStreetMap is where the temples, bridges, viewpoints and stations are. What the index is, where its data comes from and what TREK sends to it is on its own page: [TREK Places API](TREK-Places-API).
### Suggestions while you type
After two or more characters and a 300 ms pause, suggestions appear under the search field of the place form.
- Use **↑ / ↓** to move through them, **Enter** to pick one, **Esc** to close the list.
- Suggestions come from the TREK API, from its index and from an OpenStreetMap layer it keeps. A suggestion from that layer shows the name that matched what you typed, with the name used on the spot underneath when the two differ.
- Only when the TREK API has nothing does TREK ask the keyed provider (Google or Amap), or, without one, OpenStreetMap's own search service.
- Suggestions come from the TREK API, from its index and from an OpenStreetMap layer it keeps, and from the address search of the TREK services asked at the same time. A suggestion from the layer shows the name that matched what you typed, with the name used on the spot underneath when the two differ. How the rows are ordered is described in [How the list is put together](#how-the-list-is-put-together).
- Only when both have nothing does TREK ask the keyed provider (Google or Amap), or, without one, OpenStreetMap's search on its own.
- An installed [search plugin](Plugin-Cookbook#suggestions-while-the-user-types) whose index can keep up with typing adds up to three of its places under the suggestions, marked with the plugin's name. Picking one fills in what the plugin knows about the place, with no second lookup.
### Language of place names
@@ -121,12 +121,29 @@ By default, search, suggestions and addresses answer in the language TREK is set
### The full search
Press **Enter** without picking a suggestion, or click the search button beside the field, to run a full search. It asks the TREK API and OpenStreetMap at the same time and interleaves their answers, TREK first, up to ten results. A place both of them know (within 60 metres, with a matching name) is listed once.
Press **Enter** without picking a suggestion, or click the search button beside the field, to run a full search. It asks the TREK API and OpenStreetMap at the same time and merges their answers the same way as the suggestions, up to ten results; see [How the list is put together](#how-the-list-is-put-together).
A Google or Amap key does not change this. The keyed provider is asked only when the TREK API and OpenStreetMap both come back empty; see [Google and Amap](#google-and-amap).
Installed [search plugins](Plugin-Cookbook#answer-place-searches-from-your-own-index) add their results below the core list. Only the ones built for it also answer while you type; the others appear here, once the search is run.
### How the list is put together
The suggestions and the full search build their list the same way, so the two agree on what a name means.
1. **Both are asked at once:** the index with its OpenStreetMap layer, and the address search of the TREK services. Its hits are ranked with places that have a Wikidata link before their unlinked namesakes, and streets, unlinked shops and unlinked artworks step back: "Neuschwanstein" opens on the castle, not on an artwork of that name. It leans towards the area you are planning (see [The open day steers the search](#the-open-day-steers-the-search)), more narrowly than before, so a namesake 50 km away no longer passes the real place. On an installation without a key Nominatim answers in its place, and the list has no lead.
2. **The list opens on a lead** when the address search's answer has one:
- a country or a region, always;
- a town, an island or a sight with a Wikidata link, when it is called what you typed (or a typo of it: one letter wrong, two in a name of eight letters or more), lies within 1000 km of where you are looking, and no place of that name ranks above it. With no hint at all, a town, an island or a sight leads; a municipality or a county does not.
3. **The rest alternate**, index and OpenStreetMap, the index first.
4. **Doubles go:** a place both sources know (within 60 metres, with a matching name) is listed once, as the index's copy; rows of the lead's own name inside its area go, so "Berlin" no longer opens on a business filed as "Berlin" in Berlin; the same element under two ids is shown once; and rows that read the same, with the same name and the same line below it, are shown once.
A three-letter code in capitals, such as `JFK` or `LHR`, is looked up in TREK's bundled airport list and asked for as that airport at its place, which then leads. Typed in lower case it stays an ordinary search, so `ber` on the way to "Berlin" still finds Berlin.
The line below a row from the address search shows the street, the quarter, the town and the country, and the region only where there is no town. It never shows the postcode or the county.
Measured on 5000 places from Wikidata, the right place came first while typing 65 percent of the time, against 48 before; in the full search 68 percent against 53; for cities 88 against 65; for countries 99 against 44. Rows that read the same twice are gone.
### Where each result came from
Every row, in the suggestions and in the search results, on the desktop and on the phone, carries a small mark naming its source: **TREK**, **OpenStreetMap**, **Google** or **Amap** (高德地图, or 高德地圖 in traditional Chinese), and for a row from a search plugin the name the plugin was installed under. A list that mixes several sources stays readable that way. Results from the offline cache carry no mark; see [Searching offline](#searching-offline).
+5 -5
View File
@@ -233,9 +233,9 @@ Routing uses two engines, and both have public defaults, so the addon works with
| **Valhalla** | with the TREK services or an own Valhalla: every road route TREK draws (the road trip, the day plan, the routed booking lines) on foot, by bike and by car, and the other ways of a leg. With the public FOSSGIS Valhalla only driving around toll roads, motorways and ferries, and the **No motorway**, **No tolls** and **No ferry** offers | the TREK services' Valhalla through this server (**Routing service**), the FOSSGIS Valhalla at `valhalla1.openstreetmap.de` where they are off | **Own Valhalla instance** |
| **OSRM** | every day Valhalla does not calculate: all of them with the public FOSSGIS Valhalla or without a Valhalla, and a day the TREK services or an own Valhalla cannot answer | the FOSSGIS servers at `routing.openstreetmap.de` | **Own routing engine** |
A day is always calculated by one engine, never one leg by each: the two estimate travel times differently, and a day's arrival times are added up leg by leg. When Valhalla cannot answer a day (the service down or its allowance spent, or no way for one of its legs), OSRM calculates the whole day instead, without a message, and TREK asks Valhalla again for the next day it routes once the service has rested (see [Admin-User-Defaults](Admin-User-Defaults#routing-service)). A day that avoids road classes still goes to the public FOSSGIS Valhalla in that case, since OSRM cannot avoid them.
A day is always calculated by one engine, never one leg by each: the two estimate travel times differently, and a day's arrival times are added up leg by leg. When Valhalla cannot answer a day (the service down or its allowance spent, a question that ran out its deadline, or no way for one of its legs), OSRM calculates the whole day instead, without a message. A question that only took too long, a very long bike route for example, costs that one day: the TREK services are asked again for the next. A host that cannot be reached or fails is left to rest first (see [Admin-User-Defaults](Admin-User-Defaults#routing-service)). A day that avoids road classes still goes to the public FOSSGIS Valhalla when the TREK services cannot answer, since OSRM cannot avoid them.
The public OSRM servers allow roughly one request a second. That is enough for a day plan and tight for a road trip, which routes every leg of every day: TREK spaces its requests and retries a refused one, but a long trip takes a while to fill in. An instance with many road trippers is better off with its own.
The public OSRM servers allow roughly one request a second, and so does the FOSSGIS Valhalla. That is enough for a day plan and tight for a road trip, which routes every leg of every day: TREK spaces its requests to those hosts 1.1 seconds apart and retries a refused one, but a long trip takes a while to fill in. An instance with many road trippers is better off with the TREK services or engines of its own. The relay keeps its connection to the TREK services open between questions, and the server, routing for the [MCP tools](#mcp-tools), asks the relay, an own OSRM and an own Valhalla without that spacing.
> **Admin:** Set your own engines under **Admin → User Defaults**, in the **Map** section, on the desktop or the phone: **Own routing engine** for OSRM, **Own Valhalla instance** for Valhalla. A value saves when you leave the field, and **reset** restores the public default. Then **restart the server and reload the page.** Only an admin can set them; they apply to everyone.
@@ -256,7 +256,7 @@ Choosing **Public Valhalla (FOSSGIS)** as **Routing service** keeps OSRM for eve
Requirements for your own instances:
- **OSRM** must serve the standard layout, `<address>/route/v1/<profile>/…`, which `osrm-routed` does out of the box. It answers every route in TREK that Valhalla does not, not only road trips. The public servers refuse to exclude road classes; an OSRM of your own built through the MLD pipeline, with a profile that has those classes, can answer **No motorway** and **No tolls** in **Other ways** by itself.
- **Valhalla** of your own answers every route, so it needs the `auto`, `pedestrian` and `bicycle` costings and should take twenty locations a request (`max_locations`, Valhalla's own default for `auto`); a longer day is asked in pieces of twenty that share a stop.
- **Valhalla** of your own answers every route, so it needs the `auto`, `pedestrian` and `bicycle` costings and should take twenty locations a request (`max_locations`, Valhalla's own default for `auto`); a longer day is asked in pieces of twenty that share a stop, one after another without a pause. Only a piece that goes to the public FOSSGIS Valhalla is cut to ten stops and paced.
- **Reachable from the browser.** The browser calls the engine directly, so the address has to work from the devices your travellers plan on, not only from the TREK server. `http://localhost:5000` means the traveller's own computer to a browser. When TREK is served over HTTPS, the engine has to be HTTPS too, or the browser blocks it as mixed content.
- **Reachable from the TREK server** for the [MCP tools](#mcp-tools), which calculate on the server. An address on your local network is accepted there without `ALLOW_INTERNAL_NETWORK`, because only an admin can set it.
@@ -399,10 +399,10 @@ What TREK contacts, and from where:
| Service | Asked by | When | To change it |
|---|---|---|---|
| TREK services' Valhalla (`valhalla.liketrek.com` by default) | the TREK server, for the browser and for MCP | every route | **Routing service**, or `TREK_VALHALLA_URL` |
| TREK services' Valhalla (`valhalla.liketrek.com` by default) | the TREK server, for the browser and for MCP | every route; it receives the stops' coordinates in order, the travel mode and the road classes to avoid, with the installation key, and no user or trip | **Routing service**, or `TREK_VALHALLA_URL` |
| OSRM (`routing.openstreetmap.de` by default) | the browser, and the TREK server for MCP | every route Valhalla does not calculate | **Own routing engine** |
| Valhalla (`valhalla1.openstreetmap.de`) | the browser, and the TREK server for MCP | with **Public Valhalla (FOSSGIS)**, or where the TREK services cannot answer: only when avoiding road classes or offering **No motorway**, **No tolls**, **No ferry** | **Own Valhalla instance**, or not at all once only **Own routing engine** is set |
| TREK's place index and OpenStreetMap | the TREK server | the search along the route (OpenStreetMap through Overpass), and the place lookups of **Add manually** and the Google import (the usual place search) | see [TREK-Places-API](TREK-Places-API) and [Places-and-Search](Places-and-Search), and `OVERPASS_URL` and `NOMINATIM_URL` in [Environment-Variables](Environment-Variables) |
| TREK's place index and OpenStreetMap | the TREK server | the search along the route (OpenStreetMap through Overpass), and the place lookups of **Add manually** and the Google import (the usual place search: the index, then the address search of the TREK services, or Nominatim without them) | see [TREK-Places-API](TREK-Places-API) and [Places-and-Search](Places-and-Search), and `OVERPASS_URL`, `NOMINATIM_URL` and `TREK_PHOTON_URL` in [Environment-Variables](Environment-Variables) |
| MobiData BW OCPDB | the TREK server | when a charging stop's data is shown | |
| DWD and GDACS | the TREK server | only with **Show hazard areas** on | switch it off |
| Google short links (`maps.app.goo.gl`) | the TREK server | only to unfold a short link during the Google import | |
+35 -13
View File
@@ -1,10 +1,10 @@
# TREK Places API
The TREK Places API is TREK's own place index. It answers place search, the suggestions under the search box, the details of a place picked from it, the category buttons on the map and the geocoding behind imports, with no API key to enter and no account. Every installation gets a fair daily allowance, counted by the number of requests only. In the app it is called the **TREK API**, and a result that came from it carries a **TREK** mark.
The TREK Places API is TREK's own place index. It answers place search, the suggestions under the search box, the details of a place picked from it, the category buttons on the map and the geocoding behind imports, with no API key to enter and no account. Two more services sit beside it under the same [installation key](#installation-key-and-daily-allowance): an [address search](#address-search) of OpenStreetMap (Photon, at `photon.liketrek.com`) and [routing](#routing) (Valhalla, at `valhalla.liketrek.com`). Every installation gets a fair daily allowance on each, counted by the number of requests only. In the app the three together are called the **TREK API**, and a result that came from the index carries a **TREK** mark.
It does not replace OpenStreetMap. A search asks both and shows their results together, because each is good at what the other lacks: the index is strongest on businesses such as restaurants, shops and hotels, and OpenStreetMap is where the temples, bridges, viewpoints and stations are. How the two meet in the search box is described in [Places and Search](Places-and-Search).
> **Admin:** there is nothing to set up. The index is on by default on every install and has no switch in the admin panel: whether searches leave the instance is a property of the deployment, so it is decided with environment variables (see [Switching it off](#switching-it-off) and [Running your own copy](#running-your-own-copy)), where a second admin cannot flip it from a browser. **Admin → Settings → API Keys** opens with its card, marked **Recommended default**, and **What is in it** on that card lists the fields and sources described below.
> **Admin:** there is nothing to set up. The index is on by default on every install and has no switch in the admin panel: whether searches leave the instance is a property of the deployment, so it is decided with environment variables (see [Switching it off](#switching-it-off) and [Running your own copy](#running-your-own-copy)), where a second admin cannot flip it from a browser. **Admin → Settings → API Keys** opens with its card, marked **Recommended default**. It names the three services with a few facts about each and shows the allowance of each as tiles: what is left, what was used and the limit. **What is in it** lists one block per service: the fields of a place described below; for the address search streets and house numbers, towns and regions, the address of a point and 26 languages; for routing by car, by bike, on foot, avoiding tolls, motorways and ferries, and an elevation profile. The sources under it are Overture Maps Foundation, OpenStreetMap, Wikivoyage, Wikimedia and Mapzen Terrain Tiles, which the heights of routes come from.
## What it is
@@ -30,22 +30,22 @@ Names are the ones the index has, which are the names used on the spot. The inde
| Where | What the TREK API does | When it has no answer or cannot be reached |
|---|---|---|
| Suggestions while typing | Answers on its own, from the index and its OpenStreetMap layer | Google or Amap when one holds the keyed slot, otherwise OpenStreetMap's search service (Nominatim) |
| Full search (search button or **Enter**) | Asked together with OpenStreetMap; the two lists are interleaved, TREK first | OpenStreetMap's answer on its own; the keyed provider only when both are empty |
| Suggestions while typing | Asked together with the [address search](#address-search), from the index and its OpenStreetMap layer; see [How the list is put together](Places-and-Search#how-the-list-is-put-together) | The address search's answer on its own; Google or Amap when both are empty and one holds the keyed slot, otherwise OpenStreetMap (the address search, or Nominatim on an installation without a key) |
| Full search (search button or **Enter**) | Asked together with OpenStreetMap (the address search, or Nominatim without a key), merged the same way as the suggestions | OpenStreetMap's answer on its own; the keyed provider only when both are empty |
| Opening a place picked from it | Address, contact details, opening hours and description | The place keeps what was saved with it |
| Category buttons on the trip map | Places of that category around the map centre | The public Overpass mirrors of OpenStreetMap |
| The [Road trip](Road-Trip#search-along-the-route) addon's search along the drive | Fuel, charging, rest areas, campsites and the other kinds it looks for | The public Overpass mirrors |
| Tours: the trail grades, surfaces and kinds of way along a planned tour | The OpenStreetMap tags of the ways the tour runs on, from its ways layer | The public Overpass mirrors |
| Tours: the signposted horse routes around the map view | The horse route relations in the view with their ways, from its routes layer | The public Overpass mirrors |
| Tours: the ski piste router (**Ski & winter** tours) | The winter layer: which build it serves, the index of ski areas, and the graph of runs, lifts and trails of one area, which your server keeps and checks once a day | A ski area already kept on your server still plans; a leg that cannot be planned gets a red row, *The piste data cannot be reached right now.*, with **Draw straight** |
| Booking imports, and stops given only by name in an imported Google Maps route | The coordinate of a venue, found by its name | OpenStreetMap's search service, which also resolves street addresses |
| Booking imports, and stops given only by name in an imported Google Maps route | The coordinate of a venue, found by its name | The [address search](#address-search), which also resolves street addresses; Nominatim on an installation without a key |
| Preparing a trip for offline use | Up to 3000 places around the trip, in one request | Nothing is cached, and offline search has nothing to answer from |
| MCP: `search_place` and `search_pois` | The same as the full search and the category buttons | The same fallbacks |
| Places near a point (**Places near this pin** in the place form, `POST /api/maps/nearby`, `search_nearby_places`) | Named places of any kind around the point, nearest first | Google Places when the index has nothing and a key exists, OpenStreetMap otherwise |
Where Google holds the keyed slot (a Google key, with neither Amap nor OpenStreetMap picked as the places provider), two things skip the index and OpenStreetMap for a search: the **Search Google instead** line under a result list (`provider: 'google'` on `search_place`) sends that one search to Google Places alone, and the admin switch **Search with Google only** sends every search and every suggestion there, `search_place` and **Places near this pin** included; the category buttons and `search_pois` keep asking the index. See [Google and Amap](Places-and-Search#google-and-amap).
Right-click reverse geocoding on the map does not use it: that is OpenStreetMap's (or Amap's inside mainland China, when Amap holds the keyed slot), through the [address search](#address-search) where the installation has a key.
Right-click reverse geocoding on the map and the name of a pasted map link do not use the index: they ask the [address search](#address-search) where the installation has a key, Nominatim where it has none. Inside mainland China the right-click asks Amap when Amap holds the keyed slot.
### Why two sources
@@ -69,7 +69,7 @@ On its first search an installation registers itself with the service in the bac
The key carries a random installation id and nothing else: no address, no host name, no user. It lets the service give each installation its own daily allowance instead of one pool per network, and it is sent only to the hosts in `TREK_SERVICES_HOSTS` (`places.liketrek.com`, `photon.liketrek.com` and `valhalla.liketrek.com` by default), never to a copy you run yourself or anywhere else.
**Admin → Settings → API Keys** shows on the card how this installation stands: connected, setting up its key, on the shared pool, switched off or revoked, with today's use, what is left and when the count starts again. **New identity** drops the key and asks for a new one; use it after cloning an installation onto a second machine, or after the key was revoked. Requests are counted per installation and, independently, per network; the counters are deleted after two days. Search terms and coordinates are never logged.
**Admin → Settings → API Keys** shows on the card how this installation stands: connected, setting up its key, on the shared pool, switched off or revoked, with today's use, what is left and the limit of each service, and when the count starts again. **New identity** drops the key and asks for a new one; use it after cloning an installation onto a second machine, or after the key was revoked. Requests are counted per installation and, independently, per network; the counters are deleted after two days. Search terms and coordinates are never logged.
| Variable | What it does |
|---|---|
@@ -81,11 +81,29 @@ An installation pointed at its own copy with `TREK_PLACES_URL`, or with `TREK_PL
## Address search
Where the installation holds a key, the OpenStreetMap half of the search, the suggestions of an install without the index or a key, the right-click on the map and the name of a pasted map link ask the address search of the TREK services first: a [Photon](https://github.com/komoot/photon) instance at `photon.liketrek.com` with a planet-wide import of OpenStreetMap. Nominatim stays behind it. A refused key, a spent allowance, an error, no answer within 2.5 seconds, or nothing found all go to Nominatim, so the result reads the same either way. After four misses in a row TREK asks Nominatim alone for a minute; a spent allowance that says when it comes back is waited out instead, for an hour at most. Imports that look up many points in a row (the venues of a booking, the stops of a route link, the addresses of imported places) go to Nominatim alone and leave the allowance to the people searching.
Where the installation holds a key, OpenStreetMap is asked through the address search of the TREK services: a [Photon](https://github.com/komoot/photon) instance at `photon.liketrek.com` with a planet-wide import of OpenStreetMap. It is then the installation's geocoder, and Nominatim is not asked beside it, nor when it finds nothing: an empty answer is the answer. It answers:
It is asked in the language TREK is set to, without its region (`pt-BR` asks in Portuguese, `zh-TW` in Chinese), where the import holds names in that language: Arabic, Azerbaijani, Catalan, Chinese, Czech, Dutch, English, Estonian, French, German, Greek, Hungarian, Indonesian, Italian, Japanese, Korean, Polish, Portuguese, Russian, Slovak, Spanish, Swedish, Thai, Turkish, Ukrainian and Vietnamese. Any other language gets the names used on the spot. Opening a place and matching a Google place to its OpenStreetMap record stay on Nominatim.
- **Search and suggestions:** the OpenStreetMap half of the full search and of the suggestions while typing. How its hits are ranked and merged with the index is described in [How the list is put together](Places-and-Search#how-the-list-is-put-together).
- **Imports:** the venues of a booking, the stops of a route link and the addresses of imported places, asked after the index.
- **A point on the map:** the right-click on the map and the name of a pasted map link. When nothing lies next to the point, it is asked once more within 50 km; nothing there either leaves the name and address empty.
- **Matching a Google place to its OpenStreetMap record**, for the record's Wikidata, Wikipedia and Commons tags: inside a box of about 2 km around the place, a place with a Wikidata link before an unlinked one, and a station or road of the same name after the place itself unless the name asked for one (*Hauptbahnhof*, *Tor station*).
- **Opening an OpenStreetMap place:** Overpass gives the element's tags and where it lies, and the address search names it and writes its address. Nominatim is asked only when Overpass cannot place the element.
It sends the words searched, the coordinate a search is ranked around, the point of a reverse lookup and that language, with the installation key and the `User-Agent` and nothing else. There is no shared pool: without a key, with `TREK_SERVICES=off`, or with `NOMINATIM_URL` set to a Nominatim of your own, TREK never asks it and searches the way it did before. `TREK_PHOTON_URL` points at another copy.
Nominatim is not asked as a stand-in either. A search the address search does not answer at all (a refused key, a spent allowance, an error, or no answer within 2.5 seconds) has no OpenStreetMap half, and the index answers on its own. After four of those in a row TREK stops asking the address search for a minute; a spent allowance that says when it comes back is waited out instead, for an hour at most.
It is asked in the language TREK is set to, without its region (`pt-BR` asks in Portuguese, `zh-TW` in Chinese), where the import holds names in that language: Arabic, Azerbaijani, Catalan, Chinese, Czech, Dutch, English, Estonian, French, German, Greek, Hungarian, Indonesian, Italian, Japanese, Korean, Polish, Portuguese, Russian, Slovak, Spanish, Swedish, Thai, Turkish, Ukrainian and Vietnamese. Any other language gets the names used on the spot.
It sends the words searched, the coordinate a search is ranked around, the point of a reverse lookup, the box around a place being matched and that language, with the installation key and the `User-Agent` and nothing else. There is no shared pool. Nominatim stays the geocoder of an installation without the TREK services (no key yet, or `TREK_SERVICES=off`) and of one with `NOMINATIM_URL` set to a Nominatim of its own: TREK then never asks the address search and geocodes the way it did before. `TREK_PHOTON_URL` points at another copy.
## Routing
The third service is a [Valhalla](https://github.com/valhalla/valhalla) at `valhalla.liketrek.com`, routing across the whole planet with elevation data. With **Routing service** on **Automatic** or **TREK services** it calculates the routes of the planner, the road trip and tours, by car, by bike and on foot, around toll roads, motorways and ferries where asked, and the heights of a line. The browser never asks it: a relay on your own server forwards each question with the installation key.
A day goes to the relay with up to twenty stops a request, and the pieces of a longer day follow one another without a pause. A question that runs out its deadline, a very long bike route for example, is answered 504: that one day is drawn by OSRM, and the next question goes to the TREK Valhalla as before. Only a host that cannot be reached or answers with a server error makes TREK leave it alone, for 60 seconds on the server and 10 minutes in a browser tab. Isochrones are not offered.
A routing request sends the coordinates of the stops in order, the travel mode and the road classes to avoid, with the installation key. Routes are asked for with their maneuvers only, without the written turn instructions. No user or trip goes along.
Which engine answers what, what happens when the TREK Valhalla cannot answer, and how to use engines of your own is on [Admin-User-Defaults](Admin-User-Defaults#routing-service) and [Road-Trip](Road-Trip#routing-engines).
## What leaves your instance
@@ -99,6 +117,8 @@ Every request goes out from your TREK server, never from a browser, so the servi
| The trip's area as a box | Preparing a trip for offline use |
| The index id of one place | Opening a place picked from the index |
| A venue name | Booking imports and route imports |
| The words searched, the point of a reverse lookup, the box around a place being matched, and the language TREK is set to | The [address search](#address-search), once the installation has a key |
| The coordinates of a day's stops in order, the travel mode and the road classes to avoid | [Routing](#routing) through the relay on your server |
| The OpenStreetMap way ids a planned tour runs on | Tours trail grades, surfaces and kinds of way |
| The map view as a box, grown to a 0.05 degree grid | Tours horse routes |
| The id of a ski area | Tours ski piste router. No coordinate goes along: the service learns which area a planner loaded, never where anyone clicked. |
@@ -108,7 +128,7 @@ Every request goes out from your TREK server, never from a browser, so the servi
The header carries an opaque token derived from your instance's own address, so the service can rate-limit each instance on its own instead of everyone behind one IP. Set `APP_URL` (or `ALLOWED_ORIGINS`): without either, the token is derived from the port alone, and two unconfigured installs on the same port share one rate-limit bucket.
Who is searching never goes along. No user, account, session, cookie or trip id is sent, and neither is the language TREK is set to or the one picked under **Place names** (see [Language of place names](Places-and-Search#language-of-place-names)). The service's own front page states that queries are not logged, that requests are counted per rate-limit bucket and nothing else, and that the instance token is not stored.
Who is searching never goes along. No user, account, session, cookie or trip id is sent, to the index, the address search or routing. The service's own front page states that queries are not logged, that requests are counted per rate-limit bucket and nothing else, and that the instance token is not stored.
The requests use Node's default HTTP client, so an outbound proxy set with `HTTPS_PROXY` applies to them, and `NO_PROXY` can exempt the service's host. The official image already turns Node's environment proxy on; a source install needs `NODE_USE_ENV_PROXY=1` as well. See [Environment Variables](Environment-Variables#outbound-https-proxy).
@@ -152,8 +172,9 @@ The address is read from your own configuration and is not a URL a user can type
| `TREK_PLACES_ENABLED` | Whether the index is asked at all |
| `TREK_PLACES_URL` | Which copy of the index is asked |
| `TREK_SERVICES`, `TREK_SERVICES_KEY`, `TREK_SERVICES_HOSTS` | The installation key, see [Installation key and daily allowance](#installation-key-and-daily-allowance) |
| `NOMINATIM_URL` | The OpenStreetMap half of the full search, right-click reverse geocoding, OpenStreetMap place details and import geocoding. Set, it also keeps them off the [address search](#address-search) |
| `TREK_PHOTON_URL` | Which copy of the [address search](#address-search) is asked |
| `NOMINATIM_URL` | A Nominatim of your own. Set, it answers the OpenStreetMap half of the search, right-click reverse geocoding, OpenStreetMap place details and import geocoding, and the [address search](#address-search) is not asked at all. Unset, the public Nominatim answers them only on an installation without the TREK services, or a search the address search does not answer at all |
| `TREK_PHOTON_URL` | Which copy of the [address search](#address-search) is asked; once the installation holds a key it is the geocoder for everything listed there |
| `TREK_VALHALLA_URL` | Which copy of the [routing](#routing) service the relay asks |
| `OVERPASS_URL`, `OVERPASS_TIMEOUT_MS` | The Overpass mirrors behind the category buttons, the Road trip search and the ways and horse routes of Tours when the index has no answer |
Defaults and details for each are on [Environment Variables](Environment-Variables).
@@ -174,6 +195,7 @@ Nothing breaks. Every call has a short deadline, 3.5 seconds for a search, 10 se
## See also
- [Places and Search](Places-and-Search): how the index, OpenStreetMap, Google and Amap meet in the search box
- [Road-Trip](Road-Trip#routing-engines): the routing engines and how they share the work
- [Offline Mode and PWA](Offline-Mode-and-PWA): keeping a trip on the device
- [Environment Variables](Environment-Variables): every variable named on this page
- [Plugin Cookbook](Plugin-Cookbook#answer-place-searches-from-your-own-index): adding a third index of your own to the search
+1 -1
View File
@@ -137,7 +137,7 @@ From the plan, **Edit** on a transport needs the right to edit days; on the Tran
A transport with both ends set can be drawn as a line on the trip map:
- **Flights**, **cruises** and **ferries** follow a great-circle curve, the way they actually travel across the globe.
- **Cars**, **buses**, **taxis** and **bicycles** follow real roads, routed on demand through a public OSRM router (driving for car, bus and taxi, cycling for the bicycle). A straight line shows while the route loads, and stays when routing fails or the distance is over about 2000 km.
- **Cars**, **buses**, **taxis** and **bicycles** follow real roads, routed on demand by the same router as a day's route (driving for car, bus and taxi, cycling for the bicycle): the Valhalla of the TREK services, or OSRM for a day it cannot answer and on an installation without them; see [Road-Trip](Road-Trip#routing-engines). A straight line shows while the route loads, and stays when routing fails or the distance is over about 2000 km.
- **Trains** are drawn as a straight line through all their stations.
- **Cable cars** are drawn as a straight line from the valley to the mountain station, the way the rope runs.
- **Public transit** journeys follow their real rail and bus lines, each ride in its line's own colour and the walks between them as a dotted grey line. A journey the provider sent no shape for falls back to a straight line. A journey is also drawn whenever its day's **Route** is switched on, so it has no route button of its own in the day plan.