mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-18 21:16:47 +00:00
41b18f970c320d9d82bffdde41fbcba4d4c8e5ba
361 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Maurice
|
41b18f970c | feat(vacay): add manual school holiday calendars | ||
|
Maurice
|
2c06c9904b |
feat(collections): a list as a file, so it can leave the instance (#2198)
Sharing a list works between people on the same TREK. This is the other case: giving one to somebody who runs their own, or keeping a copy. Export sits beside Edit and Share in the list header and downloads the open list; Import sits beside New list in the rail, reads a file, shows what is in it and makes a new list of it. Desktop only, which the route already decides. What travels is what somebody wrote down: the list's name, colour and description, its labels, and each place with its address, coordinates, notes, status, contact details, category name and labels. A file is dull JSON on purpose, so it can be read and edited by a person. What does not travel is everything that only means something on the instance it came from. Ids of every kind, since the receiver issues its own and a category crosses over by name. Star ratings and members, because a rating is an opinion somebody gave the people on that list. Provenance into trips, which points at rows the receiver cannot see. And an image path under /uploads, which resolves on the sender's server: only an absolute https URL survives. A file is a stranger's JSON and is read as one. It is parsed in the browser that chose it and never uploaded; the parsed list goes through the same contract on both sides; and a link that is not http(s) arrives as nothing rather than as an anchor. Strict where it must refuse, forgiving where it can drop: a file that does not say what it is never reaches the importer, while one unreadable place inside it is skipped and counted, and one bad field on a good place costs that field alone. An import is always a new list. Importing into an existing one would mean deciding what happens to a place that is already there, and every answer to that is a merge nobody asked for. |
||
|
Maurice
|
a8e4c45576 |
feat(share): show a stop and a booking in full on a shared link, and no more (#2320)
A public link showed a stop as its name and one line under it, the address or the description, whichever came first. The owner had written both, and a note on the place and another on the day, and had set how long they meant to stay and how to reach it. All of that shows now, laid out the way the planner lays it out, and every link leaves the page in a new tab with no opener. A booking shows the note the owner attached and the page they linked, labelled by where it goes. What travels to the page is chosen column by column now, where it used to be the whole row. The whole row of a booking carried its confirmation number, its import trail and its raw metadata, and the metadata is where an imported ticket keeps its seat and its record locator; the whole row of a place carried the owner's booking notes on it and the Google identifiers. None of that belongs to somebody holding a link. Metadata keeps the parts that describe the journey, by an allow-list, so a field the import starts writing tomorrow does not become public by appearing. Links are accepted only as http or https, on the server and again on the page. |
||
|
Maurice
|
a00cc889ed |
feat(roadtrip): show every change to a road trip live to everyone on it
Two people shaping one drive were each editing their own copy: a via dragged on one screen reached the other only on the next reload, and the route it changed looked settled until then. Every write in the domain now announces itself over the websocket the rest of the trip already uses — the five REST routes and the matching MCP tools alike, so an assistant moving a stop is as visible as a person doing it. Two new trip-scoped events carry it: roadtripVia:changed with the day's whole via list, and roadtripTrack:changed. The whole list rather than a delta, because a via is identified by its position in a chain and a delta protocol would need an ordering guarantee to be worth anything. The originating socket is excluded through the X-Socket-Id header the other domains already forward, so nobody watches their own change arrive twice. |
||
|
Maurice
|
59b7c35e87 |
fix(roadtrip): re-pin a via to the leg it was dragged onto
Dragging a via somewhere else on the map changed where the point IS and never where it sits in the chain. The anchor that decides which two stops it is threaded between was worked out once, when the point was dropped, and the drag sent only coordinates — `roadtripViaUpdateRequestSchema` carried a lat and a lng and nothing else. So a via pulled past the stop it used to precede kept claiming the earlier leg. The router then drove out to it and turned back before carrying on, which on screen is not a subtly wrong route: it is a spur that reads as the drag having done nothing at all, with the original road still sitting there unchanged. The anchor is not a property of the point but of where the point sits along the drive, so it is recomputed on a drag the same way it is on a drop. The projection that did that was inline in addRoadtripVia; it moves to a shared `anchorFor` and both callers use it. A drag differs from a drop in two ways, both deliberate. It measures against its OWN day: letting the nearest day win, which is right for a click on open map, would hand the via to a neighbouring day whose road happens to pass closer and make it disappear from the day it was dragged in. And it has no 2 km guard: pulling a via well off the current road is exactly what the gesture is for, and the anchor only says which leg gets bent. `after_order_index` is optional on the way in, so a drag inside one leg and an older client still send just the coordinates, and the stored pin is then left alone rather than cleared. |
||
|
Maurice
|
77162aa8d5 |
feat(roadtrip): avoid tolls, motorways and ferries, through a second engine
The switch a road tripper keeps asking for has never worked. OSRM's `exclude` is the only
avoidance TREK has, and the two public hosts it ships with answer it HTTP 400 on every
leg: their car profile is built without excludable classes, and their own Lua says why
("no memory for classes on demo server"). So "drive this without the tolls" produced
nothing at all on a default install, and the fallback inside the alternatives bar quietly
gave up after one refusal per host.
FOSSGIS runs a public Valhalla on the whole planet next to that OSRM, keyless, and there
avoidance is a runtime weighting rather than a profile that has to be rebuilt. This adds
it as a second engine asked only the questions the first cannot answer, and puts three
switches under the road trip settings that change the road itself rather than offering an
alternative beside it. Paris to Lyon measured 465.8 km / 297 min with tolls against
492.0 km / 454 min without; Hamburg to Copenhagen comes back ferry-free at 469.8 km,
which OSRM cannot produce at all — where a ferry IS the crossing it answers NoRoute
rather than driving round.
Four things the docs would have got wrong, all measured against the live instance:
- `format=osrm` does not carry `has_toll`. That flag is the entire reason for doing this,
and it exists only in the native answer — which is also 5.7x smaller, because the OSRM
shape drags every intersection along. So the adapter translates instead of borrowing a
familiar envelope.
- Without a `radius` Valhalla refuses a point it cannot bind to a road, where OSRM still
snaps one. Vienna's Stephansdom, in a pedestrian zone, answers error 442 until a search
radius is allowed. TREK is full of such places, so every location carries one.
- Ten locations is a hard cap and a road trip day is bundled into one request. A day over
it is split into runs overlapping by one point, which is exact rather than approximate:
a measured six-stop day came back within two metres and under a second of the same day
asked whole.
- Its drive times run 5.4 % above OSRM's over ten European legs and 36 % above on one, and
those times feed the arrival clocks of a day. So a day is answered by one engine or by
neither, never by both, and a piece that will not answer loses the whole day rather than
half of it — the schedule chains leg times blindly and would otherwise print a complete,
plausible, silently wrong timetable.
Because the weighting can fail, the honest surface is the answer rather than the request.
`use_tolls: 0` still returns a tolled road where there is no untolled crossing, so what
the road actually turned out to be is read back per leg, and a day that could not avoid
what it was asked to avoid says so on its own header instead of wearing a label the road
disproves. The switches disable themselves, with a reason, on an instance pointed at its
own OSRM: that operator chose against public hosts, and a second one they never asked for
would undo the choice.
Two things that would have broken quietly and did not:
- The route cache keys on `profile:unit:coords` and is shared with the day planner, the
studio and the booking geometry. Without the avoidance in the key, flipping a switch
returns the old road out of cache in under a millisecond — and worse, an avoiding answer
stored under the plain key hands those other callers a road nobody drives.
- `snapped` is OSRM-only and carries the dashed kerb-to-door spur from #2273. Valhalla
echoes the coordinates it was given and never says where it bound them, but the ends of
a leg's line are exactly those points: measured against Füssen, its first vertex matches
OSRM's snapped location to the digit.
The alternatives bar gets the same engine, which finally makes its "no motorway" and "no
tolls" offers appear on a default install, plus a ferry-free one. `sameRoad` now compares
geometry rather than numbers there, because two engines' distances for the same road sit
kilometres apart and the old 200 m tolerance called that a discovery.
Desktop only, like the whole road trip mode: nothing under client/src/mobile renders it.
|
||
|
Maurice
|
29fc586930 |
test(maps): pin the coordinates a suggestion carries
The half of the change that saves the pick from a text search for its own label was covered by nothing. MAPS-AUTO-010 reads `source` and stops there; the client test writes the coordinates into its own mock and then asserts them. Delete `lat: p.lat, lng: p.lng` from the service and both stay green, while the fallback quietly goes back to searching for "Tokio Hauptbahnhof, 東京駅丸の内駅舎" and taking whatever comes back first. So the server test now asserts the coordinates on the wire for both indexes, and the mobile sheet — which carries a copy of the same fallback and had no test for it at all — gets one for the fallback and one for the source mark. |
||
|
Maurice
|
7ba7338f5f |
fix(maps): sag bei jedem Vorschlag, welcher Index geantwortet hat
Seit die Tipp-Suche beide Schichten fragt, ist ihre Liste gemischt — die Antwort nennt aber weiterhin EINE Quelle fuer die ganze Liste, und die heisst 'trek-places'. Der Client beschriftet damit jede Zeile, auch die aus OpenStreetMap. Wer tippt, liest also acht Mal "TREK" und schliesst daraus, die OSM-Schicht antworte gar nicht. Sie antwortet, sie steht nur unter falschem Namen da. Auf der Suchstrecke daneben stimmt es laengst: dort traegt jeder Ort sein eigenes `source`, und genau deshalb liest sich diese Liste richtig. Also traegt es jetzt auch die Zeile. Das Feld ist optional, weil Google und der Nominatim-Rueckfall je aus einer Quelle antworten; eine Zeile ohne eigene Angabe faellt weiter auf den Namen der Liste zurueck. Dazu die Koordinaten, die der Vorschlag ohnehin schon kennt. Bisher wurden sie weggeworfen, und wenn der Details-Aufruf nicht antwortete — Kill-Switch, ein ueberlasteter Overpass-Spiegel, irgendein Fehler oben — baute der Client eine Textsuche aus Name und zweiter Zeile. Bei einer OSM-Zeile ist die zweite Zeile aber keine Adresse, sondern der ortsuebliche Name: gesucht wurde dann nach "Tokio Hauptbahnhof, 東京駅丸の内駅舎", und dessen erstes Ergebnis wurde kommentarlos als der Ort genommen, den der Nutzer angeklickt hatte. Jetzt nimmt der Rueckfall den Punkt, den die Zeile mitbringt. Und das Abzeichen gibt es endlich auch mobil. Die Marke und ihre Tabelle liegen dafuer in client/src/utils/placeSource.ts, weil beide Oberflaechen dieselben Listen zeigen und ein Zeichen, das nur auf einer davon steht, schlimmer ist als keines. Was hier NICHT drin ist, obwohl es dazugehoert: dass der richtige Bahnhof in der Liste steht. Das liegt am Dienst, nicht an TREK, und ist dort gemessen und behoben — Rangfolge nach Art des Ortes plus die Verkehrsknoten, die der OSM-Schicht ganz fehlten. |
||
|
Maurice
|
fab3d2bdf8 |
fix(maps): ask the OpenStreetMap layer on the autocomplete path
Typing "Tokio station" from Tokyo suggested a weigh station in Ritzville and a
station in Tuxtla Gutiérrez, and typing "Tokyo Station" put Japan in seventh
place behind Markham, Arlington, Calgary, Milano and Melbourne. The station
itself was never in the list.
The service has had the answer all along. Its OpenStreetMap layer carries 14.6M
travel places with every name form each is known under, including the exonyms a
traveller actually types, and it is not the same data as the index: Overture
holds businesses, so a search for a station finds the shops inside it. The layer
returns "Tokio Hauptbahnhof" for the German spelling and 東京駅 for the Japanese.
It was never asked. `sources` defaults to the index alone and trekPlacesSearch
never sent the parameter, so no caller here has ever seen a layer row.
Sent on the autocomplete path only. The explicit search asks Nominatim in
parallel and would get the same OpenStreetMap places twice; this path asks
nobody else, because Nominatim's usage policy names autocomplete as
unacceptable use. So the layer is not a second opinion here, it is the only
place those names live.
A layer row has a different shape, and that shape is why this is more than one
parameter. It has no `gers` and no address block, and its id reads
`osm:node/9712313` where this file resolves `node:9712313`. Passing it through
untranslated would hand the client an id getPlaceDetails does not know, and the
failure would land after the user had already picked the suggestion. The
secondary line falls back to the local name, which is what is written on the
building and more use under a translated label than an empty line.
Measured against the service before the change, same query, same coordinates:
"Tokio station" index only -> Tokio Weigh Station, Ritzville US
with layer -> Tokio Hauptbahnhof in second place
"東京駅" index only -> six restaurants inside the station
with layer -> 東京駅 itself in the list
|
||
|
Maurice
|
d30b916f9c |
feat(maps): count how much routing an instance actually does
Every route is calculated in the browser against the public FOSSGIS hosts, so the server never sees a routing request and nobody has a number: not how many a real trip costs, not how big they are, not how much already goes to a self-hosted engine. Deciding whether TREK could run its own router without that number is guessing at the bill, and the counters have to be collecting before the question comes up. Counters, not a log. A row is a day, a profile, a request kind and an engine kind with totals on it: how many requests, how many waypoints, roughly how far, how many were refused. No query, no coordinate, no route, no user, no trip. Nothing leaves the instance: its own database holds them and its own admin reads them at GET /api/route-usage/summary. The client tallies in memory and flushes in batches — on a timer, past a threshold and when the page is hidden — because a counter that cost a request of its own would measure the load by adding to it. Routing all funnels through one fetch in RouteCalculator, so that is the only place instrumented. On by default and switchable off with route_usage_enabled, unlike the shadow log next door: that one stores what people typed, this one stores four integers about a day. |
||
|
Maurice
|
a463246c1c |
fix(tests): let the spool handler stub carry a payload
`ReturnType<typeof of>` resolves against the zero-argument overload, so the
stub only accepted `Observable<never>` and SPOOL-001 could not hand it the
`of('ok')` it needs. tsc -p tsconfig.tests.json broke on it, which sank the
server preflight job and with it every coverage job that needs it.
|
||
|
Maurice
|
2a38e79431 |
test(collab): cover the image upload path and the spool cleanup
The chat images never reached a test: committing them to storage, taking them back out when a later one fails, and dropping them again when the reply target turns out to be gone. The interceptor that removes the spool when a request dies before the handler had none either, and it sits in a domain pinned at 99% function coverage. Both filters are pinned too, including the disguised extensions that were the point of changing them. |
||
|
Maurice
|
7e3b9fd039 |
fix(collab): keep every panel on screen, and stop leaking spool and links
The desktop layout rendered notes and links as a pair and dropped whichever of the two was on its own, so turning the new Links feature off on an otherwise default install made the Notes panel disappear. Both rows are now split by kind and rendered only when they hold something, and one function decides what a panel id renders, because the branch that lost a panel did so by not listing it. The message and its attachment rows are written in one transaction. The caller has already committed the image bytes by then, so a message that landed without them left those bytes with nothing pointing at them and nothing to sweep them. Deleting one now drops the blobs after the rows are gone rather than before. A body the Zod pipe rejects used to leave up to four spooled images on disk: pipes run after interceptors, so multer had already written them and the handler's own cleanup was never reached. An interceptor removes them on any failure before the handler, which also covers every other schema mismatch, and the length check that could never fire is gone. Adding, pinning and deleting a link now says something when it fails instead of raising an unhandled rejection, the list has real types, and the rejected-image toast is translated in all 23 locales rather than shipping English everywhere. The picking, previewing and clearing of chat images moved into one hook both shells use: it was copied into two, and both rebuilt every preview on each change and leaked an object URL per image per pick. Tests: the four link routes end to end with the validation pipe the harness was missing, the image filter against the disguised-extension case, and the layout combinations that drop a panel. |
||
|
Maurice
|
07bb899c50 |
fix(collab): close the image upload hole and the guard trap
The chat image filter believed the Content-Type the client put on the part. The stored name keeps the extension of the name the client sent, and the download route derives what it serves from that extension and sends it inline, so pwn.html declared as image/png came back as HTML on our own origin. The filter now checks the extension as well, against the blocked list and against the types it claims to accept, because a per-route filter fully replaces the module-level one it looked like it was adding to. The multipart message route also kept its guard decorators. Guards run before the interceptor, so a refusal went out while the client was still streaming up to four images and the socket died as ECONNRESET rather than carrying the error. The checks moved into the handler, where the other upload route in this file already does them, and a test pins both refusals. The three collab:link events were missing from the shared registry, which the server typecheck refuses, and the admin Links switch could never be saved because the Zod contract had no key for it. Both are in now. Migrations moved to the end of the list and the column add uses the pragma guard rather than a caught duplicate-column error. The message-required string keeps its old wording for a request without a file part, so a client from before this route took images sees what it always saw. |
||
|
Maurice
|
6a3d4b1281 |
fix(budget): stop receipts deleting files, and share the upload path
Attaching a receipt no longer lets the budget domain delete one. Trashing the file was reachable from the REST route, the MCP tool and the plugin RPC, none of which check file_delete, and a receipt id is any file on the trip, so anyone who could edit an expense could trash a document they were not allowed to touch. A concurrent edit could do it by accident: the client sends the full set of receipt ids from a snapshot taken when the form opened, so saving an expense someone else had just attached a file to moved that file to the trash. Removing a receipt now removes the link and nothing else. The link row is treated as shared, because it is. One row can tie a file to a place and to an expense at once, so the sync clears only the receipt half and leaves the rest, the foreign key is SET NULL rather than CASCADE, and a receipt already in the trash keeps its link so restoring it comes back attached. The upload and its rollback moved into one module both shells call. It was copied into six places, and all six rolled back with the permanent-delete route, which only accepts a file that is already in the trash and therefore answered 404 every time: a failed save left every uploaded file on the trip, attached to the expense, and the next attempt uploaded another copy. It now trashes first, keeps the pending files for the retry, and says so when a file could not be removed instead of swallowing it. Escape in the receipt viewer no longer closes the expense form behind it, the download fallback uses a real accent class rather than a utility that does not exist, and the upload indicator is actually switched on. Tests: the receipt link behaviour on both service paths, the four new branches in the files service, the upload module, and the viewer. |
||
|
dersimoezdag
|
06ecc5135c | feat(budget): attach receipts and invoices to expenses | ||
|
Maurice
|
f5d6af9c77 |
fix(planner): steady satellite pill, responsive places rail, day-scoped add
The satellite toggle sat on an offset that included --day-panel-h, so it hopped every time the day panel was collapsed or expanded. On the desktop map that panel is a centred card between the sidebars and never reaches the pill at the left edge, so the lift only applies on a phone now. In the places rail the two add buttons split the width evenly once a day is open, and every button drops to its icon when the rail is dragged narrow. The filter tabs span the rail and keep their own text widths. The count is a badge across the rail; the search field got the outline the controls around it use. An empty day offers a button that opens the place form pointed at that day instead of only stating that nothing is planned. The day is cleared again when the form is opened to edit, which it was not before. The trip tab bar no longer carries a native title repeating its own label; the full name moved to aria-label for the tabs whose label is abbreviated. Three maps tests drove the index switch through app_settings, which no longer holds it, and now move TREK_PLACES_ENABLED instead. |
||
|
Maurice
|
4a88dbcbcf |
fix(places): say where a result came from, and stop asking questions in the form
Six changes to the place picker and the card behind it, all of them about a panel saying less and meaning more. The TREK place index has no switch in the admin panel any more. It decides whether a search leaves the instance at all, which is a property of the deployment rather than a taste: an operator pins TREK_PLACES_ENABLED=false in their compose file, and it cannot be turned off from a browser by whoever holds an admin account that day. The switch never shipped, so nothing to migrate. The standing "Using OpenStreetMap" notice above the search box is gone. It was a sentence about configuration in the middle of a form about a place, and it answered a question nobody asked while leaving the real one open. Each result now carries a small mark instead: TREK, OpenStreetMap or Google. It sits on the row rather than above the list, because a list can be two indexes interleaved and a heading could only name one of them. The saved-places filters open across the full width of the row. Two of them sit side by side, only one can be open at a time, and list names were being cut at about ten characters for no reason. Three empty states use the mascot the rest of TREK uses. The place details panel no longer tells the reader to go and ask an administrator for a Google key, the saved-places list and the road trip rail no longer explain themselves in two lines of grey text. That needed one new mood, `sad`: `sleepy` reads as falling asleep, which is a different thing from finding nothing. The Kind of stop field is out of the place form. It is a road trip concept, and the road trip view already sets it from the stop's own number, where the choice is next to what it changes. |
||
|
Maurice
|
2d7889c237 |
fix(memories): give the photo picker a chronological order it can rely on
The picker got its photos back in whatever order the provider happened to return them. It groups by day and appends pages lazily, so an unordered page lands under the wrong heading and pushes photos out of the fold the reader is looking at. Immich now asks for order: desc on both the search and the album path. An older server that does not know the property drops it silently rather than failing, so each page is sorted again here; the album paths drain every page before sorting and are covered outright. getAssetInfo reports mediaType, the same mapping the listing already used, so the detail route and the picker agree on what an asset is. Synology gets no sort parameter upstream on either path. Search.Search documents none, and _fetchSynologyJson maps every app code except 106/107/119 onto a 400, so a parameter one DSM build rejects would take listing down entirely for that user. Both paths read every page anyway, so ordering the mapped result costs nothing and cannot fail. No media type for Synology yet, deliberately. streamSynologyAsset serves every asset as a JPEG out of SYNO.Foto.Thumbnail, original included; there is no video byte path. Labelling an asset a video would make the lightbox mount a player on a still image, which is worse than the missing badge. The badge, the byte path and the persisted media_type belong together in their own change. Five album cases in the Immich integration suite pinned the old arrival order. Where the position was incidental they now look the asset up by id; where the order is the point they state the chronological one. |
||
|
Maurice
|
b2d9b25bb6 |
fix(roadtrip): say which filter emptied the list, and stop typing a limit racing itself
Four small things, and one that was not this branch's fault but is now its neighbour. The driving limits saved on every keystroke. Typing "180" sent three settings writes carrying 1, 18 and 180, unordered and concurrent over HTTP/2, so whichever the server committed last won: the number that decides every over-budget warning could quietly end up a tenth of what was typed, and only show it after the next reload. Typed locally now, committed on blur or Enter, and a value that did not actually change writes nothing. The empty-result message always blamed the name box. Four controls narrow that list and only one of them is the name, so picking a section with no hits produced `Nothing on the way matches ""` — empty quotes naming a filter the reader never set. The count line above it was gated the same way, so the section case lost its "x of y" as well. Both follow whatever actually narrowed the list. The check-out dropdown printed a bare ISO date, the only place in the planner that did; it goes through the same helper as the rail beside it. Switching an addon off left open MCP sessions holding its write tools. A `when:` gate runs once per session, at attach time, so the tools stay registered and callable while the REST half answers 404 for the same user in the same moment — and the list that decides whether to tear those sessions down had drifted: airtrail and collections gate tools and were missing from it, which this addon would have inherited. The list now sits beside ADDON_IDS and a parity test reads the gates out of the source and holds it there. Read out of the source rather than out of a runtime registry on purpose: a runtime set only holds the gates whose modules the caller happened to import, so it would pass in a suite that imports none — which is the shape of test that hid this in the first place. RoadtripLimitsCard gets the test it never had, including the one case that matters: three keystrokes are not three writes. |
||
|
Maurice
|
44d52ab215 |
fix(roadtrip): stop one gesture writing twice, and one search running too early
Five things, all of them a click or a drag doing something the traveller did not ask for. The GL via handle committed a move on every pointerup. Any button started the drag and there was no movement threshold, so a plain click wrote the via to wherever inside the 17px handle the pointer happened to be — at a low zoom that is kilometres, and the write re-routes the whole trip. A right-click ran the drag AND the delete, so one gesture sent two writes; on the platforms where contextmenu comes first, the move landed on an id that no longer existed and reported a failure for a deletion that had worked. Leaflet gets this right for free from `dragend`, which is why the two renderers behaved differently for the same gesture. Primary button only now, with a threshold, and pointercancel puts the pin back instead of committing — the browser fires it when the captured element is torn out of the DOM, which is exactly what a delete does. With the alternatives picker open, one click on the route fired both handlers. Layer registrations are independent in MapLibre, and every alternative starts and ends at the same two stops — when the leg already carries vias the current road is itself one of the offers, so the overlap is the whole leg. The click dropped a via AND chose a different road: two writes and two trip reloads for a gesture made once. The corridor search could be started before the day had routed. The corridor is then built from the straight line between the stops rather than the roads driven, and the routing answer landing a second later changes the line, which clears the search mid-flight and drops every result — no error, no partial result, just the idle empty state again. Routing runs one day at a time about a second apart, so the window is wide open on a long trip. Leaving road trip mode left the alternatives drawn on the map. The switch is in the sidebar and reachable while the bar is open, and the overlay depends only on the picker, so pale blue routes with drive-time pills stayed on an ordinary planner map with no road trip UI left to dismiss them from. Clearing a leg's vias swallowed its failure and closed the picker anyway. Every neighbouring write in that hook reports one. The leg still carried its via and still routed the old way, so the traveller believed they had undone the detour. Walking and cycling legs were counted as driving. A day may legitimately mix modes — splitIntoRuns exists for that — and a two hour hike was reported as "over the longest drive allowed", its minutes went into the day's driving time and its kilometres onto the tank, where a ferry crossing could trip a range warning outright. A leg with no mode still counts, because every leg was a drive before the field existed. The road-trip domain also says out loud that it is online-only, which the repo asks for rather than leaving it to be discovered. A via anchors by POSITION, so a queued write replayed after somebody else moved a stop would re-pin the drive onto a leg nobody chose, silently and hours later; the offline story needs the anchor to be an assignment id first. Until then the surfaces disable the gesture instead of accepting one and dropping it. Six theme-lint markers move onto the line they exempt. The linter suppresses per line, so a marker in the comment block above suppressed nothing and the six road-signage colours the authors documented as intentional were counted anyway. |
||
|
Maurice
|
65be8db122 |
test(roadtrip): cover the surface the domain shipped without
The domain arrived with 557 lines, a service test, and nothing else. No controller test, no e2e, and no MCP test — so the guard chain, the trip scoping on every route, the cross-trip track check and the day_edit parity were all unasserted, and the whole domain sat in the 80 catch-all where it could shed twenty points against the headroom of the domains beside it. The e2e is the one that earns its place. `@RequireAddon` is metadata and does nothing on its own, and AddonGuard is not global, so the ordering the controller's own comment calls load-bearing is exactly the kind of thing a later change removes without noticing — it had already happened once. Deleting the guard now turns three cases red, which I checked by deleting it. The MCP tools had never executed at all: the shared harness seeds the addon disabled, so `when: roadtripAddonOn` kept all five from attaching. They now run against the same checks the REST routes make, including the demo account and a member without day_edit, because the repo requires the two surfaces to move together. Two client modules that had no test get one: the overlay builder, where two decisions live that are not cosmetic — which offered road is drawn as the one you are on, and that a label hangs where its own route is unlike every other, rather than at a midpoint that can fall on a stretch two routes share — and the service marker, where the thing worth pinning is that an ordinary place gets nothing back, and that the anchor arithmetic includes the border. The domain carries its own coverage floor now instead of hiding in the catch-all. Pinned under the measured figure on purpose; the exact ratchet gets regenerated with the repo's own script after a full run. Along the way, roadtrip_vias and roadtrip_day_tracks join the reset list every other domain's tables are on. Without that a via written by one case was still there for the next one, which is how the first version of the MCP suite passed an assertion it should have failed. |
||
|
Maurice
|
41e256bf0f |
feat(roadtrip): answer the corridor search from the place index
Search along the route went to Overpass and only to Overpass, on the one path where that hurts most: one search fans out over sixteen boxes, and each of those races four public mirrors. The index answers the map's explore pills in milliseconds where those mirrors take seconds, and the corridor was the reason the index exists. Two independent things kept it out. The corridor sends its categories as a comma-separated list, and the index branch looked the whole string up as one key, so it missed every time. And the four kinds a drive needs, fuel, charging, rest areas and campsites, had no Overture terms mapped at all. They do now: gas_station and fueling_station, ev_charging_station, rest_stop, and campground with rv_park. The branch is list-aware the way searchOverpassPois already was, and it labels each hit with the category that produced it rather than with the list that was asked for, because the client colours and groups its markers by that field and "fuel,charging" is not a category. It answers all-or-nothing: a category the index has no terms for sends the whole query to Overpass, since answering the half it knows would silently drop the rest while the panel still reported a finished search. The caller's limit is passed through instead of a hardcoded 50, so a mixed search gets the same per-category budget the Overpass path spends. The other outbound path of this addon changes with it. Importing a shared Google route geocoded its waypoints by calling searchNominatim directly, which walked past geocodeQuery and its index lookup. Through geocodeQuery an index hit costs no throttle slot at all, and what the index does not know still falls through on the background lane. A place answered from the index also carries its chain and that chain's Wikidata item, so a branch gets its logo on the pin here exactly as it does on the Overpass path. Sockets stay an OSM field: a charging station answered from the index reports "not stated" rather than claiming it offers nothing. |
||
|
Maurice
|
1e1dd9b814 |
fix(roadtrip): keep the shaping a traveller did, through every path that moves a stop
A via records which stop it follows by POSITION, so anything that renumbers a day's stops moves the ground under it. The road-trip rail corrects for that; almost nothing else did. reanchor() never renumbered `sequence`. It is allocated per leg and starts at 0 in each, and re-anchoring MERGES two legs whenever the stop between them goes away — so leg A's 0,1 ended up beside leg B's 0,1, and everything that draws the route orders by sequence. The drive ran A0, B0, A1, B1: forward, back, and forward again. Persisted, surviving a reload, and unrepairable except by deleting the vias. The old anchor is read before the updates and used as the primary sort key, so the vias of the earlier leg stay ahead of the ones that merged into it. Reordering the only two stops of a day deleted every via on it. A reorder is modelled as remove-then-insert, and the removal half refuses to treat a two-stop day as still having a drive — right when a stop really goes away, catastrophic when nothing was removed. Two stops is exactly the shape "follow this track" produces, up to nine vias on that one leg, gone to a single drag with no prompt and no undo. Removing a stop, reordering within a day, and assigning a place mid-day never re-anchored at all, though the helpers exist and three other paths use them. The detour then sat on a leg the traveller never chose, or on a leg that no longer existed and vanished — until a later stop brought it back bending a road nobody asked for. Reordering hands a whole new ordering rather than one move, so the anchors there follow the stop they were pinned behind instead of arithmetic on the index, which is correct for any permutation. Duplicating a trip dropped all of it: `stop_type` was missing from the place insert, and neither via nor day-track table was copied. The duplicate looked complete and quietly drove somewhere else. A failed read of the via list emptied it. That read runs after every write and feeds the routing key, so a 502, a dropped connection or a tab going offline re-routed the whole trip along the roads the traveller had steered away from, with nothing said and nothing retried — indistinguishable from having deleted them. Only a 404 or 403 empties now; anything else keeps the last known list and says it may be stale. |
||
|
Maurice
|
676c82a308 |
feat(roadtrip): remember which track a day follows
The vias already made the day follow the road; nothing said which road. After a reload the badge could only say "shaped by hand", and re-fitting after the stops changed meant finding the track again by eye. One row per day, written in the same transaction as the chain it describes: a day claiming to follow a road whose vias never landed would be worse than a day claiming nothing. Three states rather than two, which is why the field is an object and not an id — absent leaves whatever the day followed alone, null says it follows nothing, an object records the road it now takes. A bare nullable id could not tell "do not touch this" apart from "forget it", and a hand-dragged via on the same day must not wipe the label. The foreign key is the point: delete the imported track and the label cascades with it, so no day is left claiming to follow a line nobody can see. The vias stay, because they are the drive. Both write paths check that the place is a track of this trip before it becomes a label — permission alone would let another trip's place id, or an ordinary place, become a name that can never be drawn. Also clears three reliability findings the scanner raised on this branch: two default sorts given an explicit comparator, and a trailing-slash regex the scanner is right to call backtracking, walked instead. |
||
|
Maurice
|
6fca238440 |
feat(places): import the stops of a shared Google Maps route
Pasting a /maps/dir/ link into the list-import box answered "could not extract list ID", which is the whole of the complaint: people share a drive far more often than they share a list, and it is the same gesture — somebody pressed Share in Google Maps. Which screen they were on is the URL's business, so the box takes both and the controller decides. No API key and no call to Google for the link itself: the stops are in the URL. Three shapes arrive — the path form with its data blob, the documented ?api=1&origin= form, and a short link that is one of those after a redirect — and a stop the link spells out in coordinates needs no geocoder at all. One that is only a name is geocoded, keeping the name from the link rather than the one the geocoder answers with: somebody who typed a nickname into Google should not find a street address on their trip. A name nobody can place is left out and counted rather than failing the import, because a route of six stops with five findable is five stops more than the traveller had. Coordinates are read as 1d/2d, longitude before latitude, which is the reverse of a place link and the one way to put Berlin in Somalia. A blob that does not line up with the stops is ignored entirely: half a link read confidently is worse than one read as names. |
||
|
Maurice
|
061259b3d9 |
feat(maps): pass through what OSM knows about a charging station
The corridor query has always ended in `out center tags`, and the projection has always kept six keys out of the whole tag set. Everything an electric car needs to know was in the answer and went in the bin: which plug families the station has, how many of each, at what power, how many vehicles fit, and whether it charges. Reading them costs no extra request, no key and no second query. The filters treat "not stated" as its own answer, which is the only honest way to build them: OSM states a socket type on roughly a third of charging stations and a power on fewer still, so a power filter keeps every station that says nothing rather than reading silence as too slow. The plug dropdown offers only the families this search actually turned up, because CHAdeMO in a list for a corridor with three Type 2 posts on it is a filter that can only return nothing. Socket names stay as they are printed on the plug. "Type 2" is not a string anyone translates, and the lowercase tag key is not what is written on the charger. The tool description follows, as parity requires, including the coverage caveat — a model that reads a missing power as "no fast charging here" would be wrong about most of the map. |
||
|
Maurice
|
67163e7224 |
feat(roadtrip): lay a whole chain of via points in one write
The single-via route is right for a detour dragged by hand and wrong for anything that derives its anchors from a line. Pinning a day onto a recorded track or a signed scenic road means a couple of dozen points, and one request each re-routes the entire trip once per point, spaced by the routing host's own rate limit — twenty anchors would spend half a minute drawing routes nobody asked to see. replace_legs names the legs to clear rather than taking a flag for the day, and that is the whole difference: a traveller who bent two legs by hand and then adopts a scenic road for a third has not asked to lose the two. The tools follow in the same change, as parity requires. Undoing a detour picks this up too, where the vias of one leg were deleted one request at a time. |
||
|
Maurice
|
9a0a6f8c3b |
fix(settings): the routing endpoint belongs to the operator
routing_base_url arrived on this branch and was assigned to neither managed set, which MANAGED-KEYS-001 exists to catch. It is locked, alongside the other infrastructure endpoints: the host it names is folded into the CSP once at boot (routingCspOrigins), so a customer who repoints it lands in a policy that does not know their router and the browser blocks the requests with nothing to catch. MANAGED-KEYS-005 pins the list verbatim and is updated with it. |
||
|
Maurice
|
e11ae6f056 |
feat(roadtrip): shape the drive — vias, alternatives and stops along the way
The road-trip addon's second half: the parts that let a planned drive be argued with rather than only read. Reshaping. A via records which stop it follows by position, and that position is resolved fresh every time the day is routed — so inserting, reordering or removing a stop moved the ground under every via after it, and the drive silently snapped back to the road it had been steered away from while the handle still sat on the map where it was left. The correction is computed against the day as it stands and written with the same change, in one transaction: a half-applied re-anchoring mixes two numbering schemes in one day. The one judgement that needs geometry — which half of a split leg a via belongs to when a stop lands in the middle of it — is measured on the road actually driven, so a fuel stop added to a bent leg keeps the bend on the side it belongs to. Alternatives. OSRM answers most long legs with exactly one route, which read as "there is no other way" when a perfectly good slower road existed. When it offers nothing, the same drive is asked for again without the motorway, and failing that without the tolls — one question at a time, stopping as soon as one lands. The offer says what it is rather than how much slower. Stops along the way. Everything the corridor search can find is a pause, not a destination: fuel, charging, rest areas, campsites, food and sights all sit inside the leg they were found on, carry their own colour and icon, and are left out of every stop count. That colour is defined once and read by the rail, the corridor list, the map pin and the picker — and it replaced the chains' logos, which turned a corridor full of petrol stations into a row of advertisements and left the brands with no logo on file looking like something else entirely. How long a stop takes was readable in the rail and writable nowhere; new places were given an invented hour that nobody had entered. It is now set from the rail, cleared as a zero because the update statement folds a null into "leave it alone", and new places start with nothing. Both columns are rebuilt on one type scale, anchored to the day plan's own sizes so switching tabs does not change the size of the text beside it. The rail reads as trip totals, day cards and a chain of stops with the drives between them; the corridor column as what to look for, how the search is getting on, and what it found. Six category pills over three lines became one dropdown, which is the space the results wanted. Also: the offered routes are framed on the map when the picker opens (`fitKey` carries no coordinates and each renderer reads it as "the selected day"), road trip mode does not cluster at all so the whole drive stays readable zoomed out, and the drive-time labels finally render in the app's own typeface instead of Leaflet's Helvetica. All of it in both renderers. |
||
|
Maurice
|
1db55f734c |
fix(maps): wait longer than the query we ask Overpass to run
The query carries `[timeout:20]`, so the mirror is allowed twenty seconds of work on it — and the fetch around it was aborted after twelve. A mirror under load that would have answered at fifteen never got the chance, and the caller saw a failed area. That is what makes a corridor search along a long drive report half its stretches as unsearchable: the stretches were being searched, we just hung up. Both numbers now come from one constant, the client budget is the query's own plus room to hand the answer back, and a test holds the relationship rather than the two literals. |
||
|
Maurice
|
b339ef3f04 |
fix(days): keep a place's stop type on both assignment loaders
Three read paths built the same nested place object by hand, and two of them left `stop_type` out of it while their SQL was already selecting the column. The effect was visible: a petrol station added along a route drew correctly for a moment from the optimistic write, then the server's answer replaced it with a place that had no kind, and the road-trip rail redrew it as an ordinary numbered destination. `getAssignmentWithPlace` now goes through `formatAssignmentWithPlace` like the list path already did, which removes the third copy rather than adding the missing field to it. The two queries in the days service gain the column, and its hand-built shape gains the field it cannot yet be spared. |
||
|
Maurice
|
d6955f20a6 |
test(roadtrip): cover the routing, corridor and panel behaviour
The addon shipped with only its two pure modules under test, which left the parts that actually talk to the network — and the panel a user reads the answer from — resting on nothing. Covers the routing hook (one request per travel-mode run, day default over trip fallback, retry then give up, no re-fetch on a rename, abort on leave), the corridor search (one query per box carrying every kind, the perpendicular filter, dedupe, the retry pass before a stretch counts as unsearched), the corridor state (roads driven over the line between stops, day follow-along) and both panels. Two findings from writing them, fixed here: - A dead straight leg is reduced to its two ends by the simplifier, and tiling walks point to point — so a 250 km motorway stretch produced a box at each end and nothing in between, while the search still reported itself complete. Steps longer than half a box are now split before tiling. - projectOnSegment guarded a degenerate segment with `lenSq === 0`, which two ends that came through a chain of floating point arithmetic never hit. Also splits the anchor resolution out of computeSchedule, which was three levels of nesting for one question, and sorts the POI cache key with a comparator. |
||
|
Maurice
|
6aa7884874 |
perf(maps): search a corridor with one query per box, not one per category
The road trip corridor asks for fuel, charging, rest areas and campsites over a dozen boxes, and asking per category was four times the requests for the same answer — slow, and four times the chance a shared Overpass mirror times out and reports the stretch as unsearched. `category` now takes a comma-separated list. Each OSM selector belongs to exactly one category, so a hit is still labelled with the kind it answered, and the result cap is shared out per category so one dense kind can't crowd the rest. The MCP tool takes an array for the same reason. Also puts the POI, plugin and route via-point pins on the map's render clock, the same fix the planned-place pins already had: a library marker repositions on every pointer sample while the canvas draws once a frame, so the suggestions swam during a drag and snapped back on release. |
||
|
Maurice
|
37179cb608 |
feat(maps): show a chain's own logo on its map pin
A corridor full of petrol stations was a row of identical coloured dots, and the one thing that tells them apart is the brand. OSM carries brand:wikidata on most of them — 88% of the fuel stations in a Berlin box — Wikidata carries the logo as property P154, and Commons serves it. The bytes are proxied and cached rather than linked: one self-hosted instance asking Wikimedia for a handful of logos is a very different egress profile from every visitor's browser announcing which petrol stations they are looking at. The cache is in memory because a GET must not write to the database, and there are only so many fuel brands; a brand with no logo is remembered too, or every pan would ask again. A logo-less or unreachable brand answers 204 and the pin keeps its category icon, so nothing depends on Wikidata being reachable. Both renderers show it, since both read the same category table. |
||
|
Maurice
|
7cdd61e7fb |
fix(maps): say which source answered, and stop the stubs driving the index
Two halves of one mistake, both found by the suite. Letting each side of the merged search catch its own failure meant the index could contribute nothing while the answer still called itself "trek-places+openstreetmap". That label is not decoration: the search log writes it into the corpus a candidate index gets scored against later, so a list that is entirely OpenStreetMap must not be recorded as though the index had a hand in it. The source now names what actually contributed. And maps.service.test.ts drove the index for real. Its fetch stubs answer with json() and no text(), which is not what the index client reads, so the branch was entered and then failed on the stub — "uses Nominatim when user has no API key" was really testing that a stub is incomplete. With the new circuit breaker those failures also accumulated, and the breaker is process state, so it leaked into whatever file ran next. trekPlacesSearch is stubbed there now, beside the nearby stub that was already there for the same reason. The index paths keep their own files. |
||
|
Maurice
|
ed5769fc89 |
fix(maps): name the index as the source, and stop it being asked twice
Attribution first, because this branch argues the point itself: the card names the sources with the comment that naming them is a licence obligation rather than decoration, and the copy beside it promises that every field says where it came from. The POI path then stamped Overture rows as OpenStreetMap. Overture is not OpenStreetMap — it carries OSM among other sources under other licences — so that is a wrong attribution rather than a rounded one. The wire contract keeps `source` an open string and nothing on the client switches on it, so saying `trek-places` costs nothing. The MCP tool description no longer calls itself an OpenStreetMap tool either, and says which source answered. Adding one place cost two round trips to the index. The details lookup fetches the place and its answer carries the description; toPlaceRecord dropped that field, so the enrichment fetched the same place again a moment later to read it. It is carried through now and read from what the caller already has, with the second lookup left as the fallback for when there is nothing to read. That description's source URL becomes an href on the client and was taken on `typeof === 'string'` alone. It now goes through the same allow-list a place's website goes through — the file already does this for menu_url, with the comment explaining why — so anything but http(s) loses the link and keeps the text. The instance token was hashed from raw APP_URL, which the shipped compose file leaves commented out. Every default install therefore sent the same token, and a token every caller shares is not a caller: one instance running a large import would rate-limit all the others, who would fall back to Nominatim with nothing to point at. getAppUrl() falls through to ALLOWED_ORIGINS and then to the port, so unconfigured instances still differ. Two client-side leaks. A pick made out of the offline cache was recorded into the shadow corpus, where it moved the two figures the corpus exists to measure — and offline is a setting, so the network is usually reachable and the row landed. And the prefetch never re-checked the session after its request came back: a logout in that window repoints the handle at the anonymous database, so one person's trip area was written where the next person's offline search reads. The cache path also ignored the abort signal, so an answer for a keystroke two keystrokes old could overwrite a newer suggestion list. It rejects the way both surfaces already know to swallow. Left alone, and said in a comment rather than hidden: the index cannot localise. The Overpass path picks name:<lang> and falls back to int_name; the service has no language parameter at all, so a German reader exploring Tokyo gets the Japanese primary names on this path. |
||
|
Maurice
|
b0aa7f8d95 |
fix(maps): stop asking an index that is not answering, and untie the place cache
Three things an install feels rather than reads. A service that cannot be reached cost the full timeout on every call. Each call site falls back to the old path, but pays 3.5 s first — so an instance behind a firewall that drops rather than refuses, or one that simply has no route to the service, pays it on every keystroke of autocomplete and on all three queries a booking import runs per venue. Ten venues is over a hundred seconds of waiting for an answer that was never coming. A process-wide breaker now fails instantly after four consecutive failures and tries again a minute later, so an unreachable index costs one timeout instead of one per request. A 404 does not count against it, because "no such place" is an answer, and neither does an oversized body, because the service replied. The offline place cache hung off the map-tile switch. That setting is about tiles — its own text says "off keeps the cache to trip data + documents only" — and it gets turned off for space, tens of megabytes of it. A trip's places are about one. Somebody who turned tiles off therefore got an empty offline search with no explanation, and "prepare for offline" reported success having stored no place at all. The two run independently now; the tile progress phase stays gated on the tile setting, so a run without tiles still reports no tile phase. Tests for the merged search path, which had none: the wiring around mergeSearchResults was uncovered, so which list goes in first and what `source` says were both free to change. Neither is cosmetic — index-first is the whole point of the feature, and the search log writes `source` into the corpus a candidate index gets scored against later. Two of the eight cases pin the fix from the previous commit: an index failure keeps the OpenStreetMap answer, and neither source is asked twice. place-shadow lands on its own coverage entry rather than the 80 catch-all, where a new domain could shed twenty points unnoticed. Pinned under its measured figure on purpose; the exact ratchet gets regenerated with the repo's own script after a full run. |
||
|
Maurice
|
48f0f29273 |
feat(admin): let an operator switch the place index off
trek_places_enabled was read by six call paths — search, autocomplete, the POI pills, booking-import geocoding, the offline area and details resolution — and written by nothing. No admin route, no MCP tool, no switch anywhere in the UI, and the key is not in the settings allow-lists either, so the only way to set it was an INSERT against app_settings by hand on the server. That matters more than the four switches beside it, which trade away quota. This one decides whether every search and every keystroke in the place box leaves the instance at all. The flag reads fail-open, so an install that upgrades without visiting the admin panel starts sending them, which is the right default and exactly why the operator needs somewhere to say no. Adds the pair symmetrically to place-shadow from the same branch: getTrekPlaces /updateTrekPlaces on AddonsService, GET/PUT /api/admin/trek-places with an audit row, and a real switch on the card. The read stays fail-open so it keeps agreeing with MapsService.trekPlacesEnabled(), and a test pins that agreement across every stored value — if those two ever diverge the panel shows "off" while the queries keep leaving, which is worse than either default. The card said this itself: `available` was a display-only prop whose comment read "False until the client is wired to the service; the card then says so instead of offering a switch that would do nothing." It is wired now, so the prop is a switch. Its two badge strings had been shipped to all 23 locales and rendered nowhere; they make way for the switch label and a line naming what answers while the index is off. |
||
|
Maurice
|
5aa36aaf3d |
fix(maps): stop the index costing a second search, a duplicate and a lost cache
Six things the merged search and the offline cache got wrong. An index failure took the OpenStreetMap answer down with it. Only the OSM half of the Promise.all had a catch, so a rejection on the index side discarded ten results that had already arrived and sent the same query to Nominatim a second time, behind its 1.1 s process-wide throttle. The index refusing a query is ordinary traffic rather than an outage — a common single word without coordinates is turned down upstream as too expensive — so this fired in normal use. Each side now catches its own failure, and the keyless fallback reuses the answer OpenStreetMap already gave instead of asking again for a list that cannot have changed. Dedup never fired for a non-Latin name. namesOverlap splits on [^a-z0-9], so 長谷寺, Кремль and مسجد الشيخ زايد all tokenise to nothing and the function returned false — the same place came back once from each source, one row under the other, and picking either gave it a different id. That is the corpus this whole feature was measured on. Two names with no Latin words are now compared strictly, folded through NFKC so the width variants the sources disagree on still match; sharing a character is deliberately not enough, because deduping 東京タワー against 東京タワー駅前郵便局 would swallow a real result. expand=1 answered nothing for an index place while expand=0 answered in full. The expanded lookup degrades OSM ids to the plain one and had no branch for the new family, so the richer request was the poorer one, over REST and MCP alike. The bias circle could exceed Google's 50 km ceiling. A trip spread over more than that produced a radius Google rejects outright, turning a search into an error toast. Clamped on both sides — the client because it draws the box, the server because the radius arrives over the wire. The offline cache was rebuilt on every sync and never deleted. syncTrip wrote its meta row with put(), which replaced the whole record and dropped the fingerprint saying the cached area was current, so every login, reconnect and manual sync re-downloaded megabytes that had not changed. And clearTripData never touched areaPlaces, so a trip switched off for offline use kept answering offline searches and its rows stayed for the life of the install. clearCachedPlaces, which claimed to do that job, was called from nowhere; its only test asserted with .every() on an empty table and passed on nothing. Picking an offline suggestion ended in an error toast. The details lookup had no cache path, so it failed and the callers fell back to searching for "name, address" — which the cache matches on the folded name alone, so it found nothing for a place that was sitting right there. A miss stays a miss. |
||
|
Maurice
|
273bac8917 |
fix(maps): keep index ids away from Google, and let the area download be big
Four things the index changed and nothing followed: `gers:` was missing from NON_GOOGLE_PLACE_ID, so isGooglePlaceId said true for every id the index hands out. Five call sites gate on that function to keep unresolvable ids away from Google, which answers them with a billable 400 INVALID_ARGUMENT: photo refs, the editorial summary, the place-photo route, the expanded details lookup and the enrichment photo pass. Since the index answers first for search and autocomplete, a GERS id is what an ordinary new place now carries, so this was the normal case rather than an edge one — three billed lookups per added place, none of which could ever return anything. The area download shared the search path's megabyte cap and its 3.5 s timeout. Both are right for a keystroke and wrong for the offline prefetch, which asks for 3000 rows at once: a city-sized answer sits on that megabyte, readCapped threw, and the caller could only report "index unavailable" — the trip then went offline with an empty place cache and nothing said so. The cap now follows the row count the caller asked for, with a floor, and the bulk call gets a budget that fits a bulk download. It is still capped, so a broken upstream cannot hand us an endless body. searchPlaces returned before the Google branch as soon as the index or OpenStreetMap had anything, and both set google_place_id to null. That is right for a search and wrong for the one caller that wants an identity rather than an answer: list-import enrichment (#886) exists to attach a google_place_id to a bare imported pin, and pickEnrichmentMatch discards every candidate without one. So the import silently stayed unenriched on an instance that pays for a key. That caller now asks for the Google identity explicitly. Nothing changes for an instance without a key — enrichment could never resolve anything there, before or after. Tests cover the three functions this branch had left untested, which is what put the maps ratchet under its functions threshold: the autocomplete index path (a new file, MAPS-AUTO-001..007), the gers details branch when Overpass is down (MAPS-GERS-008), and the client's abort timeout — including that the signal exists at all, which nothing asserted before. |
||
|
Maurice
|
2b7af6267b |
test(server): cover what this branch added to the pinned domains
The coverage ratchet measures per domain, and this branch put new code into four domains pinned well above the floor without tests reaching it. addons (99/99/99): getPlaceShadow and updatePlaceShadow had none at all, and the parity the service comment claims with PlaceShadowService.enabled() is now asserted rather than asserted in prose. maps (93/86/97/96): geocodeQuery was invisible - its only consumer stubs it away - so the new suite drives the gate, an accepted hit, a hit with an unusable coordinate, an index failure falling through, and both ends of the Nominatim tail. It sits on the booking-import path, where it decides whether thirty sequential lookups leave the instance. admin (86/70/89/88) and place-enrichment (96/95/94/97): the place-shadow handlers and their audit entry, the getAppConfig read, and nearbyWouldMislead, whose lines ran incidentally while nothing asserted the result - the guard could have been inverted and the suite would have stayed green. |
||
|
Maurice
|
d613c91e16 |
fix(places): keep the chain out of the field that means "this place"
toPlaceRecord wrote the brand's Wikidata item into `wikidata`, and getPlaceDetails spreads the record over the OSM details, so for a chain branch picked from the index that value replaced the building's own tag - and nulled a real one when the place had no brand. resolveIdentity reads that field as the place's own identity, so the photo ladder returned the chain's Commons files as pictures of this branch and the description came back as the company's article without the aboutBrand flag. That is precisely the failure WIKI_IDENTITY_TAGS and readBrandIdentity were written to prevent, in their own words: "a chain's logo passed off as a photo of the restaurant would be a plain lie". The item now travels under brand:wikidata, the key OSM uses and readBrandIdentity already reads, and resolveIdentity picks it up from the payload for a place OSM does not know - so a branch still gets the chain's description, flagged as such, and never its logo. The client test also covers trekPlacesArea, the streaming half of readCapped including the size cap, the configured base URL and the nearby defaults, none of which any test reached. |
||
|
Maurice
|
0991fa538b |
fix(maps): stop pois() dropping opening hours and reporting a narrowing as none
The index-first branch hardcoded opening_hours: null while the payload it maps carries them, and search_pois advertises "opening hours wherever OSM carries them". It also capped the radius at 20km and then answered clamped: false, so a wide viewport came back narrowed and said it was not - the same field the Overpass path fills honestly. The three red MCP cases were the same code telling the truth from the other side: they stub Overpass one level below the facade, so pois() ran for real, and because trekPlacesEnabled() fails open on a database with no row, a unit test was sending live requests to places.liketrek.com from CI. That is what answered with 50 places instead of the stubbed one. The index client is now mocked in that suite, with the gate left open so the cases still run on the shipping configuration, and the index-first path gets cases of its own here and in a new maps.pois suite: field mapping, the empty and the failing index both dropping through to Overpass, and an outage under both providers still reaching the caller as an error rather than an empty list. maps.service.test.ts drove pois() with no stub at all and leaked the same way. |
||
|
Maurice
|
fb363f22c8 |
fix(maps): alternate between the index and OpenStreetMap instead of ranking them
Measured on 128 places out of a real trip to Japan, all saved through the old search. Index alone: 51.6 percent inside the top five. Index and OpenStreetMap alternating: 72.7 percent. Two cleverer orderings were tried first and both lost. A score threshold cannot separate the cases at all: at 0.75 it catches 19 of 62 misses and throws away 6 of 66 hits. Promoting results whose name matches what was typed is worse than it sounds, because "Hase Station" shares a word with "Hase-dera" while OpenStreetMap answers in the local language and returns the right temple under a name that shares nothing: that rule put seven weak index matches ahead of the correct answer, which landed at position eight. Alternating puts it at position two. So the merge does not rank. Each source keeps its own ordering and they take turns, index first. An exact business match still opens the list; a landmark Overture does not carry is second rather than eleventh. |
||
|
Maurice
|
3caafe0548 |
fix(maps): show OpenStreetMap alongside the index, not instead of it
Measured against 128 places out of a real trip to Japan, all saved through the old search: the index answered 51.6 percent inside its top five. For most of the rest it returned the shops AROUND the landmark rather than nothing, which is worse than nothing, because ten plausible wrong answers look like an answer. Overture Places is a dataset of businesses and is very good at those. It largely does not carry temples, bridges, riverside walks, viewpoints or observation decks, which is a fair share of what somebody planning a trip searches for. Two ways to detect "the index does not have this one" were measured and both failed. Its own score does not separate the cases: a 0.75 threshold catches 19 of 62 misses and throws away 6 of 66 hits. Name overlap does not either: 57 false positives, because "Hase Station" shares a word with "Hase-dera". So this does not classify. Explicit search asks both concurrently and merges, name matches first and the index ahead of OpenStreetMap within each group. Autocomplete is untouched, because Nominatim's policy names it as unacceptable use. Nominatim also gets the location bias it never had, without which "Hase-dera" returns the temple in Nara rather than the one in Kamakura the user is standing beside. Two booking-import cases still stubbed searchNominatim after geocoding moved to geocodeQuery, and stubbed it with the old array shape, which made "has coordinates" pass on an undefined lat. |
||
|
Maurice
|
bac85cb98a |
feat(places): opening hours from the index, with OSM still first
The index can now carry opening hours, from two sources: an OpenStreetMap layer the service keeps as a separate database file, and the schema.org data a place publishes on its own site, read in the same page fetch the description comes from. OSM stays the first choice where it has them. Measured across seven countries it covers 27.5 percent of gastronomy, and an OSM entry describes this exact object and gets corrected by people who walked past it, where a chain's website often carries one set of hours for every branch. The rest is what the operator publishes, which measured 8.3 percent on the same kind of place. Both go through the same expansion into weekday lines, so a card reading `opening_hours` gets one shape and not two. Five maps.service cases went red when search started answering from the index ahead of Google; they are about the shape of the Google request, so they now switch the index off first. |
||
|
Maurice
|
87a765b763 |
feat(offline): cache the trip's area so place search works with no network
An offline instance had the trip's own places and nothing else, so "find a pharmacy near the hotel" had nothing to answer from: every lookup went to a server. The index can hand over a bounding box in one request, so it does, once, next to the map tiles. A trip to Rostock is roughly a megabyte, refreshed only when the trip's area actually moves. Search and autocomplete fall back to it at the API layer, which is why all ten call sites got the offline path without any of them learning about it, and the answer says `source: 'offline-cache'` rather than pretending to be live. Country packages stay what they were: a SQLite file for anyone who would rather run their own copy of the service. A browser cannot query one without shipping a WASM SQLite, and Germany alone would not fit in IndexedDB, so that door stays where it belongs. /v1/packages lists them, because "you can leave" only means something if the door is visible. |
||
|
Maurice
|
715993feaf |
feat(places): descriptions from the place's own website
Overture has no descriptions, and the encyclopaedias only describe the places that have an article, which is a fraction of a percent. What Overture does have is the address of the page the description is on, for 43 percent of places, and those pages publish a summary in JSON-LD or og:description precisely so machines can read it. The API fetches each page once and keeps the summary; every instance reads it from there. TREK never opens a business's website itself, which would mean one request per instance per place against small servers. In the ladder it sits below the encyclopaedias and above Google: an article about this exact place beats the operator's own copy, but for a restaurant or a shop the operator's summary is the only one that exists. Credited by host and linked back, with no licence claimed. |
||
|
Maurice
|
b3d69aa760 |
feat(places): record which search result was picked, on this instance only
The corpus behind "is our own index good enough to replace Nominatim". When somebody searches and then picks a result, the client posts the query, the rank and the pick. Nothing else: no user, no trip, no session, and coordinates only to three decimals. Deliberately decoupled from the search endpoint. Correlating a response with a later pick would mean handing out a ticket on POST /api/maps/search and threading it through all fifteen call sites; the client already holds everything the row needs at the moment of the pick. Evaluation happens offline afterwards: export the corpus, run it against a candidate index, count how often the pick came back in the top five. That is why collection can start before such an index exists, which is the whole point, because the corpus needs weeks of real use and the index needs a server, and those two waits should not be serial. Off unless an admin switches it on, and it reads === 'true' rather than !== 'false'. The three older places switches fail open because a migration backfilled a row for installs already using them; nothing uses this one, so an instance that upgrades and never visits the admin panel logs nothing. Reading is admin only, retention is 180 days, and the switch state is on the unauthenticated app-config endpoint on purpose: whether an instance records what its users search for is something a visitor may know before logging in. |