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.
Description:
This is a major overhaul of the SignPostCheck, to fix a few bugs and make an enhancements.
The major reason for the overhaul was to fix a bug where multiple edges would end up in the same flag, even though they were geographically separate (sometimes by over a kilometer). This occurred because these items were connected to the same motorway or trunk edge, but on different ends, and the edge was used as the starting object for the check. Now the starting object is the ramp edges themselves, so the starting object is always the only item that is flagged. As part of this change, the configurables
ramp.max.edges
andarterial.minimum
were removed. The logic these supported is no longer in the check.Previously these three items, that are about 2km apart, were part of the same flag. Now they would all be separate flags.
![Screen Shot 2019-04-23 at 9 21 01 AM](https://user-images.githubusercontent.com/24948563/56598383-3f74ac00-65a9-11e9-9ba8-68fb35cb1d21.png)
The second bug that was fixed was that this check assumed it was always working with one way roads. This meant that edges/ways would sometimes be flagged multiple times. The check now accounts for reverse edges and way sectioning.
The final bug fix was to look for destination relations, instead of just destination tags, and to add the tags
destination:backward
anddestination:forwards
to thedestination_tag.filter
configurable. This fixed a few false positive flags where items were flagged for not having destination tags.The one enhancement was to add an optional part of the check for branching ramps. This is to catch where a ramp has a single entrance, but multiple exits. In these cases, when the ramp branches towards the different exits there usually should be destination tags. However, some locations may not use road signs for these instances. So, this feature is controlled by a configurable, and can be turned on or off as needed.
An example of a ramp branch with a destination tag:
![Screen Shot 2019-04-23 at 9 33 08 AM](https://user-images.githubusercontent.com/24948563/56599154-dc841480-65aa-11e9-9b8d-a0649efe5798.png)
Potential Impact:
None
Unit Test Approach:
Updated the unit test configurations to match the new design of the check. Also updated existing unit tests, and created a new one to test the new branching logic.
Test Results:
Ran on 6 countries and sampled 540 out of 1792 flags. All flags appeared valid.