# What to build with RouteWasm

## Walking and cycling planners

Let people move endpoints, adjust stops and compare local journeys repeatedly. Use `route` with `pedestrian` or `bicycle`; display the geometry with MapLibre. Initial graph data can be reused across nearby alternatives. Elevation features depend on the chosen build; the retained older worldwide dataset does not include elevation.

## Field tools and travel apps

Plan journeys within retained coverage with unreliable connectivity. Test app startup offline as well as routing. Download and retain the visual map and app assets separately. Provide a storage estimate, progress and a remove-downloads action. Mobile browser support needs real-device testing.

## Interactive reachability maps

Use `isochrone` to explore which places are reachable in a chosen time. Repeated changes can reuse graph tiles, but larger areas or longer durations increase memory and data requirements. Rendering a reachability shape is distinct from calculating it.

## Small distance/time comparisons

Use `sources_to_targets` for bounded local matrices. Keep location counts and coverage small and measure the workload on target devices. The SDK is not a promise of unlimited fleet optimization on a phone.

## GPS trace tools

Use `trace_route` or `trace_attributes` for bounded map-matching workloads. Local calculation avoids a server route request containing the trace; fetching tiles still reveals approximate areas. Protect and retain GPS data according to your own application's requirements.

## Where to start elsewhere

Occasional worldwide directions, live-traffic navigation, large optimization jobs and very long routes often fit hosted server APIs better. RouteWasm's optional server/hybrid product is planned. Start with a measured local workload rather than assuming local execution always wins.