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 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:
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.
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.
]]>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.
CAP 135° SE — the
rally navigator's oldest trick for confirming you left a junction the right
way.!, !!, !!! from radius, blindness and downhill
grade.Spoken cues follow suit — "hairpin left, 160", "S-bends" — in the navigation voice language you already chose.
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.
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 app has computed an anti-U-turn origin heading since early in the
turn-by-turn work. It turns out that heading never once reached the routing
engine. The server's validation model declared exactly lon and lat, and
Pydantic silently dropped everything else the phone sent — heading, and the
via type that marks a rejoin hint as a pass-through rather than a stop.
The symptoms were exactly what riders reported. With no heading, a reroute for someone travelling the wrong way comes back as "continue" — the instruction they are already following, repeated forever, with a perfectly good roundabout fifty metres ahead that the engine was never told was ahead. And with every via defaulting to a stop, one evening's log shows 47 multi-leg reroutes producing 69 phantom "you will reach the destination" announcements, mid-ride.
The docstring above that model warned that Pydantic ignores unknown fields. It had already cost us once. The lesson is now a house rule with teeth: test at the HTTP boundary, not the service — six of the eight new route-level tests fail against the old model.
Fixing the heading exposed the next layer. The rejoin logic guaranteed its target was forward along the route — which is the same as forward for the rider right up until the rider is travelling opposite to the route, which is precisely when they are lost. So the origin heading pointed at the roundabout while the rejoin hint pulled the line straight back through it, and the rider rode out and back. There is now a guard: a rejoin more than 120° off the rider's heading is dropped, and the reroute plans to the destination instead.
The rest of the reliability sweep came straight off device logs from field
rides. A guard-before-await race was leaking native location watchers — one
ride ran with two GPS pipelines fanning fixes into an already-saturated
thread, and one day's log showed 24 manager instances. "It stopped syncing
with the GPS" was the app failing to consume fixes, not the phone failing to
make them. A reroute storm — 52 reroutes in 20 minutes — turned out to be the
throttle being disarmed by its own reroute. A rider who left the route stopped
being told they'd arrived; a lost rider stranded by a non-convergence guard
gets a time floor and an auto-retry — and then measurement showed that guard
had shipped dead, its condition unable to fire until it had already fired.
When the marker can't be snapped to a road, it now draws a metre-true accuracy halo instead of a falsely precise dot. And then the best outcome of the week: the plan's next phase — snapping to the road we think you're on — set its own stop-condition in advance, two rides measured a 1 m median residual up to 91 km/h, and the phase is not being built. Deciding not to build something, on evidence, is a result.
The scenic loop generator got turned inside out. Instead of "give me 120 km of loop and hope it passes something", you now pick the places — wiki-ranked villages and POIs by category and budget, curated on the map — and the optimizer computes the circle through them. Shipped on the phone and in the desktop planner the same day, and iterated twice on owner feedback before the weekend.
The plainer loop generator learned honesty too: when the road network can't deliver the distance you asked for, it says so — on the server, on the phone, and offline — instead of quietly handing you a shorter ride.
release-to-phones.sh had a bad week and came out much stronger. It could
hang forever at a prompt when no phone was attached — one run was found still
spinning fourteen hours after the build finished. It couldn't see a phone on a
USB cable because it grepped for a status word only wireless prints. It once
installed the build to the wrong phone and wrote a receipt saying the
opposite. And it happily called an empty .app skeleton a successful build,
because xcodebuild creates the folder before compiling anything.
Every one of those is fixed the same way: the script now checks ground truth —
the debug-services probe, the device's product type, the Mach-O inside the
bundle — instead of string-matching its way to optimism. A green exit is not a
result. Same spirit on the code side: the mobile app finally has ESLint with
rules-of-hooks as an error, wired into CI, days after a hooks-order crash
took down every CarPlay routing flow in the field — a class of bug that could
not have been linted for, because there was no linter.
The CarPlay stability audit root-caused all three field symptoms — including that routing crash — and the usability round put route alternatives on the car screen with a companion picker. A desktop session no longer outlives its upstream token, and the B2B web app is walled off from rider accounts. Walk isochrones went from a 23-minute per-request projection to a ~3-second windowed crop — numerically identical output. The contour basemap was re-baked on the server: 8.85 GB → 5.3 GB, 102 warnings → 0. An OBD-II BLE dongle now has a transport and a diagnostic screen, parked until the motorcycle answers. The screen stays awake while navigating. And the half-ring that haunted signed-out phones after a group call is dead.
One more thing: the page you are reading lands on main this week. The docs site now ships with the repo — generated API reference with a drift gate so it cannot quietly fall behind the code, operations runbooks, and this blog.
Dig deeper: the rider app guide, and riding together for the CarPlay side.
]]>Multi-stop routes now carry per-stop arithmetic through the whole app:
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.
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.
]]>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 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.
]]>Today the session view grows three storage actions that say exactly that.
A synced session's local copies can now be dropped in one tap. The session stays in your list, the track stays on the map, and every capture keeps playing — streamed from the server with the same viewers, just marked "Streaming from server". This is the space-freeing move: media is by far the heaviest thing the app stores. The action only appears once the session is fully synced, so it can never throw away the only copy of anything.
The inverse. A session that lives only on the server — because you removed it, or because it was recorded on another device — can be re-materialized locally: every capture row and every media file comes back to the phone, and the session works with no connection again. Sessions the server knew but the phone had completely forgotten are rebuilt from the registry, wired back up so future streaming and syncing keep working.
This one needed a new server verb, and the verb had to be soft. The session
registry only knew two things: list a session, or cascade-delete it together
with its GRASS layers. Neither is "remove this from my listing". So the
registry gained a hidden flag — a PATCH that hides a session from the
listing while leaving the layers, the attribute tables, and the media
untouched on the server. Deleting from the library hides the registry entry,
soft-deletes the Library cards (the catalogue has had a trash with restore for
months), and wipes the local copy. A permanent delete remains what it always
was: a separate, explicit act.
The subtle part is discovery. When the registry returns an empty list, the app
falls back to scanning the environment's raw track_* layers — a deliberate
escape hatch for sessions published before the registry existed. But a hidden
session's layers are still there, so the scan would cheerfully resurrect
everything you just deleted. The listing now reports how many sessions it
hid, and the fallback scan only runs when the registry is genuinely empty —
not when it's merely quiet on purpose.
One more lesson from the reroute
post applied here before the bug could
exist: a background re-publish overwrites a session's whole registry entry
with whatever the phone sends — and the phone never sends hidden. The
register route now preserves the flag across upserts, and a route-level test
pins it: sync more samples all you like, a deleted session stays deleted.
All of it lands with route-level server tests against the real HTTP boundary, and the mobile pieces ride the next phone build.
]]>An audit of the routing graph found that most of Europe's tiles carried no elevation at all — the majority of the graph's one-degree cells had no DEM behind them, and a missing DEM yields silently zero grade, which looks exactly like flat ground. Then the same check on the road-score database: every one of its million European roads had NULL in all seven elevation columns. The "epic road" score had never seen a mountain. Same class of bug, found the same way: by looking instead of assuming.
Both are fixed from the same source — the 1-arcsec DEM we already host, resampled into the exact grid Valhalla reads. The routing tiles now carry grade, and the riding knobs that were quietly inert came alive: prefer or avoid hills, avoid tunnels, cap route difficulty, with a difficulty number reported beside "% unpaved" rather than folded into it. Steep tarmac stays easy; a rider who asked for no rough stuff did not ask to avoid mountain passes.
The road score grew a climb axis — a second number beside curvature, because "twisty but flat" and "high but straight" are different roads and one blended score cannot say which you got. Ranked by climb, the Alps now answer Gavia, Stelvio, Timmelsjoch. The Netherlands answers dike roads at 8.
The tempting design was to mix "fun" into Valhalla's cost model. Measurement killed it: discount steep edges and the solver buys more steep kilometres, not more altitude — one test route went 23 km further and 300 m lower the harder we asked it for hills. An optimisation solver optimises what you price, not what you meant.
So scoring stays in the curvature database, and a new scenic bias hands the router per-edge discounts for the best-ranked roads in the corridor — by curvature or by climb, off by default, and every failure path returns an ordinary route. The loop generator learned the same trick: it can now weave in a road chosen for its climb, not just its bends, with a hard elevation floor so a flat region says so instead of offering its least-flat lane.
Dirt-first routing shipped the same lesson in miniature. The first cut inflated the cost of pavement, which made ferries relatively cheap and sent a "dirt" route across a fjord. Discounting dirt instead fixed the ferry, fixed the inert middle preset, and the badge now says "no unpaved roads on this route" rather than a bare 0% that reads as broken.
The desktop planner had been dark for a week while the server kept shipping, so it got a catch-up sprint: the dirt-first axis, grade knobs, climb loops, the POI seeker reaching all 39 categories instead of 2, corridor search along the route, our own basemap, live view, reach contours, and a wildcamp planner that says honestly when the analysis backend is not on this server. The first fix of the sprint was humbling: the slope-coloured terrain strip had never rendered on prod — a graceful fallback had hidden a missing gateway rule for weeks.
Then we did something new: an independent audit of our own sprint. It
found a real boundary defect — the gateway allowlist could be walked out of
with encoded .. segments, turning every prefix rule into a door. Browsers
normalise those before sending, which is exactly why browser testing could
never have caught it. The matcher now refuses dot segments outright, the
client got its first-ever unit tests, and all seven follow-ups were acted on
the same day.
The first real browser pass found the rest: every vector layer on the desktop was blank (relative tile URLs, which a worker cannot resolve — no request, no error, nothing in any log), the proxy told browsers a gzipped tile was plain, raster basemaps silently dropped every text label, and the caching was exactly backwards — the mutable document was cacheable and the immutable assets were not. An audit that reads code and a pass that drives a browser find different bugs. You need both.
One more honest note: tier gating is now off by default. The tier line-up is not decided, the current accounts are all development fakes, and the pilot will run fully featured so that anything we might later gate still gets tested. The draft bundles are kept as drafts, clearly marked as not a product decision.
The tab-bar freeze finally gave up its causes, on device, with a watchdog: duplicate navigator trees stacked by deep links, a frozen scene left on top still eating taps, sensor readings written to the store 48 times a second, and one environment load firing ~100 parallel GeoJSON parses that blocked JS for 24 seconds. Each got a targeted fix rather than a workaround.
Also this week, at speed: the rally roadbook grew a 137-glyph symbol library in four dialects and FIA-layout print — A5 pages and a continuous moto-roll with cut marks; search learned the famous passes, so three keystrokes surface Stelvio instead of ten villages named Colle; the TET got a Europe-wide tap-a-trail overview map; and Settings was regrouped around how riders actually think, in ten languages.
Dig deeper: the desktop client and the rider app guide.
]]>This week we stopped renting.
Phase 0 was Norway, behind a flag: planetiler over the Europe PBF we already
host, our own style, our own self-hosted glyphs — because self-hosting the
fonts is the difference between owning the basemap and owning only the tiles.
Surface is a first-class visual channel in it: unpaved roads render ochre with a
dashed casing, so "can I take the GS down there" is answerable at a glance. An
absent surface tag stays neutral — overclaiming gravel is worse than saying
nothing.
Phase 1 was all of Europe: 28.96 GB, 22.7 million tiles, 53 minutes on 24 cores. Verified by content, not exit code — the Champs-Élysées, Unter den Linden and the Colosseo each have to decode out of their own tile, because a continental build can lose a whole region while every other check stays green.
Then the rest arrived in days rather than months: hillshade and contours from our own GLO-30 DEM (Galdhøpiggen decodes to within ~10 m of its true summit — wrong georeferencing would miss by hundreds), POI icons with a palette that survives mid-zoom, a layer manager, tap-a-POI-to-identify, 3D buildings, a device-side tile server so the basemap works offline, and an unpaved-density heatmap pilot — because we measured that overview-zoom tiles simply do not contain the dirt, so no styling could ever answer "where is the riding".
Honesty corner: terrain tiles briefly stalled the whole API at low zoom, a style-spec subtlety silently dropped an entire contour layer, and the new map stays behind its flag until the cartography earns the default slot. It is ours now; it is not yet better. That gap is the roadmap.
The same DEM work pulled GRASS into everything. Per-country slope derivatives served as COG mosaics, an elevation/slope/aspect profile along any track, walking-cost services, wild-camp spot scoring refined on 1 m national DTM patches, and ice-risk that now casts actual shadows with r.sun at the hour you will ride past — a shaded hairpin at 8 a.m. and the same hairpin at noon are different roads in October.
Sweden's 1 m elevation went in without mirroring the 1.2 TB national product:
we fetch only the tiles a route corridor touches. And the week supplied its own
lesson in humility: in a lat-lon location, r.walk was quietly counting
degrees as if they were metres. Everything walk-related now runs in a metric
projection, with a sanity guard so that class of bug cannot ship silently again.
On the phone this surfaces as a climb strip, grade badges and an ice-risk panel; on the desktop as slope shading with a legend.
Offline routing on region packs was crashing on device with std::out_of_range
while the identical pack routed fine on the server. We root-caused it three
times in three days, and the first two answers were wrong.
First: "the packs are an incomplete graph subset." Second: "the August EU tile
builds are corrupt — suspect the faulty CPU core." Both fit the evidence; both
were disproven by the next experiment. The true cause was in our own mobile
wrapper: it installed a tile-download getter even for local packs, so the
first out-of-pack tile reference — normal and harmless when there is no getter —
walked into a substr on an empty URL and threw. The server never reproduced it
because server tools never install a getter.
No tileset was ever corrupt. No rebuild was needed. The fixed engine is pinned, reproduced and verified off-device in seconds instead of on a physical iPhone, and confirmed on production Norway and Spain packs. The lesson we keep re-learning: a plausible root cause that fits the evidence is a hypothesis, not an answer.
Full-duplex calling met two real phones, and the phones won the first round. The fixes that came back: answering must go through CallKit, never around it — iOS refuses the app an audio session while a call sits unanswered, which is a connected-but-silent call; and a media library was deactivating the shared audio session a tenth of a second after any of its players stopped, tearing the floor out from under the live call. Hang-up races, ring cancellation and TURN over port 443 all landed the same day.
A security audit got paid down: fail-fast on weak secrets, login lockout, session epochs, SSRF-hardened URL imports, non-root containers, authenticated Redis. And the confession that started the visibility push — this repo had no CI at all, and the desktop client once sat broken for a week while Swarm served a stale container that looked perfectly healthy. Now there is CI, a daily deploy-drift check that messages Telegram only when something is wrong (a monitor that says "all good" every morning trains you to ignore it), live probes that exercise routing and geocoding end-to-end, every install reports exactly which build it is running, and the SOS bot has a watchdog — a dead emergency channel must make a noise.
Four more countries joined the EU set (Luxembourg, Ireland with NI, Malta, Cyprus). SOS alerts now speak the contact's language. A portable cold-archive drive got a scriptable toolkit — after we measured the real link speed and the economics of restoring flipped. And enabling Redis AOF on an existing dataset can boot you into an empty database; we hit it, recovered, and wrote it down.
Dig deeper: offline data on the rider app, and the data products behind the new basemap.
]]>Not any more.
Epona now controls GoPro over BLE and the Insta360 X4 through its SDK. Start and stop recording from the app, from the CarPlay screen, or from a helmet button — without taking a hand off the bars, which is the only interaction model that matters at speed.
Two cameras, two entirely different integrations. The GoPro speaks a documented BLE protocol; the X4 needs Insta360's own SDK compiled in. Presenting them as one feature took more work than either one alone.
Every shot is written to a shot log and dropped into the ride as a GPX waypoint. When you sit down to edit — days later, looking at four hours of identically-named files — you already know which clip was the pass and which was the roundabout you filmed by accident.
That is the part we are most pleased with. The camera integration is convenient; the log is what turns a pile of footage back into a ride.
The two cameras are genuinely different, and the app now respects that instead of pretending otherwise: only the GoPro gets the Wi-Fi transport switch, and the X4 shows a read-only camera card rather than offering settings that BLE cannot deliver. Better to say "not available here" than to fail silently after a tap.
Two scripts that will save more hours than they look like: release-to-phones.sh
builds one release with CarPlay enabled and installs it to both dev phones,
and release-to-android.sh produces one release APK with Android Auto on and
pushes it to any adb target.
Small tools, enormous effect. The gap between "the build works" and "the build is on a bike" was twenty minutes of remembered incantations, and a twenty-minute gap is why field testing happens on Saturdays instead of on Tuesdays. It is now one command.
Daily Geofabrik diff updates on the self-hosted Overpass instance, applied automatically. The POI data behind fuel, food and services now ages in days rather than quarters — so a fuel station that opened last month is a fuel station you can route to.
A pipeline fix worth naming, because it was a genuinely nasty one. Valhalla treats a missing administrative database as a warning, not an error. A tile build pointed at a path that did not exist finished successfully and shipped tiles with no country data at all — which silently switched off legal-speed defaults and mph display hints across the app.
The pipeline now builds admin.sqlite explicitly, forces the host path, and
hard-fails any build whose log mentions a missing admin database. A green exit
is not a result.
Camera, car screen, helmet, phone, desktop — the ride is becoming one continuous thing rather than five devices you reconcile afterwards.
There is a lot more of this to come.
Dig deeper: the rider app guide, and riding together for the CarPlay and safety side.
]]>The best bug reports come from things that never threw an error.
32 of 64 regions had no POI import. Ireland had zero fuel stations. Nothing errored, nothing alerted, no log line said so. The map looked exactly as a map should look — the fuel stations were simply not on it, and you would only find out by needing one.
A dark sky near Bergen returned nothing. A rejected request was rendering as an empty result, which is indistinguishable from a truthful "no stargazing spots here" — and a user has no way to tell the difference between an app that found nothing and an app that failed to look.
Both are now fixed, and both are the reason for everything below.
A quarterly EU data-refresh pipeline, written down as a runbook rather than lived in someone's head: fresh Geofabrik extracts for 32 countries, legal-maxspeed injection for the nine countries with statutory speed tables, an osmium merge into a single PBF — multi-PBF Valhalla builds segfault — TET overlay re-application, the tile build, and a route benchmark harness that compares the new tiles against golden routes before anything goes anywhere near live.
The overlay step has a subtlety worth naming: OSM churn deletes nodes that the trail conflate still references, so the pipeline resurrects the missing ones from the previous run's augmented extract. A sudden jump in that count means the overlay has aged out and needs re-conflating, which is a much better signal than discovering it in a broken route.
It is pinned off a faulty CPU core on the build host, because a tile build scheduled onto that core corrupts the routing graph rather than crashing — which we know because it did, and because a corrupt graph fails days later in a place with no signal.
Legal speed limits now come from an on-device profile computed with Valhalla's
traceAttributes, so the HUD sign works with no signal at all.
Most European roads carry no explicit maxspeed tag in OSM — the limit is the
national default for that road class, which every rider knows and no database
states. So the profile fills those gaps from statutory tables, falls back to live
data when it has a connection, and lets a detected camera override everything.
Three sources, one number on the screen.
A pack freshness manifest, and update-available badges driven by it: the phone compares each installed region's tileset version against the server's and badges only what is genuinely behind.
Plus the fix that made them honest. A stale pooled SQLite handle had the badge looping forever, insisting on an update that had already been installed — the single fastest way to teach someone to ignore a badge permanently.
The beach seeker stopped being Norway-specific. Sweden shipped — sea and lake both — with an SGU jordarter geology prior doing the heavy lifting, and per-region crowdsourced review pages so riders can correct it.
Italian-locale address search was quietly falling back to a different geocoder after a 400 error. The vehicle register writes "901 Norden" while Husqvarna writes "Norden 901". The odometer is now anchored rather than inferred from GPS, because inferring it was always going to be wrong eventually.
Every feature we ship stands on this. A gorgeous route on stale tiles is a beautiful lie, and we would rather ship a plain truth.
Dig deeper: the developer docs for the manifest format.
]]>It seemed like the right name for the thing in your tank bag.
The rider app is now Epona. EpicRide is the desktop planner. FastGIS is the platform and the API underneath both — the thing that serves 346 endpoints to all of them.
Deliberately, the infrastructure did not follow. Service names, package identifiers and hostnames stay exactly as they were, because renaming the plumbing to match a product decision is how you spend a fortnight, break a deployment and gain nothing a user can see.
The display name now lives in one file per client, reached everywhere else through a constant or an i18n variable — and there is a test that fails if someone hard-codes it again. The next rename is two edits instead of an archaeological dig.
The TET explorer shipped: the whole catalogue on a globe you can fly. Three rounds of polish went into making it feel considered rather than technical — the camera aims itself at the trail instead of at empty ocean, the overview stays legible at continental zoom, only one section card opens at a time, and on a phone it gets out of the way entirely and hands the screen back to the globe.
A 3D globe is easy to build and hard to make legible. Most of the work is deciding what to hide.
And adv.fastgis.eu was rebuilt as a single 14,300 km ride across Europe —
one continuous story rather than a feature grid. If the product is about the
ride, the landing page should be a ride.
Weather along the route now refreshes during the ride, re-sampling ahead of you as you go. A forecast fetched three hours ago at the start of a long day is a historical document, not a prediction — and the rain it did not mention is still rain.
Centaur, Pegasus and Alicorn — with the entitlement system rebuilt to be rail-agnostic and subtractive from the top. The app ships complete, the highest tier holds everything by construction, and each lower tier is defined by what it keeps rather than by features bolted on.
That inversion matters more than it sounds. Additive tiering means every new feature needs a decision in every plan, forever; subtractive means a new feature is included by default and you decide once where to cut. Moving a feature between tiers is one value in one registry, and admins can grant or revoke per plan at runtime with no deploy.
Which mythological creature you are is, we admit, the most fun product decision we have made all year.
A name is a small thing that makes everything after it easier to talk about. Now back to the riding.
Dig deeper: accounts and tiers, and the rider app.
]]>The layers panel was rebuilt layers-first, with track cards folding into expandable rows — the previous shape drowned once you had a dozen tracks loaded. Route legs can be dragged to insert vias, so shaping a route is a gesture rather than a form.
Elevation profiles run the full length of the route and hover-pin onto the map as you scrub them: put the cursor on the climb and the map shows you where the climb is. There is a measure tool, compass and rotation, per-layer styling that survives being included in a route, and a basemap catalogue with Standard, Satellite, Hybrid and vector styles.
Riding modes landed too: configure them once on their own page, then assign a mode per leg from a catalogue. The same trip can be motorway to the mountains and gravel once you arrive, without planning it as two separate routes and reconciling them by hand.
QGIS-style editing, and full vertex editing on group tracks — loops, TET trails, imported GPX — which is where most browser editors give up. Live drag preview shows the reroute as you move the point rather than after you drop it.
There is undo/redo at the top of the panel, and sketch persistence, so closing the tab is an inconvenience rather than a catastrophe. Edit mode is an explicit toggle: you cannot nudge a carefully built route by mis-clicking on it.
Curvy roads. TET with multi-country selection. MTB with trail merging along OSM ways — because a single trail is usually a dozen disconnected OSM fragments — plus reach-the-trailhead routing and per-trail stats. Beach seeker. Friluftsliv as full cards with info, map-select, range and free-text filtering.
Select on the map and the matching result card reveals itself; select the card and the map follows. Two-way selection sounds obvious and is the thing that makes a results list usable at 300 items.
Plans save and load in full. Library items show map previews and full-extent card previews. There are landing pages per item, ratings, owner title editing, audience sharing, and Friends and Groups. What you plan on the desktop is what your phone already knows about.
Two Valhalla ceilings got fixed rather than worked around. A 50-location cap
surfaced as a cryptic error 150 with no hint that a limit existed; the client
now chunks the request and stitches the result. And the distance limits were
raised to 4000 km, so planning Norway to Portugal does not require splitting the
trip in half and pretending that was your plan.
There is a real division of labour now. Plan on the desktop with everything visible at once; ride with the phone, offline, with the plan already there. Each does what its screen is good at, and neither pretends to be the other.
Dig deeper: EpicRide.
]]>It went from pipeline to product in six phases: the EU extraction, the /mtb
API, access-by-car and lift scoring with faceted search, a mobile trail overlay
and browse screen, offline trail tiles, and an on-map search library that behaves
exactly like the curvy-roads search — same gestures, same filters, same
scroll-to-card on a map tap. A rider who has learned one search should not have to
learn another.
The access scoring is the part we would defend hardest. A trail you cannot reach is not a trail you can ride, so the catalogue knows whether you can get there by car and whether there is a lift, and lets you filter on it.
Then performances: segment timing that records as you ride, with GPS auto-start and auto-stop so there is no button to remember at the top of a descent. Afterwards you get a detail screen, a chart, and an elevation-and-surface bar — how much of that climb was gravel is a more interesting question than how fast you did it.
43,048 Norwegian outdoor-recreation points from four sources — and, unusually, the API tells you the licence of every single one. Two sources are NLOD 2.0, one is share-alike ODbL, and one is open with no named licence at all, which is not the same thing as public domain however much you would like it to be.
GET /friluft/sources returns that per source, with the attribution string you
owe and whether share-alike propagates to whatever you build. Most APIs put this
in a footer nobody reads. We put it in the response.
The loop generator can now weave curvy roads and beaches into the loop it generates. Ask for 200 km and it threads the good roads through the middle, rather than handing you a circle that happens to have nice bits somewhere near it.
We also taught it to detect and repair geometry-level dangles. Norway is full of roads that run out to the end of a fjord and stop; a loop generator that does not know this will cheerfully route you out and back down the same 40 km and call it a circuit. It now spots that shape in the geometry and repairs it.
Optimised routing shipped — the travelling-salesman problem, on a motorcycle. Give it a set of stops and it orders them properly, both on the server and on the device, so re-optimising after you add a stop works with no signal.
Multi-day trip planning stopped being an exercise in dragging list items around and squinting at the total. It needed Valhalla's matrix distance ceiling raised to cope, which is the sort of limit you only discover by hitting it.
Category and spatial context in Phase 1, a deterministic CPU spell corrector in Phase 2, and a warmed local LLM in Phase 3 so the rare hard query does not pay an eight-second cold start.
User profiles with avatars, a garage and riding styles. And two security passes — eleven launch-blocker findings in one, a fourteen-point desktop audit in the other — plus per-tenant Postgres isolation, off by default until it has earned its confidence.
Three became ten, with a first-run safety acknowledgment. Europe is not an English-speaking continent and we would rather not pretend otherwise.
Dig deeper: data products covers MTB, friluftsliv, beaches and curvy roads, licences included.
]]>Your generated story is now a draft you can edit. Changes are stored as an overlay on top of the generation rather than replacing it, so the original is never destroyed and you can always see what the machine said versus what you said. Republishing is selective: fix one caption, rebuild that story, keep everything else exactly as it was.
That overlay model is the whole design. Regenerating from scratch to fix a typo is how people learn not to fix typos.
Around it, a set of blocks worth having:
Every enrich block is strictly validated before it renders, with localized thumbnails and proper renderers per block type. A block that fails validation is not rendered at all — no half-drawn card, no placeholder. Showing nothing is a better failure than showing something wrong on a page you are about to send to your friends.
There is now an Edit story button on the phone with a pre-authenticated handoff to the editor — you tap it, the browser opens, you are already signed in. No copying a URL, no logging in again on a laptop while the moment passes.
Creating and sharing a StoryMap from mobile captures works end to end, with a sync gate so you cannot publish a story whose photos are still sitting on the phone, and explicit warnings when a bake would produce something incomplete. The failure mode we were designing against is the one where you proudly send a link and half the images are missing.
We also made the story page work on a phone screen, and stopped the Edit button falling off the edge of its own card.
Elsewhere entirely: the beach seeker pipeline for Norway shipped — sandy-beach discovery from open geodata, stages zero through five, sea and lake both.
It began as a joke about where to stop for lunch. It is now a dataset, and it is a good demonstration of what the platform is for: the question "where can I swim near this road" is a spatial analysis problem, and there has been a GIS sitting underneath this app the whole time.
The editor is the moment the AI stopped being the author and became the first draft. That is the right relationship, and everything downstream gets easier once you accept it.
Dig deeper: stories, and data products for the beach data.
]]>Come off a TET trail and the old behaviour rebuilt the whole thing from scratch. Now the reroute trims the original trail — instantly, with turn-by-turn preserved, no round trip to a server you may not be able to reach.
You rejoin where you left. Being handed a brand-new plan for a ride you are already halfway through is technically a reroute and practically a betrayal.
Per-region tile_dir installs replaced the previous scheme, which had a habit of
working perfectly right up until it didn't — and failing in a way that was hard
to diagnose from a layby. Each region now installs into its own directory, so a
corrupt or half-downloaded pack takes out one country rather than your whole
offline setup.
Field fixes went in alongside it, plus some navigation and voice work recovered from a branch that had quietly drifted out of sight.
Two smaller ones with outsized effect. The app now takes microphone input from a Bluetooth helmet, which is the difference between voice notes being a feature and being something you actually use at 90 km/h.
And the map can overlay all your rides at once. Watching a season accumulate as one tangle of lines across a country is unreasonably satisfying, and it also shows you — instantly, without any analysis — the parts of your own region you have somehow never ridden.
Fuel and campgrounds ahead along your route — not "near you", which is useless at 90 km/h — with one tap to add as a stop.
Every one of these was invisible until someone rode with it. So we will keep riding with it.
Dig deeper: the rider app guide.
]]>The enrichment gateway shipped, and with it the flagship: point it at a recorded ride and it produces a StoryMap — a scrolling narrative where the 3D globe flies along with the text, your photos land where you took them, and the prose is grounded in where you actually were rather than invented.
Generation is a job, not a request. You start it, it runs in the background, you get a notification. Writing four days of riding takes longer than an HTTP timeout allows, and pretending otherwise produces a spinner nobody trusts.
It reads your media too. Audio and video samples are transcribed through the media-AI gateway, so the voice note you recorded at a viewpoint — helmet on, engine running, describing the road you just rode — becomes part of the story instead of a file you never open again.
Then it narrates. Text-to-speech per scene, in multiple languages, with the narration switching when the reader switches language — so a story from a Norwegian ride can be read aloud in Italian to someone who will never see the fjord otherwise. The translation and the speech are generated together, so the voice matches the text on screen rather than reading an English original with an accent.
The interesting work was not generation, it was restraint. Three fixes tell the story:
Per-capture storage actions, direct sample visualisation, inline previews you can view and share over the map, and media that keeps streaming from the server after you delete the local copy to free space. Your phone fills up on a long trip; that should cost you storage, not memories.
Orphaned captures — samples whose session record went missing — now recover instead of dead-ending on a screen that told you nothing.
Also: photos captured in-app keep their GPS. Expo's image re-encode was silently stripping the EXIF location — every photo any of us had taken in the app was ungeotagged, and nothing had ever complained. Coordinates are now injected at capture time, and everything shot before the fix was backfilled server-side from the position the app had already recorded alongside it.
A ride you cannot show anyone is a ride that slowly stops existing. We would like the good ones to last.
Dig deeper: stories covers generation, editing and publishing.
]]>The navigation HUD now renders on the car screen. Getting there took a scaffold, a gated config plugin, an absolute-fill layout and a self-healing install — the sort of list that looks like nothing and takes a week.
CarPlay is unusual to build for because you cannot iterate on a simulator and trust it; the head unit has opinions the simulator does not. It is on a real device now, it survives a reconnect, and the install steps are written down so the next person does not rediscover them.
Here is a scenario we got wrong, and then got right.
You are riding a road bike profile toward a trail. The router knows the trail exists. What should happen when you reach it?
The naive answer is "recompute", and the naive answer strands you: the recompute throws away the trail and sends you around by road, because by every metric a router optimises for, the road is better.
So we made the vehicle switch on a trail into an approach rebuild — car profile to the trail head, bike profile on the trail itself — and made keeping the trail the default, with road-to-end as an explicit choice you make rather than one made for you. The router is very good at answering the question it was asked. Most of this work is asking it a better one.
Detecting that you are on a trail at all turned out to need two independent signals: a structural one — a routing leg with no manoeuvres in it, because trails do not have junctions to announce — and an on-trail projection guard that checks where you actually are against the trail geometry. Either alone produces false positives on a long empty road. Together they hold up.
Three of them, all in the same fortnight:
None of these are features. All of them are the difference between an app you trust on a long day and one you don't.
Self-hosted Photon for European geocoding, a zero-result relaxation ladder,
and an LLM rung behind an explicit ?deep flag. When the search finds nothing,
the phone loosens the query a rung at a time rather than shrugging.
The LLM rung needed the most care, and the fix was mostly saying no to it: the prompt is hardened against inventing place names, because a geocoder that confidently returns a village that does not exist is worse than one that returns nothing at all. Tuning the prompt to a "rules" variant took the small local model from 71% to 88% on our benchmark, which is the difference between a feature and a liability.
More car screen, more trail. The two ends of the same ride.
Dig deeper: the rider app guide covers navigation and the trail behaviour.
]]>Not a checkbox — the real thing, over your own GRASS data:
callback conformance class so a job can push to a subscriberWhich means: open QGIS, add a connection, and your analysis is there. No export step, no format conversion, no "can you send me a shapefile".
Processes is the one we think is underrated. Your allowed GRASS modules are
exposed as OGC jobs — you POST an execution, poll the job, collect the results —
and with the callback class the job pushes to you instead. A slope analysis
over a big raster stops being something you sit and watch.
We also fixed the small things that decide whether a standards client actually
works — advertising the service-desc link so QGIS accepts the landing page,
emitting https hrefs from behind the proxy, and parsing GRASS's binary
floating-point range so raster metadata is right.
Realtime location sharing shipped: a WebSocket fan-out over Redis pub/sub, friends, and named groups. Share to the people you choose, for as long as you choose — it is a session you start, not a setting you leave on and forget.
Friendship is two-sided; you request, they accept. Nobody appears in your audience because someone typed your name. The desktop viewer grew a "Live Riders" panel, and the phone shows peer markers moving in something very close to real time, because Redis pub/sub means a position update fans out to twelve people without twelve database round trips.
Per-client API tokens landed at the same time, so a phone and a desktop browser can hold separate concurrent credentials for the same account. Revoking your laptop should not log out your motorcycle, and losing your phone should not mean re-authenticating everything you own from the side of a road.
A spec-driven survey renderer on the phone, a designer on the desktop, and a schema contract between them — so a form you design in a browser renders natively on a phone in a field with no signal, without anyone shipping an app update.
Turn-by-turn trips now record themselves into a ride logbook automatically. No "start recording" to forget; if you navigated it, it is in the book.
And Android got its first two phases in quick succession: an online-only build, then on-device Valhalla routing — the same offline engine iOS runs.
Everything here is the same instinct. Your rides, your data, your tools — reachable from whatever you already use, and shareable exactly as far as you decide.
Dig deeper: riding together covers sharing end to end, and the developer docs have the OGC recipes.
]]>So this fortnight we made the phone stop needing us.
Valhalla now runs on the phone. Not a cached route, not a downloaded corridor — the actual routing engine, with the actual tiles, computing an actual route with no server in sight. Lose signal mid-ride and navigation simply continues, including a full recompute if you miss a turn.
Getting a C++ routing engine onto a phone is less glamorous than it sounds. The tiles install per region rather than as one monolith, so adding Austria does not mean re-downloading France, and the engine is bridged natively rather than run through a JavaScript shim that would melt the battery.
Spoken navigation came with it, and the rider picks the language and voice independently of the app's interface language. Your phone can be in English while the directions are in Italian, which sounds like a small thing until you are in Italy trying to match a spoken street name to a sign that spells it differently in your head.
The TET augmentation pipeline landed, and it is not a map overlay. The trail data is folded into the routing graph itself, so the router knows a trail is rideable rather than drawing a line over roads it would rather use. That is deployed to the EU server and available offline through baked bundles: import a country, ride it without a connection.
The difference shows the first time you ask for a route that ends on a trail. An overlay gives you a pretty line and directions to the nearest tarmac. An augmented graph takes you down the trail.
Full Italian and Spanish translations shipped with an in-app language picker, on top of the i18n groundwork. A rider in Palermo and a rider in Bergen should get the same app, not the same app in someone else's language.
Multi-user accounts arrived, with a password policy enforced on every path that touches a credential. Siri phrases and App Intents mean you can start a ride without touching the screen. The capture workflow was rebuilt around an explicit Idle → Recording → Paused shell, and then audited four times over — thirteen bug fixes in one pass, orientation handling in another.
That last part is not glamorous. It is also why the app will still be recording when you get back.
Offline is not a feature you finish. It is a promise you keep extending: maps, then routing, then search, then everything else. We are two steps in.
Dig deeper: offline data covers what downloads and when, and the developer docs have the manifest format if you want to build against it.
]]>Valhalla is now wired in properly: real turn-by-turn directions, isochrones, time/distance matrices, and — the one we were most excited about — a loop generator. Give it a start point and a distance, and it samples waypoints by angle, tunes how far it reaches, and hands back a ride that comes home.
Most routers can get you from A to B. Getting you from A back to A is a genuinely harder problem, and a much more useful one for anyone riding for the pleasure of it rather than to arrive. A naive implementation picks three random points and gives you a triangle with a motorway down one side. Sampling by angle from the start, then tuning how far out each arm reaches, is what turns that into something you would actually ride. It also persists its state, so tweaking a distance does not throw away the shape you liked.
The mobile foundation landed alongside it: GPS integration, POI clustering, and the first round of usability work that only shows up when you actually hold the thing at a junction. Clustering sounds like a detail until you zoom out over a country and the map tries to draw forty thousand individual pins.
The vector editor grew up considerably — digitise, select, move, vertex-edit, write attributes. The DB Manager arrived, so you can inspect the SQLite or PostgreSQL table behind a layer without leaving the browser.
There's a measure tool that does proper geodetic length and area rather than pretending the world is flat — over a few hundred kilometres at Nordic latitudes the difference is not academic. And the GRASS → mago-3d-terrainer → CesiumJS pipeline turns a raster DEM into quantized-mesh terrain you can actually fly over, which is a much better way to understand a mountain pass than a contour map.
The interesting thing about building a rider app on top of a spatial analysis platform is that the analysis does not go away — it becomes the thing that makes the routes good. Every algorithm already in GRASS is, potentially, a way of deciding which road is worth riding.
We are just getting started on that.
Dig deeper: the routing tool and the terrain builder both have guides now.
]]>