One bar, four layers​

The bar sits at the bottom of the map, beside the lean and acceleration HUD, and on the Navigate tab. Pick a layer — 🌧 rain, 💨 gusts, 🌡 temperature, 🌫 visibility — then play, pause or drag through time. The track is tinted by what kind of frame you are on: blue for what the radar saw, amber for our two-hour nowcast, violet for the model forecast to the day ahead. Tap the card and it folds into one round button while you ride; tap the button to get it back. A small line under the card tells you when the server will next look for new data, and a ⟳ asks it to look now — the server is honest about the cap, so a tap never hammers anyone's servers.

Every layer is served by our own service. Nothing on the phone talks to a weather provider; the worker ingests open data on a schedule into immutable frames and the app draws tiles from those.

What each layer knows​

Rain is the last hours of the pan-European radar composite (EUMETNET OPERA), our own extrapolation of it for the next two hours, and the ICON-EU model forecast after that. In the Nordics, MET Norway's own radar nowcast and 1 km forecast are pasted in. Since today the rain frames also carry their phase — a pale hatch where it will fall as snow, a lighter one for sleet, a red one for freezing rain — and thunderstorm cells as small ⚡ marks (orange when hail is forecast). Load the layer and the bar asks the server what your own position sees at each forecast hour: the hours with thunder get a yellow tick, and a ⚡ before the time while you are on one.

Gusts are the hourly maximum gust from ICON-EU, 1 km in the Nordics from MET, coloured from 30 km/h (below that a gust is weather, not a hazard) through 50, 70 and 90 to 120. Arrows on a lattice show where the wind blows, growing with the gust; calm areas keep a short grey barb so the direction is never missing.

Temperature is the 2 m forecast with a hard edge at 0 °C — frost is a threshold, not a gradient — and the 1 km Nordic detail that shows the cold valleys between the warmer slopes.

Visibility draws fog and haze only where they limit the view, grey from 200 m and gone at 5 km, so an empty map means you can see. Nordic detail comes from MET's MEPS model, which also knows where its cells are foggy.

The same numbers under every stop​

Plan a route and each stop's line in the plan sheet reads the weather expected at that stop's arrival time, from the very frames the map shows:

❄ 2.1 mm/h ⚡ · 💨 31 km/h ↗ · 🌡 −1 °C · 🌫 0.8 km

— snow, with thunder, a 31 km/h gust blowing north-east, a degree below zero, and 800 m of visibility. Visibility is only mentioned under 5 km; a clear morning does not need a number. Because the caption and the tile are sampled from one dataset, they can never disagree.

Where the 1 km comes from​

Across Europe the forecast layers sit on ICON-EU's 7 km grid. In the Nordics, MET Norway's 1 km post-processed forecast is read for every hour — its values pasted into the European frames, and, since today, drawn as frames of its own on top, so the valley-by-valley structure is visible rather than averaged into 8 km blocks. The paste is retried whenever MET's servers come back after an outage; an outage never costs the run its European picture.

What it costs, and what it does not​

All of this comes from open data under open licences — EUMETNET OPERA via MeteoGate, DWD's open data, MET Norway's thredds — credited on every tile's X-Attribution header and in the app's credits. No commercial weather service is involved, and the phone's traffic is only to our own API.

The frames are immutable and the tile URLs never change meaning, so an older build of the app keeps working through every one of these releases; it simply does not see the newer bands and layers. Everything above is on the current build.

Arrows on the gusts​

A 60 km/h gust is survivable as a headwind and frightening from the side. The gust layer draws a lattice of small arrows over its colours, pointing where the wind blows and growing with the gust; on the calm parts of the map, where the colours fade out below 30 km/h, a short grey barb still gives the direction. The plan sheet carries the same arrow after each stop's gust value — 💨 31 km/h ↗.

The direction comes from the forecast model's wind components across Europe and from MET Norway's 1 km forecast in the Nordics, inside the same frames the layer already draws; directions are combined as vectors, never averaged as angles, so a wind from just west of north never comes out as "from the south".

A visibility layer​

Pick 🌫 on the bar and the map shows fog and haze — and nothing else. The layer is grey where visibility drops under 5 km and darkens towards 200 m; clear air is not drawn at all, so an empty map means you can see. In the Nordics it comes from MET Norway's MEPS 2.5 km model, which also knows where its cells are foggy; across the rest of Europe from ICON-EU. Fog also marks the rain layer and the stop captions with 🌫, and a stop's line mentions visibility only when it is under 5 km (🌫 0.8 km) — a clear morning does not need a number.

Same frames, same manifests, same tile URLs as before: an older build of the app simply does not see the new band and the new layer.

Rain or snow​

Where the rain layer shows precipitation, it now shows its phase too. Snow pulls the colour halfway to a pale blue-white under a fine diagonal hatch; sleet is a lighter tint with a sparser hatch; freezing rain keeps its colour under a red hatch. The rain colours themselves have not moved — your eye is trained on them — and where nothing falls, nothing is drawn. The legend strip under the bar shows the three swatches (❄ 🌨 🧊), and when you plan a route, each stop's line reads ❄ 2.1 mm/h instead of 🌧 2.1 mm/h where it is going to snow at your arrival time.

