Repository navigation
Polygon/drawing fixes: canonical z-order, click-to-select, draw UX (eo-gpt #111) - #14
Merged
Merged
Conversation
…w UX (issue #111) Layer ordering (items 1+2): the DB gave every new asset z_index = max+1 while the map client force-inserted rasters below all vectors, move_layer was broadcast-only, and snapshot restore re-applied the raster heuristic — so layer-manager order and render order disagreed until a reorder forcibly synced them. z_index is now canonical everywhere: create_asset slots rasters just below the lowest vector, move_layer persists, add broadcasts carry z_index, and the client inserts/restores by z instead of heuristics. Draw interactions: - First click did nothing (item 6): the adapter's pre-drawing minPixelDragDistance default is 1px, so any press jitter reclassified the click as an ignored drag. Raised to 8px (the while-drawing default). - Circle/rectangle/freehand accept click-move-or-drag (item 5). - Finishing a shape reverts to pan mode (item 4). - Mode transitions clear stale inline cursors from the hover systems; crosshair/pointer arbitration is class-based and synchronous (item 3). Selection (item 7): hover cards are gone (they pinned themselves at the hover start and, zoomed inside a large polygon, could never be dismissed). Clicking an asset now emphasizes its border (restored verbatim on deselect/empty-click); the default outfit focuses the panel row instead of peeking on hover. tests: new test_layer_order.py pins the server policy (NB: the pytest harness hang is pre-existing; logic verified standalone). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- maxTileCacheSize: 512 — the default viewport-sized cache re-fetched (and re-faded) tiles the moment you panned back over them; a fixed 512-tile cache keeps the session's working set hot. - cancelPendingTileRequestsWhileZooming: false — the default abandoned in-flight requests mid-gesture, so zooms ended on blank chunks that restarted from zero. Bandwidth is not our bottleneck; fill the frame. (The other loading-speed lever — 512px tiles — turned out to already be in place: MapTiler raster entries serve native 512 PNG; only the keyless OSM/Esri fallbacks are 256, and neither provider offers 512.) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Layer ordering
Root cause of the "ordering flips after reorder" and "polygons sometimes over tifs" reports: the DB assigned every new asset
z_index = max+1, while the map client force-inserted rasters below all vectors,move_layerwas broadcast-only (never persisted), and snapshot restore re-applied the raster heuristic — so layer-manager order and render order disagreed until a reorder forcibly synced them, and reloads silently undid explicit raster-above-vector arrangements.z_indexis now canonical end to end:create_assetslots rasters (geotiffs/tiles) just below the lowest vector; vectors stack on topmove_layerpersists (newmove_assetrenumber);reorder_assetsunchangedz_index; the client inserts by z (beforeIdForZ) and re-syncs registry order after moves/reordersDraw interactions
minPixelDragDistancedefaults to 1 px, so any press jitter reclassified the click as an ignored drag (while drawing, the threshold is 8 px — which is why only the first click died). Raised to 8.drawInteraction: 'click-move-or-drag'). Polygon/line stay click-per-vertex (terra-draw has no drag variant; freehand is the drag way to sketch a polygon).Selection (item 7)
Hover cards are gone (they pinned at the hover start point and, zoomed inside a large polygon, could never be dismissed). Clicking an asset emphasizes its border (original paint saved and restored verbatim on deselect/empty-click); the default outfit focuses the panel row on click instead of peeking on hover.
Perf follow-up
maxTileCacheSize: 512— panning back over visited areas renders from memorycancelPendingTileRequestsWhileZooming: false— zooms no longer end on blank chunks (accepted bandwidth tradeoff)Testing
New
tests/test_layer_order.pypins the server-side stacking policy. NB the pytest harness hang at lifespan is pre-existing (MCP-related) — the ordering/move/reorder logic was additionally verified with a standalone script against a temp DB (all assertions pass).🤖 Generated with Claude Code