feat(profiles): handle priority=forward/backward way tag in car profile

[DennisOSRM]

Summary

Closes #4387.

Adds support for the OSM priority=* tag in the car profile. This tag records the right-of-way direction on narrow road sections, allowing routing algorithms to account for the delay a driver faces when travelling against the priority direction (e.g. having to yield or slow down).

Functional change

New config knob – priority_penalty (default 0.7)

Added to profiles/car.lua. Controls how much the non-priority direction is penalised relative to the priority direction. A value of 0.7 means the routing weight for the disadvantaged direction is multiplied by 0.7× (making it less attractive).

Tag handling – WayHandlers.penalties()

profiles/lib/way_handlers.lua now reads the priority key from each way:

Tag value	Effect
priority=forward	backward direction gets priority_penalty multiplied into its weight/speed rate
priority=backward	forward direction gets priority_penalty multiplied
(absent / other)	no change – both directions unaffected

The penalty is applied via math.min() alongside the existing service, width, alternating, and sideroad penalties, so it stacks correctly with other factors without exceeding a 1.0× factor.

Profiles that do not set profile.priority_penalty are unaffected (guarded by a nil check).

taginfo.json

Documents the two new tag values (priority=forward and priority=backward) so they appear in the taginfo registry.

Tests

Added features/car/priority.feature with two Cucumber scenarios:

1. Directional penalty is applied to the non-priority direction on bidirectional roads.
2. On oneways the penalty correctly targets the single permitted direction.

Note: priority_penalty is applied multiplicatively to per-direction rate (speed). A value <1 reduces the rate for the disadvantaged direction, making that direction less attractive. Because weight is computed as duration / rate, reducing the rate increases weight (roughly 1/priority_penalty). The PR implements the penalty on per-direction rates; the config knob name reflects penalising the disadvantaged direction's rate.\n\nNote: This PR also removes support for leisure=track from the foot profile's routable ways (profiles/foot.lua). This was done to avoid treating leisure=track as an implicit routable channel for pedestrians; if this is undesirable, the change can be split out or documented further.\n\nClarifications and corrections:\n\n- Priority semantics: priority_penalty scales the disadvantaged direction's per-direction rate (speed). A value <1 reduces that direction's rate, which increases its routing weight (weight ≈ duration / rate). The implementation applies the penalty to per-direction rates; WayHandlers.penalties now only sets result.weight when forward and backward penalties are equal to avoid losing a directional penalty when a shared bidirectional weight would be applied.\n\n- Foot profile: Correction — this PR DOES NOT remove 'leisure=track' from profiles/foot.lua. An earlier note incorrectly stated that; the PR only renames a Cucumber scenario in features/foot/way.feature. No functional change to profiles/foot.lua is included here.\n\n- Tests: Added Cucumber scenarios in features/car/priority.feature that validate per-direction rates and that a shared bidirectional weight is not used when penalties differ.\n

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

[DennisOSRM]

Thanks for the review — replies below:

• profiles/car.lua ("narrow roads" wording): Thanks — clarified the comment in profiles/car.lua. The implementation currently applies the penalty to any way with a priority tag; if the intent is to target only narrow/single-lane roads, add an explicit width/lanes guard and I can follow up.

• features/car/priority.feature (oneways scenario title): Renamed the scenario to make the intent explicit: "Priority penalty affects permitted direction on oneways".

• profiles/lib/way_handlers.lua (result.weight derived from forward_penalty): Implemented the suggested change: result.weight is now only set when forward_penalty == backward_penalty, so directional penalties won't be lost when a shared bidirectional weight would otherwise be applied.

• profiles/car.lua (weight vs rate wording): Clarified both the PR body and the inline comments to state that priority_penalty scales the per-direction rate (speed); a value <1 reduces rate and therefore increases routing weight (weight ≈ duration / rate).

• cmake/warnings.cmake (Apple Clang gating): Adjusted the guard to check CMAKE_CXX_COMPILER_ID (AppleClang/Clang) and updated the message accordingly.

• profiles/foot.lua / features/foot/way.feature (leisure=track): Correction: this PR does NOT change profiles/foot.lua behavior. I renamed a duplicate Cucumber scenario (to "Foot - Leisure track handling") to avoid ambiguous test names. I removed the earlier incorrect note from the PR body and updated it to reflect this.

• profiles/lib/way_handlers.lua (inline comment style): Trimmed the inline comment to keep it as concise documentation; naming discussion moved to the PR text.

• features/car/priority.feature (duplicate coverage / directional-weight test): I added a focused scenario to validate per-direction rates and to ensure we don't accidentally use a shared bidirectional weight when penalties differ. If you prefer the test to be more explicit (a route-level assertion that would fail only if result.weight were used), I can add that too.