mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-21 14:36:31 +00:00
Maurice
c0eb1c6e38
MapsSearchDto validates a locationBias and MapsService passes it through, but no caller ever sent one. That gap is the whole difference between the numbers in this PR and what the software does. Measured against a live instance over the 127 places of a real trip, searching each by name: without a hint 50.0% -> 54.8% top-5 with a hint 50.0% -> 73.0% top-5 (this PR reports 72.7%) mess/eval_merge.mjs sends lat/lng on every index call and a viewbox to Nominatim; the client sent neither. Without coordinates the index refuses common queries as too expensive and contributes to 41% of searches instead of 100%, so the merge degenerates to Nominatim alone. The hint has to be NARROW, which is the part that is easy to get wrong. Same corpus, same instance, varying only how the box is derived: no hint 54.8% top-5, 38.1% at rank 1 box around the whole trip 57.1% top-5, 17.5% at rank 1 box around the nearest few places 70.6% top-5, 34.9% at rank 1 A box spanning a round trip has its centre in open country between the cities. It points at nothing and costs more than half the rank-1 hits. useLocationBias therefore prefers the day being planned, falls back to the trip only while it still fits inside one region, and drops the hint past a 60km radius rather than sending a misleading one. This also replaces the two hand-rolled copies of the bounding box in the planner dialog and the phone sheet, which shared a defect: Number(null) is 0, so a place without coordinates entered the box as the Gulf of Guinea and stretched it across the planet.