Skip to content

chore(nav): Phase 1 HERE Japan transit spike — HALT, custom track cancelled#42

Open
emptylower wants to merge 1 commit into
mainfrom
claude/magical-sinoussi-df4e80
Open

chore(nav): Phase 1 HERE Japan transit spike — HALT, custom track cancelled#42
emptylower wants to merge 1 commit into
mainfrom
claude/magical-sinoussi-df4e80

Conversation

@emptylower

Copy link
Copy Markdown
Owner

Summary

Phase 1 of the in-app navigation overhaul, follow-up to #41. HERE Public Transit v8 fails Japan coverage, so the custom in-map transit UI track (planned Phase 2 / Phase 3) is cancelled — Phase 0's Google Maps Embed API picker remains the long-term solution.

What the spike found

A standalone 10-pair OD probe against transit.router.hereapi.com/v8/routes (Tokyo / Osaka / Kyoto / Sapporo / Nagoya / Fukuoka core scenarios):

  • 0/10 expected operators matched.
  • HERE's /v8/stations endpoint returns station entities for 新宿駅 / 名古屋駅 / 京都駅 but every transports array is empty [] — no line associations, so the router responds with noCoverage / noStationsFound.
  • Routes that did surface: only highway buses (高速バス) and one Toei subway line (三田線). Zero JR rail, zero Shinkansen, zero major private rail (Tokyo Metro / 阪急 / 東武 / 名鉄 / 京急 / 西武 / 京王).
  • HERE Driving v8 + Pedestrian v8 work fine on the same key — the gap is the transit feed itself, not key config or endpoint URL.

Full per-pair table, station-probe data, and "what this rules out for future maintainers" → docs/in-app-navigation-phase1-decision.md.

Program decision

Owner decision after reviewing data: cancel the in-map custom transit program (not defer). Reasoning:

  1. NAVITIME path would require RapidAPI paid subscription + ToS clarification round-trips + 3–4 week custom UI build.
  2. Phase 0 Google Embed picker (feat(nav): in-app travel-mode picker via official Maps Embed API #41) already covers walk / transit / drive / bike with full Google transit data (JR + 私鉄 + Shinkansen).
  3. Custom MapLibre rendering would be a marginal UX gain that doesn't justify the engineering + ongoing-maintenance cost.

Dropped from roadmap: Phase 2 (HERE/NAVITIME provider integration), Phase 3 (visual polish + departure-time picker + provider switch runbook), the provider-agnostic Route TS schema, /api/route/* Worker proxy, KV cache, @here/flexible-polyline dependency.

Stays in production unchanged: lib/route/google.ts, lib/route/embedNavigation.ts, <NavModeToggle>, native-app deep-link mode= propagation.

Files

  • scripts/here-japan-coverage.ts — self-contained spike, no main-code imports, dumps raw JSON to .cache/here-spike/, applies the 9-10/10 GO · 6-8 REVIEW · ≤5 HALT decision gate
  • package.jsonnpm run route:here-spike alias for reproducibility
  • docs/in-app-navigation-phase1-decision.md — decision artifact + ruled-out notes for future sessions

Test plan

  • npm run route:here-spike — produces HALT verdict (exit 3) with 0/10 matched
  • npx tsc --noEmit -p tsconfig.node.json — clean
  • npm run check:line-budget — no new violations (only the 3 pre-existing baseline ones)
  • No production code touched — Phase 0 codepath untouched

🤖 Generated with Claude Code

…celled

10-pair OD probe against HERE Public Transit v8 (transit.router.hereapi.com/v8).
Score: 0/10 expected operators matched. Root cause: HERE has Japan station
entities but every /stations response returns empty `transports` arrays — no
line associations, so /routes returns `noCoverage`/`noStationsFound` for
Shinjuku, Nagoya, Kyoto, Sapporo, Hakata, Osaka, Ueno. The only transit modes
that surfaced were highway buses and one Toei subway line (三田線). HERE
Driving v8 + Pedestrian v8 work fine — the gap is the transit feed, not the
key or the endpoint.

Per owner decision, Phase 2/3 custom in-map transit UI is cancelled (not
deferred). The Phase 0 Google Maps Embed API picker shipped in 99121b4 remains
the long-term solution. NAVITIME path is not being pursued.

Artifact details and "what this rules out for future maintainers" live in
docs/in-app-navigation-phase1-decision.md.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@cloudflare-workers-and-pages

Copy link
Copy Markdown

Deploying seichigo with  Cloudflare Pages  Cloudflare Pages

Latest commit: 27b0453
Status:🚫  Build failed.

View logs

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 27b0453414

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

// Aggregate.
const matchedCount = results.filter((r) => r.matched).length
const errorCount = results.filter((r) => !r.ok).length
const noRouteCount = results.filter((r) => r.ok && r.routeCount === 0).length

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Count HTTP-200 empty routes in no-route summary

When HERE returns 200 with routes: [], processPair marks the result as ok: false, but the aggregate metric computes noRouteCount with results.filter((r) => r.ok && r.routeCount === 0). That condition can never match these empty-route cases, so the script always reports No-route (HTTP 200 but empty): 0/10 even when such responses occurred, which makes the decision report’s diagnostics inaccurate.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant