mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-19 13:36:48 +00:00
Maurice
59b7c35e87
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.