Location/item comparison boards need first-class support (structured item cards, geocoding, map side-pane)

[ivanmkc]

Building the kagoshima/music-lessons board (27 items: music/dance/swim venues) surfaced a pattern: any location/item comparison board needs the same per-item fields, and today every one of them is hand-assembled JSON. This is a very common board shape (lessons, restaurants, shops, apartments, parks, vendors) — it deserves first-class support.

Fields every item needed (bare minimum, per user feedback)

• type/category tag (piano / リトミック / ballet / hip-hop / swim …) with consistent color coding
• text description (1–2 sentences, not just a name)
• times / schedule (or an explicit "not published — ask")
• format (group vs one-on-one vs parent-child)
• price
• who it's for
• phone / contact
• address + Google Maps deep link (query = name + full address so the pin lands on the venue)
• coordinates for the shared map
• site link
• i18n for every text field (see feat(viewer): inline $i18n values — one tree, many languages, auto language switcher #240)

What exists today vs the gaps

✅ Map + MapLink already give pin↔card hover linking (rings + scroll-to-card, popup + pan) — this worked great.
❌ No structured item-card primitive — I generated 27 consistent cards from a Python script; freehand authoring produced wall-of-text cards that the user rejected. A LocationCard/ItemCard component (or a schema-driven itemgrid recipe) that renders the field set above uniformly would fix authoring quality at the source.
❌ No side-pane detail display — the user asked to "hover a pin and display details in a side pane". MapLink scrolls to the card, which is a decent substitute, but a Map mode with a docked detail pane (marker → renders the linked card next to the map) would match the ask directly.
❌ No geocoding help — coords had to be scraped/geocoded manually. Worse, the board shipped with distances computed from a wrong home coordinate (3.6 km off) until re-checked against GSI. A documented recipe step (or CLI helper) using GSI msearch.gsi.go.jp/address-search for JP + Nominatim elsewhere would prevent this class of error. (Nominatim can't resolve Japanese block addresses at all; GSI resolves them to block level.)
❌ No maps-link helper — every 📍 anchor is a hand-built google.com/maps/search/?api=1&query=… URL.

Proposal (incremental)

1. Recipe first: add a location-board recipe to diagram-recipes (item schema → card layout + Map + MapLink wiring + maps-URL/geocode guidance). Cheap, ships in a plugin bump.
2. ItemCard component: whitelisted node that takes {name, badges, type, desc, schedule, format, price, for, phone, address, mapsQuery, site, i18n…} and renders the uniform card — kills wall-of-text boards.
3. Map side-pane mode: Map prop (e.g. detailPane: true) that docks a panel rendering the hovered/selected marker's linked card content.
4. (Stretch) termchart geocode CLI helper.

Reference implementation: the generator lives at the pushed board kagoshima/music-lessons (see its termchart pull spec); related: #240 ($i18n inline values).