The phase comes from the forecast model's own split of precipitation into snow and rain (DWD ICON-EU, pan-Europe, with its present-weather code marking freezing rain), and in the Nordics from MET Norway's 1 km snow-phase probability — the same file the timeline already reads for the 1 km detail. Snow is snow from a 70 % share; between 30 and 70 % it is sleet.

Thunder​

Thunderstorm cells are drawn on the rain frames as small yellow ⚡ marks (orange when hail is forecast with them), spaced so they read as a hazard rather than a wash — and drawn even where the rain colours are transparent, because a storm cell is a hazard whether or not the frame shows rain under it. The source is the model's present-weather code across Europe and MET's 1 km thunder probability in the Nordics.

The bar itself now knows about thunder at your position: whenever the rain timeline loads, the app asks the server what your own spot on the map sees at each forecast hour, and the hours that answer "thunder" get a yellow tick on the track and a ⚡ before the time while you are on them. Plan a route and the stop lines carry ⚡ (or 🌩 with hail) after the rain value at that stop's arrival time.

Nothing else changed​

Same frames, same tile URLs, same manifests: the phase and the hazards are two extra bands inside the frames the timeline already draws, so an older build of the app keeps working and simply does not see them. The frames from before today render exactly as they did.

What changed for you​

Three layers, one bar. The weather bar now has a picker — 🌧 💨 🌡 — and shows one of them at a time. Rain is what it was: radar for the last hours, our own nowcast for the next two, the forecast after that. Gusts and temperature are hourly forecasts to +24 h; the scrubber starts at the next hour and plays forward.

Colours that mean something on a bike. Gusts are drawn in km/h with rider thresholds: nothing under 30 km/h, then yellow at 30, orange at 50, red at 70, purple at 90 and beyond — the map only colours air that will push you around. Gusts are the maximum over each hour, not the average, because the maximum is the one that moves the bike. Temperature is a field, so it is never blank: cold blues, a hard edge at 0 °C, greens through the comfortable range, orange and red past 30. A legend strip under the scrubber names the scale for whichever layer is up.

It remembers. The layer you pick stays picked across tabs and restarts. The ⟳ button still asks the server for fresher data, now for the layer you are looking at, with the same honesty about the cap.

How it is built​

The two new layers come from the DWD's ICON-EU model — the same open-data tree, grid and run schedule as the precipitation forecast, so the server's ingest simply learned to take three fields instead of one and to check each one's completeness on its own. Each field is warped once to web-mercator and kept as immutable per-run frames; the tiles are rendered on demand under the variable's own palette and cached forever. Everything stays behind one small layers.json that tells the app what the server serves, so a phone written against this shape needs no update when the next layer arrives.

On the phone the store became variable-aware and the rain URLs did not move — an app from this morning keeps working against tonight's server, and tonight's app against a server that only serves rain.

What is next​

MET Norway's 1 km hourly forecast inside the Nordic footprint (the same trick the nowcast already uses for their radar), and the layers sampled along a planned route so the plan sheet can say what rain, gust and temperature to expect at each stop's arrival time.

/weather/layers.json, /weather/{variable}/frames.json and /tiles/{variable}/{frame}/{z}/{x}/{y}.png, documented under Developers → Weather timeline. Forecast data © Deutscher Wetterdienst (ICON-EU); radar © EUMETNET OPERA via MeteoGate; Nordic nowcast © MET Norway.

What changed for you​

Play the rain. Switch on the 🌧 overlay (Settings → Map → Overlays, now called Rain timeline) and a thin bar appears in the bottom band of the map: ▶ plays the frames at one every 0.6 s and holds on the newest before looping; drag anywhere on the track to scrub. The label shows the frame's clock time and how far behind "now" it is — −45 min, −1 h 15 min. A white tick marks the newest observation.

On the Map tab, not just Navigate. The Map tab had no overlay pipeline at all before; it has one now, and the lean slider and the accel card move up out of the bar's way so nothing overlaps (the owner's device pass will settle the landscape details).

Honest about freshness. OPERA publishes a composite every 15 minutes, about 20 minutes behind real time. If our ingest falls three steps behind — the server's beat has died, the publisher is refusing us, the disk is full — a ⚠ appears on the bar rather than a stale picture pretending to be current. The ⟳ button re-reads the frame list; when the capped user-triggered refresh lands it will show next in 6 min instead of failing quietly.

One source, all of Europe. The composite is the merged product of around 170 national radars from Portugal to Finland, on a 2 km grid. The old service had quietly dropped its forecast frames and its terms were for personal use only; it is gone from the app and from the credits page.

How it is built​

Phones never talk to a weather upstream. A scheduled task on our server lists the last two hours of composites from the MeteoGate Open Radar Data API, downloads each new Cloud-Optimized GeoTIFF (about 3 MB) from its 24-hour cache, and warps it once to web-mercator — 0.45 s — into an immutable frame on disk. Tiles are rendered from those frames on demand (12–33 ms each, then cached forever, because a frame id names one product time and is never rewritten), with one logarithmic mm/h palette for every source so the picture will not change its look when the nowcast and forecast bands arrive.

The phone reads one small manifest — the ordered frame list, a tile URL template, a legend and a freshness block — and mounts the current frame plus three neighbours on each side as raster layers, switching them by opacity as you scrub. Seven sources on the native bridge at most, however long the timeline gets.

What is next​

