Turn restriction extraction, explicitly return false for no_* restrictions#2829
Merged
Turn restriction extraction, explicitly return false for no_* restrictions#2829
Conversation
|
|
||
| And the relations | ||
| | type | way:from | way:to | node:via | restriction | | ||
| | restriction | sj | wj | j | yield | |
There was a problem hiding this comment.
can we also add tests that start with only_ stuff like only_if_you_are_lucky or no_not_right_now to make sure we only use recognised tags?
Member
There was a problem hiding this comment.
But we don't right? All we care about is the no_ / only_ prefix.
The actual constraint is based on the fromWayId,viaNodeId,toWayId ids.
There was a problem hiding this comment.
Well, only_if_you_are_lucky would pose a valid restriction. From chat, this is how OSM defines their turn restrictions, though. So we are fine here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue
Closes #2802. This doesn't address the caveat that @Codain brought up here, #2802 (comment), but I think this would require rewriting the parser to be able to know what had been previously returned to the
InputRestrictionContaineron the same relation.Also adds a test for a restriction
yield, which is the undocumented restriction this was originally found on.Tasklist
Requirements / Relations
n/a
cc @danpat @MoKob