Conversation
and set NETWORK_FORMAT_VERSION to previous commit hash to force network rebuild
| case "sidewalk" -> new SidewalkTraversalPermissionLabeler(); | ||
| case "noSidewalkCycling" -> new NoSidewalkCyclingTraversalPermissionLabeler(); | ||
| case null -> new USTraversalPermissionLabeler(); | ||
| case null -> new NoSidewalkCyclingTraversalPermissionLabeler(); |
There was a problem hiding this comment.
Is the intent here to make the default NoSidewalkCycling? Does this mean that now there's no way to select USTraversalPermissionLabeler?
There was a problem hiding this comment.
No, the intent is to keep USTraversalPermissionLabeler. This default case was just set for testing but should be reverted before final review of this PR:
49a205a forces use of the NoSidewalkCyclingTraversalPermissionLabeler and should be reverted before merging.
…yal/r5 into sidewalk-traversal-options
Prevents traversing ways with highway=steps and nodes with kerb=raised
60c0ea8 to
552975a
Compare
to force network rebuild
and reorganize custom TraversalPermissionLabelers
0195be3 to
dc178d5
Compare
| } | ||
|
|
||
| if (permissionLabeler instanceof StepFreeTraversalPermissionLabeler) { | ||
| stepFree = ((StepFreeTraversalPermissionLabeler) permissionLabeler).requireStepFree; |
There was a problem hiding this comment.
It feels strange to set this via a way permission labeler, as the labeler instance can't take the action itself and we need to detect its type here. Could stepFree just be considered another separate TransportNetworkConfig option? The boolean field could be pulled up out of StepFreeTraversalPermissionLabeler into TransportNetworkConfig itself. This would then become stepFree = config.stepFree with no instanceof or conditional. The purpose of the field here seems to be only blocking kerbs (not stair/step ways) so perhaps it should be renamed accordingly (e.g. kerbFree or requireKerbCuts).
There was a problem hiding this comment.
Yes, it makes sense to make stepFree another TransportNetworkConfig option.
Ways with highway=steps tags are filtered out where appropriate in the custom TraversalPermissionLabelers.
| * USTraversalPermissionLabeler, except walking is disallowed on ways that allow cars, ways with inclines | ||
| * steeper than a specified limit, and ways with steps. | ||
| */ | ||
| public class StepFreeTraversalPermissionLabeler extends USTraversalPermissionLabeler { |
There was a problem hiding this comment.
Ideally we should avoid the duplicate code between this and NoSteepInclinesTraversalPermissionLabeler. Could this class just extend NoSteepInclinesTraversalPermissionLabeler? Could they just be a single class with a boolean for disallowing steps (stairs) passed into the constructor? This might be further simplified by pulling the requireStepFree field up to the enclosing NetworkConfig.
and reduce duplicate code
... for ways in the base TranversalPermissionLabeler (by passing the TransportNetworkConfig files as an argument), and for nodes with kerb tags Also, reduce duplicate code
... for ways in the base TranversalPermissionLabeler (by passing the TransportNetworkConfig files as an argument), and for nodes with kerb tags Also, reduce duplicate code
98b072a to
dee71f5
Compare
... for ways in the base TranversalPermissionLabeler (by passing the TransportNetworkConfig files as an argument), and for nodes with kerb tags Also, reduce duplicate code
abyrd
left a comment
There was a problem hiding this comment.
Thanks for the updates, this way of structuring the labelers seems quite easy to read and understand. I have not tested this on appropriate data sources with lots of sidewalk and curb/kerb tags, but would be in favor of merging it to dev as-is for testing in combination with other PRs.
We've had a few requests for custom routing profiles, including:
NoSidewalkCyclingTraversalPermissionLabelerin 7f4282a)NoSteepInclinesTraversalPermissionLabeler)This PR adds these capabilities as custom TraversalPermissionLabelers, which can be applied at network build using TransportNetworkConfig options.