Two hours of the past is the first band. The plan adds an hourly forecast to +24 h from DWD's ICON-EU model, a nowcast of our own extrapolated from the radar motion, and — for the Nordics — MET Norway's 1 km radar and forecast composited over the European product. The scrubber already has the three bands drawn in, tinted differently, waiting for the frames.

Frames and tiles: /weather/rain/frames.json and /tiles/rain/{frame}/{z}/{x}/{y}.png, documented under Developers → Weather timeline. Radar data © EUMETNET OPERA, via MeteoGate, CC BY 4.0.

What changed for you​

More roads, everywhere. Against the old database, the new one holds 77 % more "twisty" kilometres across Europe and 92 % more at the lowest preset. Germany and France go from a few hundred kilometres to 99,000 and 278,000 twisty ones; Serbia, Bosnia, Montenegro and Albania, which the old source never covered, are fully in. Only Austria comes out a shade lower at the twisty preset, and we know why.

Every result once. The old database had been loaded twice and half of it was a second copy, which is why a search used to list the same road on two consecutive lines. The new one is built with a uniqueness rule and cannot double up.

Whole roads, not fragments. A road in OpenStreetMap is drawn as many short pieces — a new piece at every junction, every change of speed limit, every village name. Scored one by one, most pieces of a twisty road fall under the threshold and vanish. We now join the pieces of a road back together first, following its road number through villages, roundabouts and the short bridge ways that used to break the chain, and cut only where a road runs dead straight for five kilometres. Luxembourg's N10, which came out as forty fragments, is one road again.

The filters mean something now. "Scenic roads only" used to return nothing: it now follows recognised tourist routes — Norway's National Tourist Routes, the Romantische Straße, the Deutsche Alpenstraße, the Stelvio, the Großglockner and about 150 others — and flags the roads that actually run along them. "Near water" was never filled in; it is, from the coastline, lakes and rivers of every country. Elevation is there for every road, from our own copy of the Copernicus 30 m terrain model, and the population-density filter covers 29 countries instead of one.

Why it took some doing​

The first attempt lost up to 97 % of the twisty kilometres in some countries, and the coverage report we built for exactly this purpose said so before anything shipped. Three things had to be true before the numbers turned: score whole roads rather than map pieces, do not cap a road's length (the presets were calibrated on uncapped roads), and separate the long straight stretches so a 227 km road at twelve degrees per kilometre does not outrank a genuinely twisty ten. Each was checked against the old data country by country.

What has not changed​

The presets and the offline curvature packs work as before; download the updated pack when the app offers it. The "scoring method" switch is now a rank by switch over the same roads — bends, intensity (turning per kilometre), tightness (hairpins per kilometre) or climb — instead of three separately scored databases; one of those measured how densely a road was drawn rather than how twisty it was, so it had to go. The map's curvature overlay is a separate layer and is unchanged for now.

Closed gates are routed around​

The routing tiles know a gate exists. They do not know it is locked: locked=yes and seasonal *:conditional closures are not parsed into them at all. So the server reads the gates on your route straight from OpenStreetMap and decides, for your vehicle and your departure date, whether each one is passable.

A gate that is locked, private, or closed for the season is routed around. A passable one stays the router's call — opening a gate for 20 km of gravel is usually a good trade, and dirt-first weighs it as one. Avoid closed gates is on by default, in the rider app under Settings → Routing, and in the desktop planner's advanced settings.

Sometimes there is no way around: a locked gate on a dead-end track, or one at the place you are going. Then the route is kept and you are told, because a router that quietly sends you at a padlock is worse than one that admits it.

Told before, and told again on the way​

• The plan lists the gates on the route, and a closed one gets a red warning naming it: Gate at 2.4 km — locked.
• Start asks before it begins. On CarPlay and Android Auto, where there is no dialog to tap, the warning is spoken right after the first instruction.
• Gates are drawn on the track — white with an amber ring when passable, red when closed — on the phone, on the car screen, and on the desktop map.
• Navigation announces them: "Gate in 300 m. Close it behind you." A closed one gets its own warning with the alert tone, a kilometre out and again at 250 m. Toll booths and bollards are announced too, in all ten languages.
• A roadbook generated for the route carries the gate as a line of its own.

If you go off-route and the app re-plans, the gates come with it. A reroute also stops treating the gate you just turned back from as "where you were going" — before, a route recomputed 100 m short of a padlock would send you at it again.

How far dirt-first may detour​

Gravel is slower than tarmac, which is the point, and it is usually not much longer. Occasionally it is: the strongest preset can find a corridor that adds half the trip again. Max detour now caps that in distance — 1.2×, 1.5× (the default) or no cap at all — and when the cap bites, the plan steps down a preset and offers you the one you asked for:

Moderate applied — the full Strong route is 1.4× the length of the plain route. +28 km · +1 h 24 min compared with this route. Use the full Strong route.

One tap takes it, and the ride's reroutes keep it uncapped. Évora to Beja is a good example: 83 km at 38% unpaved inside a 1.2× cap, or 112 km at 71% unpaved if the gravel is the reason you came.

What it does not know yet​

Routes computed offline on the phone are not gate-checked — there is no OpenStreetMap lookup out there. The app says Gates not checked on an offline route rather than pretending the road is clear; the gate data for offline packs is the next piece of this. Free-text winter-closure notes ("Vinterstenging") are shown, never enforced: a note is not a rule.

