diff --git a/wiki/Admin-Addons.md b/wiki/Admin-Addons.md index bdc66d572..e5b395f32 100644 --- a/wiki/Admin-Addons.md +++ b/wiki/Admin-Addons.md @@ -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 diff --git a/wiki/Admin-User-Defaults.md b/wiki/Admin-User-Defaults.md index 478e9fc91..d293e0842 100644 --- a/wiki/Admin-User-Defaults.md +++ b/wiki/Admin-User-Defaults.md @@ -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. diff --git a/wiki/Contributing.md b/wiki/Contributing.md index ab09376c2..35a5211a4 100644 --- a/wiki/Contributing.md +++ b/wiki/Contributing.md @@ -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. diff --git a/wiki/Environment-Variables.md b/wiki/Environment-Variables.md index 3a2c51b12..59bec8030 100644 --- a/wiki/Environment-Variables.md +++ b/wiki/Environment-Variables.md @@ -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. --- diff --git a/wiki/Map-Features.md b/wiki/Map-Features.md index bfb8fac31..fb347fd5d 100644 --- a/wiki/Map-Features.md +++ b/wiki/Map-Features.md @@ -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. diff --git a/wiki/Places-and-Search.md b/wiki/Places-and-Search.md index 9228ddfd5..d09795b6d 100644 --- a/wiki/Places-and-Search.md +++ b/wiki/Places-and-Search.md @@ -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). diff --git a/wiki/Road-Trip.md b/wiki/Road-Trip.md index 5a66bd54a..acaeed992 100644 --- a/wiki/Road-Trip.md +++ b/wiki/Road-Trip.md @@ -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, `
/route/v1/