A profile is your starting point.
Choose a kind of walk, like Green or Quiet. Each profile comes with its own preferences and rules.
A little more your kind of walk
Shorter isn’t always better.
Sometimes a few extra minutes are worth a greener street. Route preferences help you make that trade-off.
Walk or Bike, before you route.
Bicycle routing is experimental. Network gaps can cause detours.
Choose your travel mode in the map. Bike is available when this service offers bicycle routing. Switching keeps your start and end markers and recalculates for your selected mode.
Bike offers one direct route with an estimated speed of 12 km/h. Walking preferences, walking alternatives and walking street scores do not apply. Purple dots show the bicycle route’s actual endpoints; your requested markers stay in place.
When an endpoint is too far from the bicycle network or no bicycle path exists, the service returns “Cycling unavailable.” Your selection stays Bike. The service currently allows up to 25 metres between each requested point and its routed endpoint; proximity does not establish access across barriers.
Map layers & technical details identify the graph for the selected mode. The preference examples below describe walking.
A weight says how much it matters.
Turn a preference up to give it more influence. At zero, that preference has no effect.
A policy says what counts.
Rules translate street information into a preference. For example: how much tree cover deserves a boost?
Today’s catalog
What each profile actually weights.
A weight between 0 and 1 is how strongly that attribute may change the walk. Reward attributes (green, trees, water, lights, presence) make matching streets cheaper to use. Penalty attributes (noise, crashes, crime) make matching streets more expensive. Zero means “ignore this.” Fast is the shortest-time baseline: every weight is zero.
Fast foot_fast
Shortest time. No LiveMap attributes.
No attribute weights.
Green foot_green
Prefer greenery and tree cover together.
- green 0.9
- trees 0.9
Water foot_water
Prefer streets nearer water.
- water 0.9
Lit foot_lit
Prefer better-lit streets.
- lights 0.3
Quiet foot_quiet
Avoid noisier streets.
- noise 0.9
Fewer crashes foot_lowcrash
Avoid streets with pedestrian crash history. Raw five-year counts, accident only.
- accident 1.0
Safe foot_safe Legacy
Unchanged four-signal composite. Still routes; superseded by Fewer crashes and Lit.
- accident 0.7
- crime 0.7
- presence 0.4
- lights 0.3
Calm foot_calm Legacy
Unchanged quiet/green/water/tree composite. Still routes; superseded by Green, Water, Lit, and Quiet.
- noise 0.8
- green 0.5
- water 0.4
- trees 0.2
Deprecation is a catalog flag, never a silent alias. Tune
weights on the
map lab; persisted values live in
runtime/config-livemap.yml. The live authority
is GET /api/v2/routing/profiles,
including weights and all resolved policy blocks. The
deprecated v1 catalog includes weights only.
For automatic pre-trip planning, send
POST /api/v2/routing/plan without
profiles. The engine keeps the configured
baseline (Fast here), then successful non-deprecated
alternatives strictly less than 50% longer by distance.
It does not filter overlap or deduplicate identical routes.
An unreachable or zero-distance baseline is returned alone.
To keep every requested key, including legacy composites
and NoRoute results, provide an explicit
nonempty profile list (compatibility mode).
See the v2 API reference.
Try it for yourself
Two ways to get there.
One street is quicker. The other has more tree cover. Change what matters and see which walk wins.
The tree-lined walk wins.
Your preference for tree cover outweighs the extra 2 minutes.
The walking times stay at 10 and 12 minutes. Preferences change the route choice, not how fast you walk.
Weight · how much
Start here. Keep the rules and adjust how strongly they affect your walk.
Street information80% tree cover
What we know about this street.
PolicyQualifies for a 1.50× boost
At least 50% tree cover is needed.
Weight1.35× route priority
70% of the way from neutral to the full boost.
You don’t have to divide up 100%.
Each weight is independent. Trees can be at 80% and quietness at 80% too. That means both preferences are turned up; it isn’t a budget to share.
Preferences make trade-offs.
A greener street may also be noisier. The applicable preference factors multiply for each street segment, and the router compares complete walks. Distance and travel time still matter.
The map can only use what it knows.
A setting may have little effect if nearby streets are similar or information is missing. Safety-related preferences use available indicators; they cannot guarantee a safe route.
Curious about the numbers?
LiveMap turns a policy’s full-strength factor into a street preference using this rule:
Street preference = 1 + weight × (policy factor − 1)
Here: 1 + 0.70 × (1.50 − 1) = 1.35.
A factor of 1 is neutral. Above 1 favours a street; below 1 discourages it. A weight of zero always brings the factor back to 1. A 1.50× priority factor is not a 50% chance of choosing a route or a promise of a 50% better walk.
This illustration uses one tree-cover threshold, uniform conditions along each route, and the same walking speed. Its comparison score is walking minutes divided by priority, plus a small distance cost of 0.2 per kilometre. Lower wins. These are teaching values, not the configured profile or a live routing request.
| Walk | Walking time | Priority | Comparison score |
|---|---|---|---|
| Quick street · 0.8 km | 10 min | 1.00× | 10.16 |
| Tree-lined · 0.96 km | 12 min | 1.35× | 9.08 |
In the real map, LiveMap applies the configured policies to individual street segments. Policies can have several bands, use measured values or precomputed scores, and depend on time of day. GraphHopper combines segment costs, including travel time, priority, distance influence and any turn costs.
For the underlying routing model, see GraphHopper 11’s custom model documentation.
Find your balance.
Choose a profile, place your start and finish, then adjust a preference.