Why the estimate was so slow​

The planned time is the router's time, road by road. Where OpenStreetMap has a posted speed limit, that limit is the speed; everywhere else the router uses a typical speed for that kind of road. That works well on tarmac. On unpaved tracks with no speed tag, the router's own figure is 5 to 7 km/h. I-01 has 83 km of those, and they alone accounted for more than 12 of its 14 hours.

AL-01 in Albania looked slow for a different reason: most of its gravel carries a real posted limit of 20 km/h in OpenStreetMap. That limit is kept.

Realistic times on unpaved tracks​

Trips built from a GPX or a TET trail now time gravel and compacted roads at no less than 20 km/h, dirt at 15 km/h and paths at 10 km/h. A posted limit is never exceeded, and the route and its turns do not change, only the time:

The TET trails are rebuilt on the server over the next few nights; each one switches to the new time as soon as it is rebuilt, and your phone picks it up the next time you open the trail online.

The ETA learns your pace while you ride​

A floor is the same for everybody, and gravel pace depends on the rider. So every 4 km the app now compares your moving time with the planned time for the same stretch, and re-estimates the rest of the route. It keeps two separate estimates, one for roads and one for tracks and gravel, so a fast motorway run never makes the trail look shorter. Traffic lights, photo stops and coffee breaks do not count. The remaining time, the arrival clock, the next-stop ETA and the CarPlay and Android Auto estimates all follow it, and a small your pace caption says so.

And it remembers​

When navigation stops, the app remembers your pace for that vehicle. The next ride starts from it, halfway between your usual pace and the plan (a new trail or a wet day is slower than your average), until the first 4 km of that ride take over. Before you start, the planner shows both numbers, for example 7:45 h · ≈ 5:17 h at your pace.

Tap the ⓘ next to a planned route's time, or the pace caption in the HUD, for a short explanation. Everything can be turned off in Settings → Navigation → Adapt ETA to my pace, and Forget my pace clears what the app remembers.

Built once, on the server​

Every night the server checks each TET sub-trail against three things that can change its trip: the trail itself (a new TET release), the map tiles, and the builder. Anything that changed is rebuilt; everything else is left alone, so a normal night finishes in seconds. When the map is rebuilt, you get the previous trip, marked as stale, until the new one lands.

Opening a sub-trail asks for that ready-made trip. Later online opens check, in about a second, whether a newer one exists and download it only if so. The longest trails, like FIN-01 at 2,413 km, no longer need the phone to do the work.

TET in the country pack​

Downloading a country that has TET now also installs its TET tracks, in your navigation language: about 1 MB for Albania and a few MB for the bigger countries. With the pack installed you can import a sub-trail with no connection and ride it either way with turn-by-turn. The pack gets an update badge when the server has a newer build or you switch navigation language.

Where turn-by-turn stops​

The first full build also measured, trail by trail, where the router cannot follow the drawing legally. That report found two builder weaknesses: one short stretch the map matcher could not follow cost the turn-by-turn of a whole 150 km window, and a 40 m deviation could take a 10 km instruction with it. Both are fixed. Across the network the kilometres without turn-by-turn went from 1,916 to 530; 99.8 % of the 110,797 km now have turns in both directions.

What remains shows on the trail card: when a direction has half a kilometre or more the router cannot follow, it says so, for example "Reversed: 38.5 km without turn-by-turn". Clean directions show nothing.

Why it went wrong​

The map-matcher we use does not fail on a track that cannot be ridden as drawn. It answers with the first legal piece and hides the rest in a field the app never read, so a 22 km reversed ride collapsed to its first 60 m, failed a sanity check, and was ridden as the reversed drawing — clockwise round 12 of its 13 roundabouts.

What happens now​

A track keeps one built trip per direction. The builder starts from the original points, never from a matched shape: it map-matches them into continuous legal pieces, bridges every gap with a legal route whose ends are trimmed back and forward along the pieces (a bridge that starts inside the illegal spot loops back through the same junction), picks the bridge closest to your drawing rather than the shortest, and then checks the assembled line with a second legal map-match. Where there is no road at all — a hiking trail, a field — the stretch stays follow-the-line and says so.

On the owner's roundabout-rich track the reversed ride went from twelve wrong-way roundabouts to none, with no U-turns and every metre covered by turn-by-turn. A left-hand-traffic town and a divided carriageway behaved the same; two-way country roads need no bridges at all and ride exactly as before.

In the app​

• Both directions are built when you enhance a track, so opening it reversed works offline and starts at once. Joining mid-track slices the built trip at your position instead of re-matching it.
• Set off against the loaded direction and the app notices within a few seconds, switches to the other direction's trip where you are, and tells you. No reroute storm.
• Chevrons on the track line show the ridden direction, and wherever the legal line leaves your drawing — the other side of a roundabout, a bridge across a stretch you cannot ride that way — the drawing stays visible as a faint dashed ghost, on the phone and on the car screen.
• Library lines recorded on a ride or drawn on the desktop now rejoin the track after a detour instead of being replanned to their end.
• Trail source codes no longer leak into spoken instructions.

The builder is also an API for your own tools: POST /grass/routing/track-direction takes a track and answers with the legal trip for either direction, the bridges it added and their extra length, and the validation result.

One route line​

