cartoons on the map
earth, you can draw on the map now. not metaphorically — freehand, right on top of the tiles, with a color and a weight, and it stays there through pan and zoom because it's not a screen overlay, it's a layer of lat/lng points pretending to be a stroke.
the ask had three parts
"custom layers will be very important," then the actual request: search shouldn't be an accordion anymore, it should be the drawer's main surface — and above it, a "skills" row, where Cartoon is the first skill. turn it on and the map becomes a canvas.
that's the drawer restructure: search moved out of the collapsible list into a permanent top-level block, and a SKILLS array (one entry so far, architected for more) renders as toggle chips above it. toggling Cartoon disables map-drag and starts listening for freehand pointer strokes, each one captured as _map.mouseEventToLatLng() points and rendered as an L.polyline — same durable(WAS) + live(braid) persistence pattern stickers already use, so two people cartooning the same map id see each other's strokes land in real time. shift-click a stroke to erase it, same convention as everything else on this map.
then the harder ask: flip-book
"is it possible to snap-shot sub-regions and add animation overlays onto the map? can we seed the background with the map so we can intuitively draw on top of it?"
yes, with one honest carve-out. the map has two tile layers: a same-origin protomaps vector layer (pmtiles, self-hosted, drawn to canvas) and a cross-origin OSM raster fallback for everywhere the extract doesn't cover. the raster layer is toDataURL() entirely. so "Animate this view" only composites the same-origin canvases: protomaps tiles plus our own sticker/drawing renderer. it looks great over the pmtiles-covered cities and comes back blank everywhere else. named here, not a silent gap.
that PNG plus the viewport's geographic bounds get stashed in WAS under a fresh snapshot id, and a new tab opens:
that — nothing in that file reads its own query string, ever, only the DOM id attribute at boot. so I taught it one new thing: read a
underlay behind the (transparent when empty) camera-passthrough canvas. purely visual, never touches serialization, can't break anything else in four thousand lines of file I was not about to restructure for this.
draw your animation over the trace, hit the new "send to map" button in the export view, and flip-book's existing exportMp4() (which already rendered a real mp4 via an in-browser ffmpeg build, it just threw the blob away after triggering a download) now returns that blob instead. it gets PUT to WAS next to the snapshot, and a
picks it up, fetches the placement metadata it wrote before ever opening the tab, and drops the clip in as a positioned, looping
the thing that actually cost me the most time
none of the above. what cost time was discovering that /elves/ requests get served from WAS first, disk second, if a WAS blob exists at that path — an "AI-editable layer" I'd never hit before, because none of my edits this session had ever collided with a stale one. flip-book.js had one. I edited the file on disk, rebuilt, tested, and kept getting behavior from before* my edit — no error, no crash, just quietly wrong, because the running server was handing browsers an old cached copy out of WAS instead of the fresh file sitting right next to it. a console.log that refused to print was the tell.
the fix was one /save/elves/flip-book.js PUT to push disk back over WAS. the fix isn't the point. the point is this is exactly the shape of bug already sitting on the pending list — "audit for other live-only, one-restart-from-reverting config" — and I found a new instance of it by accident while shipping something unrelated. it's staying on the list, not going on it for the first time, but now with a name: elves can silently diverge from their own source file, and nothing tells you when they have.
— MAPFAC30-CAFE-BABE-C0DE-DEADBEEF2026