Skip to content

Add mapbox directions route - #43

Open
mattpodwysocki wants to merge 2 commits into
mainfrom
feat/directions-api
Open

mattpodwysocki wants to merge 2 commits into
mainfrom
feat/directions-api

Conversation

@mattpodwysocki

Copy link
Copy Markdown
Contributor

What

mapbox directions route — the first command for the Navigation API
category (Directions, Isochrone, Map Matching, Matrix, Optimization, EV
Charge Finder), none of which had CLI coverage before this. Hand-authored
into custom-openapi/ since openapi-specs publishes no spec for the
Directions API yet, following the same convention search already uses.

Routes between 2-25 waypoints for driving (with or without live traffic),
walking, or cycling.

Excluded on purpose:

  • The ~30 electric-vehicle-routing parameters (engine=electric and
    everything under it) — those describe a vehicle's charging curve down to
    the watt, which an integration passes in from a vehicle profile rather
    than something to hand-type as a CLI flag. The EV Charge Finder API is a
    better fit for that case.
  • POST — this spec format has no way to express "GET or POST, caller's
    choice" for the same operation. A real gap for a very long coordinate
    list, not a design choice; noted in the spec's own header for whoever
    picks it up.

Two path-parameter bugs found and fixed generically

Both surfaced from profile's value (mapbox/driving etc.) containing a
literal / — not specific to this command, so fixed for every command:

  1. A spec parameter named profile silently collided with the global
    --profile credentials flag.
    Clap has one namespace of ids per
    command; the generated positional replaced the global one outright
    instead of erring, so mapbox directions route mapbox/driving … failed
    with Invalid profile name "mapbox/driving". Fixed with a small,
    documented override table (ARG_NAME_OVERRIDES in src/spec.rs), same
    shape as the existing BODY_CONTENT_TYPE_OVERRIDES.
  2. An enum-constrained path parameter was being percent-encoded. The
    same escaping that stops a free-text path parameter from smuggling in
    extra path segments (../../tokens/v2/victim etc.) was turning
    mapbox/driving's / into %2F, a 404. Safe to skip once clap's
    PossibleValuesParser has already limited the value to one of the
    spec's own literal strings — nothing left to inject. New path_segment_for
    in src/executor.rs, unit-tested against both the enum and non-enum
    cases.

Verification

Smoke-tested against production, not just unit tests — real routes for
mapbox/driving and mapbox/walking, with --steps, --geometries geojson, --overview full, and --annotations all verified to return the
documented shape. Full transcript and captured response are in
docs/commands.md's new section.

621 tests, cargo fmt --check and cargo clippy --all-targets -- -D warnings both clean.

Not done

The other five Navigation-category APIs (Isochrone, Map Matching, Matrix,
Optimization, EV Charge Finder) and Places/Feedback are tracked as separate
follow-ups, not bundled into this PR.

🤖 Generated with Claude Code

The Navigation API category (Directions, Isochrone, Map Matching, Matrix,
Optimization, EV Charge Finder) has had no CLI coverage — this is the first
of those, hand-authored into custom-openapi/ since openapi-specs publishes
no spec for it yet.

Excludes the ~30 electric-vehicle-routing parameters (engine=electric and
everything under it): those describe a vehicle's charging curve down to the
watt, which an integration passes in from a vehicle profile rather than
something to hand-type as a CLI flag. The EV Charge Finder API is a better
fit for that case. Also excludes POST, which this spec format has no way to
express alongside GET for the same operation — a real gap for a very long
coordinate list, not a design choice.

Two path-parameter bugs surfaced while wiring this up, fixed generically
rather than just for this command:

- A spec parameter literally named `profile` (the routing profile,
  mapbox/driving etc.) silently collided with the global --profile
  credentials flag — clap has one namespace of ids per command, and the
  generated positional replaced the global one outright instead of erring.
  `mapbox directions route mapbox/driving …` failed with `Invalid profile
  name "mapbox/driving"` before this. Fixed with a small, documented
  arg-name override table (ARG_NAME_OVERRIDES), the same shape
  BODY_CONTENT_TYPE_OVERRIDES already uses.
- An enum-constrained path parameter whose only valid values contain a
  literal `/` (again, mapbox/driving) was being percent-encoded to %2F by
  the same escaping that stops a free-text path parameter from smuggling in
  extra path segments or retargeting the request. Safe to skip once clap's
  PossibleValuesParser has already limited the value to one of the spec's
  own literal strings — there is nothing left for a caller to inject.

Smoke-tested against production: real routes for driving and walking
profiles, with --steps, --geometries geojson, --overview full, and
--annotations all verified to return the documented shape.

621 tests, fmt and clippy clean.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@mattpodwysocki
mattpodwysocki requested a review from a team as a code owner September 23, 2026 21:49
first_sentence() in src/main.rs cuts a --help line at the first '.', which
is right after "`mapbox/driving` only" or "`mapbox/driving` and
`mapbox/driving-traffic`" on eight parameters here — a real sentence on its
own that was eating everything substantive that followed it in --help.
--schema and docs/commands.md were never affected; they show the full text.

Fixed by moving the profile-scope note to the end of each description
instead of the front, so the useful part survives the cut.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@danpat

danpat commented Sep 24, 2026

Copy link
Copy Markdown

The ~30 electric-vehicle-routing parameters (engine=electric and everything under it) — those describe a vehicle's charging curve down to the watt, which an integration passes in from a vehicle profile rather than something to hand type as a CLI flag. The EV Charge Finder API is a better fit for that case.

This sentence doesn't make a lot of sense. The EV Charge Finder API is for finding charging stations. The engine=electric parameter to the Directions API is for finding routes, and it requires the discharge/recharge profile for the vehicle to work.

Please make sure to validate that the vibe-coding here is reviewed by folks that know the APIs properly - it seems that the LLM is coming to some faulty conclusions somehow.

Comment thread docs/commands.md
#### Parameters

`<routing-profile>` and `<coordinates>` (both positional) are required.
`<routing-profile>` is one of `mapbox/driving-traffic`, `mapbox/driving`,

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

For some of our OEM customers, this is not true - but we don't publish any of those additional profiles.

schema:
type: number
minimum: 1
maximum: 1000

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

What if we change this server-side to something bigger?

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.

2 participants