The white line was an accident: the car borrowed the Selection highlight setting, which exists to highlight a track you tap. The route is now the phone's blue line on both screens, with a dark edge and round ends so it stays readable on a sunlit head unit and over satellite imagery. Plan previews are blue too, and rain or storm stretches ahead are painted on the route in the car as on the phone.

One map​

The car now loads exactly the style the phone loads: your server, label language, POI categories, badge density and, without signal, your offline map. With the Adventure theme on Auto, the car switches to night when the car does (usually with the headlights), even while the phone is still in day mode. Navigation opens flat like on the phone, and the zoom, vehicle marker and speed-limit sign are the phone's sizes scaled to the car screen.

The same symbols, including the cluster​

Turn arrows use the phone's colours: teal for left, orange for right. Apple's maneuver card, which also feeds the instrument cluster and the dashboard, now shows the phone's roundabout symbol: the real exit direction and the exit number, not one generic icon. Within 2 km of a junction it also shows the lanes, with yours lit. What the car is told a maneuver is now matches the picture: motorway exits, merges and roundabout exit angles were all being described slightly wrong to the cluster. Fuel, camping and beach results from the Services page appear as the phone's round badges.

Checking the roundabout symbol turned up a bug on the phone as well. The small chevron that shows the direction of travel around a roundabout was computed in a way that depended on where on Earth the roundabout is. In Bergen, four of five roundabouts pointed the wrong way. That is fixed on both screens.

A marker that knows which way you face​

While you are stopped or crawling, the vehicle marker now points where the phone's compass says you are facing, corrected for a phone mounted in landscape. Once you are moving it follows the road, because a compass on a handlebar or in a dashboard cradle is disturbed by the vehicle's metal. A translucent blue circle around the marker shows how accurate your GPS position is. With a good fix it hides under the marker; in a tunnel exit, a deep valley or between tall buildings it grows, so a marker that is only approximately right looks approximate.

Android Auto gets all of this through the same code; its own check on a head unit is next.

Harbours that are not paper​

OpenMapTiles has no marinas, docks, breakwaters or quays. In Bergen the moles and quay aprons of Vågen were drawn as open land; at Sanxenxo the marina was an outline around nothing. Our tiles now carry a harbour layer. Basins are a quiet tint over the water, quays and moles are decks with a structure edge, and a breakwater is the line the sea breaks on. A footway that runs along a jetty is now drawn as the jetty, not as a dashed path across the water.

The gate before the forest road​

A locked gate is the fact a rider most wants before committing to a gravel road. The new tiles carry gates, bollards and cattle grids, but only where a road or track actually runs through them, and the map shows them as small badges from z15. A gate tagged as locked is red. The bollards of city footways and the lift gates of car parks are left out, and every barrier badge yields to a road name or a point of interest when they collide.

A lighter map, with the right badges​

The stock tiles carried every point of interest OpenStreetMap knows: waste baskets, bike stands, hairdressers. The map could draw none of them. Our profile keeps only what the map draws, and ranks what a rider stops for first: fuel, charging, hospitals, campsites, huts, shelters, drinking water. Springs and wells now count as water. A Munich centre tile went from 7 290 points of interest to 1 998, and from 342 KB to 200 KB. The whole Europe archive is 2.4 GB smaller.

Because a point's rank now counts only against things the map can draw, the badge budget was retuned so a city centre keeps the density it had. Munich at z16 shows 45 badges instead of 35, and the road names stay readable.

The tiles also carry what a rider picks a stop by, ready for the map and the app to use. A fuel station lists its fuel types, a charger its sockets and capacity. A campsite says whether it takes tents or charges a fee. A shelter says whether it is a hut or a bus stop. Surface now reaches the regional view from z8. Tracks carry their grade, smoothness and whether motorcycles may use them.

If you have the offline Europe map​

A Europe map you already downloaded keeps working and draws exactly as it did. Every new layer is optional in the style, and we checked that the old tiles render the same labels with the new style at every test site. The app does not replace a downloaded map on its own. To get harbours and gates offline too, delete the Europe map under Offline basemap in the app's settings and download it again. The new download is 2.4 GB smaller.

The details of what the map draws are on the Adventure basemap page.

Things that were in the tiles all along​

The tiles we build carry more than the style read. Ferry routes were there and never drawn. Places had a rank and a capital flag; the style gave Bergen and a hamlet the same size ramp. Peaks had a prominence rank and saddles had names and elevations; Stelvio was invisible. Water names came as lines along the lake; the style anchored them at a vertex. Runways, land use, protected areas: all present, all unread.

So the first pass was correctness. Ferries draw from the regional view and carry their timetable's name. Scrub, heath and fell above the treeline take their own tone instead of the lawn green. Route shields stop appearing on Munich's staircases and start splitting E 16;E 39 into one number. Indoor and underground things stay indoors. The night theme stops leaking six day colours. Maritime borders stop looking like ferries.

A hierarchy​

The second pass gave labels a pecking order. Countries and states appear at the continental view, set light and spaced. Cities step in by rank, then towns, villages and hamlets, so a z6 view of Bavaria is no longer a wall of equal names. Suburbs become a quieter upper-case tier. Peaks come in one rank per zoom, highest summit winning a collision, and passes get their own glyph and outrank the summits around them — a pass is where you are going.

The same pass added a language: labels in the language the app speaks, the local name underneath from z12, because that is what the sign at the roundabout says.

