47eb2615ec
- rate-limiting: correct BRouter limit to 300/hour (was 60); add Overpass rate-limit requirement (120/min per IP) - security-hardening: BROUTER_AUTH_TOKEN lives in secrets.app.env, not infra.env - account-management: email-change verification does not re-auth; existing session stays valid - planner-journal-handoff: full rewrite — documents the actual JWT callback architecture (edit-in-planner → POST /api/sessions → callback endpoint), token claims, notes round-trip via GPX <metadata><desc>, session lifecycle - route-drag-reshape: rewrite to describe permanent segment midpoint handles (not proximity hover ghost marker); click-to-insert + waypoint drag model - route-splitting: rewrite to match midpoint handle model; notes geometric midpoint placement (not cursor-snapped) - road-type-coloring: redirect to route-coloring (all requirements already covered there) - osm-tile-overlays: mark profile-aware auto-enable as not yet implemented (profileOverlayDefaults exported but not wired) - osm-poi-overlays: zoom threshold is 10 not 12; user override persistence marked as not yet implemented - shared-packages: add all 7 missing packages (map-core, fit, api, db, jobs, sentry-config, correct map description); document map vs map-core boundary Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
41 lines
2.2 KiB
Markdown
41 lines
2.2 KiB
Markdown
## Purpose
|
|
|
|
Segment midpoint handles on the route polyline that allow users to reshape the route by inserting new waypoints, then dragging them to a desired position.
|
|
|
|
## Implementation note
|
|
|
|
The shipped interaction uses **permanent segment midpoint handles** — one semi-transparent circle rendered at the geometric center of each route segment — rather than a proximity-based hover ghost marker. Handles are visible at zoom ≥ 12. Clicking a handle inserts a new waypoint at the midpoint position; the user then drags that waypoint (standard Leaflet marker drag) to reshape the route.
|
|
|
|
## Requirements
|
|
|
|
### Requirement: Segment midpoint handles
|
|
The Planner SHALL render a midpoint handle at the geometric center of each route segment.
|
|
|
|
#### Scenario: Handles visible at sufficient zoom
|
|
- **WHEN** the map zoom level is 12 or above and the route has two or more waypoints
|
|
- **THEN** a semi-transparent circle is rendered at the midpoint of each segment between consecutive waypoints
|
|
|
|
#### Scenario: Handles hidden at low zoom
|
|
- **WHEN** the map zoom level is below 12
|
|
- **THEN** midpoint handles are not rendered (the map is too far out for precise editing)
|
|
|
|
#### Scenario: Handles update on waypoint change
|
|
- **WHEN** a waypoint is added, moved, or removed
|
|
- **THEN** midpoint handles reposition to reflect the updated segment geometry
|
|
|
|
### Requirement: Insert waypoint by clicking a midpoint handle
|
|
Clicking a midpoint handle SHALL insert a new waypoint at that handle's position, splitting the segment in two.
|
|
|
|
#### Scenario: Click to insert
|
|
- **WHEN** a user clicks a midpoint handle
|
|
- **THEN** a new waypoint is inserted at the geometric midpoint of that segment
|
|
- **AND** the route recomputes through the new waypoint, splitting the segment into two
|
|
|
|
#### Scenario: Inserted waypoint is immediately draggable
|
|
- **WHEN** a new waypoint is inserted via a midpoint handle
|
|
- **THEN** the user can immediately drag the new waypoint to adjust the route shape
|
|
- **AND** the route recomputes continuously as the waypoint is dragged (standard waypoint drag behaviour)
|
|
|
|
#### Scenario: Insert syncs to other participants
|
|
- **WHEN** a user inserts a waypoint via a midpoint handle
|
|
- **THEN** all other participants see the new waypoint appear in the waypoint list and on the map via Yjs sync
|