Land, water, areas​

The third pass tinted land use faintly enough that a town reads as a town from z10 without a single road losing contrast, gave farmland its own tone, drew protected-area edges and names, and put runways and IATA codes on the map — a runway is the best orientation cue after a railway.

Badges with a rider's priorities​

The fourth pass replaced the hand-drawn badge glyphs with CC0 silhouettes from Maki and Temaki, on our own badge frame, and added six categories the tiles already carried: mountain huts, supermarkets, sights, motorcycle parking, toilets and ATMs. More importantly, badges are now placed by a rider's priority. OpenMapTiles ranks a bar above a fuel station; on this map fuel wins that collision every time.

How it was checked​

Every pass rendered the same fourteen sites in headless Chrome, day, night and surface mode, before and after, with a census of placed labels per layer. Rows that should not change came back byte-identical. The renders sat in front of a person before anything was pushed. That harness is now in the repository, so the next change to the map pays for none of it again.

The map is on in the rider app under FastGIS Adventure, and on the desktop client's basemap picker. The full description is on the Adventure basemap page.

Behind that change is a new object: an event. A time, a roster, and the library records you ride.

The thing a route file cannot tell you​

A GPX file is a shape. It cannot say who is coming, when you leave, where you stop for fuel, or which of the six people on the ride still has not answered. Riders have been solving that with group chats and screenshots for as long as there have been group rides.

An event is where those answers live. It has a start, a roster with roles, a schedule of stops, and the records it uses. It has a page you can link to — and so does every part of it, because organising is a sharing activity and an organiser pastes links all day.

One idea at four sizes​

The temptation with something like this is to build the small version, then build a separate serious version later for the people running real events. We did not. A trip you are planning alone, a Sunday ride with friends, a tour operator taking clients out and a rally with waves and time controls are the same object, with different vocabulary and different capabilities.

The role ladder underneath never changes: owner, organiser, staff, participant, spectator. What changes is what you read. The row that says Rider on a group ride says Client on a tour and Competitor at a rally, and the person running it goes from Organiser to Operator to Promoter. One ladder, four vocabularies, no second product.

Which of those things you may do is decided by the server and sent with every event it hands you. The client renders that list; it never works it out for itself. So taking someone's role away takes effect on their next request rather than whenever their browser gets round to reloading.

Starting one should be cheap​

Creating an event asks for a title and a preset. That is all. No date, no roster, no route — a trip of one should not cost more than saving a route does, and everything else is a decision you can make later or never.

There is a shorter path still. Anywhere the Library is on screen — the Library page, the picker inside the planner — a saved route now offers Attach to event, and the first button in that dialog is New trip from this. The route names the trip, the trip points at the route, and you land in its console. One click, from a line on the map to something people can be invited to.

Nothing is copied​

An event stores which library record it uses and how: route, roadbook, waypoints, briefing, GPX pack, media, result track. It does not take a copy.

This is the same rule sharing has followed since the Library became one primitive: a reference, never a duplicate. The record stays yours, in one place, with one owner. Fix the route the night before the ride and it is fixed for everyone holding the link — nobody is riding last week's file.

There is exactly one exception, and it is the one that has to exist. When a rally is published, its documents are frozen at that version, because an organiser has to be able to prove what a competitor was handed. Trips, group rides and tours stay live references, because there a correction reaching everyone at once is worth more than a paper trail.

What the Dashboard shows​

Three sections, in the order they matter: invitations waiting on your answer, what is running right now, and what is coming up. If you are new, all three are empty — so instead of an apology that page offers the three things worth doing, and gets out of the way.

What is next​

The console covers the roster, the schedule and the documents. The live wall — the realtime map of an event in progress, the one screen that serves five friends and three hundred competitors — is the next surface, and it is where this gets interesting.

Read the Events page for what is there today.

Search that was always there​

The catalogue behind the Library had a full search plane for months — free text over names, descriptions and tags on a proper index, tag filters, paging — but only on a door the desktop could not open. That plane now sits on the endpoint every client uses, so the desktop and the phone can ask for "gravel" and get the ride whose description mentions it, page through a long history, sort by length, and scope a query to a map extent or a date window. Nothing about the old answer changed for callers that never asked to page.

One verb set, computed​

What you can do with an item — show it on the map, load it into the planner, insert it into a route, edit its geometry, generate a roadbook, share, export, delete — used to depend on where you had clicked. It is now one table, evaluated by a pure function of the item, the mount and your role, so a saved route offers the same verbs in the list, in a picker and on its own page. A verb your plan does not include is shown locked, not hidden. Select several items and the bulk bar offers only the actions that apply to every one of them — never a partial apply, because a bulk action that quietly skips a row is how a rider loses data they believe they moved.

Filters in the address bar​

The Library page keeps its query in the URL. Search for a word, pick a category, hit "Search this area", copy the address, paste it in a new tab: the same list. A filtered library view is a link you can send.

Roadbooks are library items​

Until now a saved roadbook lived in a small store beside the library: capped, unshareable, invisible to export. A roadbook is now a record of its own, with the track it is projected onto as its geometry and the book in its payload, linked back to the item the track came from. The editor's first save opens the Library's save form; later saves update the record in place. Books saved before today are moved in the first time you open them — nothing to do in advance, nothing lost. And because a roadbook is now the same kind of thing as a route, sharing it is the sharing you already have: the person you send it to sees the book and can download its track.

Lessons​

The interesting bug was found in the browser, not in a test: saving a book in place was overwriting the tags typed on its item page, because the save sent a tag list it had no business sending. The fix is a rule — a save in place carries the book and its track, and nothing that belongs to the record — and a test that pins it.

Dig deeper: the desktop client and the roadbook editor.

What you edit is what prints​

The editor shows your book as the official page: the 148 mm Diagram-1 rows with the distance, tulip and description boxes at their measured widths, the red danger frames, the green close-note boxes, the orange speed-zone frames, the comma decimals. A splitter zooms the paper without ever distorting it, because the same millimetres drive the A5, FMI and moto-roll print layouts — now led by a proper page-1 cover with the event block, the day's waypoint radii and the change log.

Behind every edit sits the same server engine that generates and bakes the TET books. The editor never re-implements a rule: change a danger level, paint a speed zone, drop a note — the book comes back renumbered, re-measured, and re-linted, with the findings panel (one DSS, !!! needs a safety waypoint, no box over 400 m…) one click away from the row it names.

Ride it at the desk​

The flow we ended up loving: open any GPX, start a blank book, and walk the route. A cursor steps along the track — or jumps straight to the next bend — and each add note drops a vignette that then populates itself from the data underneath: the generator reads the stretch around it and fills in the junction tulip, the crossing roads, the road name and surface, the exit heading, the terrain stamps. You decide; the machine does the drawing. One re-split pass afterwards inserts the regulation continue notes into whatever gaps remain.

Every piece of the vignette is hand-editable too: the tulip's arms and branches (click a handle, point it), the full 144-symbol lexicon in four abbreviation dialects, waypoints with regulation radii, CAPs, free text. Arm change tracking and your edits become versioned MODIF / NEW NOTE records, the way an opening car issues them.

The track is a first-class citizen​

Roadbooks live and die by geometry, so the editor owns the track as well as the book: snap a hand-drawn GPX onto the road network (stretches with no map data keep their shape), drag vertices where reality disagrees, and — only when you say so — re-measure the book's distances from the corrected line. By default the authored distances stay untouched: they come from the road's true arc length and are usually better than any GPX chord sum.

Keep it, carry it, hand it over​

Books save to a per-account library on the server and reopen exactly as left — track included — or travel as a single portable project file. Getting a book out is one click: OpenRally GPX for Piste, DMD2 and the rest of the reader ecosystem, or the print book for paper and roll holders.

The full walkthrough lives in the guide: the roadbook editor.

Ride, not read​

Open any track's roadbook, flip it to Rally, and there is now a Ride button. It builds a turn-by-turn session from the track's geometry alone: every bend is classified by its clustered turn angle — kink, mild, sharp, elbow, hairpin — with S-bends linked into chicanes, and each one becomes a maneuver the normal navigation engine drives. Nothing is looked up. No map-matching, no tiles, no server, no signal. If the points are on the phone, the roadbook rides.

What the HUD shows​

• A tulip glyph instead of a road arrow — the same approach-line-and-exit shape you would draw in a paper roadbook, coloured by direction.
• Distance to the next note, counting down odometer-style along the track as you cover ground, not as the crow flies. On a stack of hairpins the "nearest note" is often three switchbacks above you; along-track distance never makes that mistake.
• CAP, the compass heading to hold out of the bend — CAP 135° SE — the rally navigator's oldest trick for confirming you left a junction the right way.
• Danger chips: !, !!, !!! from radius, blindness and downhill grade.

Spoken cues follow suit — "hairpin left, 160", "S-bends" — in the navigation voice language you already chose.

What it deliberately does not do​

A roadbook ride never replans. Going off the line does not summon a router to "fix" the route (there is none to summon, and on a trail the fix is usually worse than the problem). The HUD drops to a calm following your track hint, the voice says so once, and the cues resume the moment you are back on the line. That quiet path existed in the engine for months as an anticipated case; this is the first mode to actually ride it.

An advisory corner-speed and gear suggestion (v = √(μ·g·r), with a grip coefficient you set) is in there too — off by default, and it stays off unless you turn it on in Settings → Navigation. Estimates about grip are not something an app should volunteer.

Where it stands​

Verified in the simulator with GPS playback along a real Norwegian pass — eleven hairpins, every one announced and advanced in order. The field test on the bike is still owed, and that is where the note spacing and the CAP lead time will get their real calibration.

The three-day arc​

The OBD-II work had been parked for months as a deliberately unmerged spike: a pure ELM327 protocol layer with tests, a BLE transport, and a diagnostic screen — all waiting on one question no amount of code review could answer: does the bike actually respond? Motorcycles are notorious for implementing a thin, inconsistent slice of the OBD-II standard, or none at all.

Then the adapter arrived (a Vgate iCar Pro 2S), and the question got answered in stages.

Bench day. Ignition on, scan, connect — and the first quiet surprise: the adapter advertises the 18F0 BLE service, not the FFF0 layout its own documentation suggests. The transport's autodiscovery fallback (any service with one notifiable and one writable characteristic) carried the day, and 18F0 is now first in the known-layouts list. Then the second surprise: the KTM 890 ignores 0100, the standard "which PIDs do you support?" query. A capability-first design would have concluded the bike supports nothing. Polling PIDs directly told a different story: RPM, speed, coolant, throttle, load and battery voltage, all live, all plausible — 12.5 V with the engine off, 14.2 V charging the moment it fired up.

Probe day. The owner's real asks were odometer and fuel. So the screen grew an extended probe: ask each interesting PID once per connection and report answered / no-answer, honestly, per line. The verdict on the 890: fuel level, true odometer, fuel rate, mass-air-flow and gear — silent. But distance-since-codes-cleared (31) answers, and that is enough: anchor it once against the dash and the app can track total distance from then on. Maintenance tracking gets ECU-exact kilometres; fuel planning stays on the learned-consumption path that never needed the ECU at all.

The hunt​

The best part of the week came from the signals OBD-II doesn't hand over. The ELM327 has a monitor mode that eavesdrops on the bike's broadcast CAN bus — received wisdom says cheap clones drop frames and give up. Filtered tightly, this one doesn't. Twenty-five broadcast CAN IDs reach the diagnostic connector, and among them:

• Gear position, plainly broadcast — decoded and confirmed through all six gears against prediction,
• the IMU cluster, identified by a sign flip while riding circles,
• a speed frame whose fields go to zero at a standstill — raw material for a wheel-speed odometer with far finer resolution than the 1 km ticks of PID 31.

The capture tooling moved from a laptop script into the app itself, with GPS interleaved into every log as the calibration reference. And because the next step is a calibration ride, the capture screen now has three glove-sized buttons — 20 / 40 / 60 km/h — that stamp labelled steady-speed windows straight into the log while riding. Tap when you're holding the speed, tap again when you leave it.

Where this lands​

Live engine data is on the phone today (More → OBD-II (Bluetooth)), the screen keeps itself awake, and the whole feature works with CarPlay active — which on this bike means always, since the head unit comes up with the ignition. The plan from here: fuse the fine-but-drifting wheel-speed integral with the coarse-but-honest kilometre counter, fold the proven signals into ride recordings, and give the rally-roadbook mode the distance source it has been waiting for.

The bike had a lot to say. We just had to stop asking politely and start listening.

Bends or climb — your call, in four places​

The curvy-roads finder grew a Rank by switch: Bends is the classic curvature ranking, Climb orders the same search by a 0–100 climb rating instead. The two lists genuinely differ — the bendiest road near you and the biggest mountain road near you are rarely the same road — and each result now shows its climb rating alongside elevation range and gain.

The loop generator got the same choice. Include curvy roads has always woven the best road nearby into your loop; now a Bends / Climb picker decides what "best" means, so a mountain loop is one tap instead of a hope. It is mirrored on CarPlay and Android Auto.

The route planner gained a Scenic bias slider — off by default, because it asks the server for extra work per request. Slide it up and the route is biased toward the best-rated roads in the corridor, again with the bends-or- climb choice. The engine's cost model is untouched: the server scores the roads and simply tells Valhalla some edges are cheaper.

A second number beside "% unpaved"​

A planned route's summary already showed how much of it is dirt. It now also shows how demanding it is: a difficulty rating — surface roughness amplified by climb, on exactly the scale the max_difficulty routing ceiling uses — with the hard kilometres spelled out beside it. It is deliberately a second number, never folded into the unpaved share: "40% unpaved" and "40% unpaved, 12 of them steep loose climbs" are different rides, and the ride you were promised should match the ride you get. Steep tarmac stays easy — steep is not the same as difficult.

The offline fold computes the same number on-device from the elevation the routing tiles now carry, so the badge survives losing the network.

All of this ships in ten languages and rides the next phone build.

Dig deeper: the rider app guide covers each control in place.

Partials everywhere the trip is shown​

Multi-stop routes now carry per-stop arithmetic through the whole app:

• In the HUD, three new cycling metric slots: NEXT STOP (distance to the next intermediate stop), STOP ETA (the arrival clock at it), and a STOP counter ("2/4"). The final-destination ETA is untouched.
• Before you ride, the route planner's stops editor lists each stop's own leg distance, riding time, and projected arrival clock — so you can see at a glance that lunch lands at 14:30, not 12:00.
• On CarPlay and Android Auto, a new Stops button during multi-stop navigation opens a dedicated list page: every stop with its remaining distance and arrival time. The car's own estimate still means the final destination — CarPlay models one trip, one estimate, and pretending otherwise would corrupt the ETA the car shows in its cluster.

The engine room is deliberately boring: the navigation store already kept the route's legs, and the ETA estimator already weighted remaining time by Valhalla's per-maneuver durations (so a route mixing motorway and switchbacks doesn't drift). Per-stop partials are prefix-sum subtractions over that same distribution — the last stop's numbers are identical to the trip totals by construction, and a test pins that identity at arbitrary points along the route.

When the honest answer is a dash​

The interesting design work was deciding when not to show a number.

An out-and-back track — Sommeiller, Jafferau — is one leg whose geometry is a palindrome. The turnaround is not a stop, and "Stop 1 of 1" would be noise pretending to be information. A TET section or imported GPX rides as a chain of stitched legs whose boundaries are chunking artifacts, not places anyone plans to stop. And after an off-route reroute rebuilds the trip as "approach + trail", reaching the trail again is a milestone, not a stop.

In all of those cases the stop metrics show a plain —. The rule the implementation follows, and the tests enforce: degrade to blank rather than lie.