Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

InvalidTagsCheck #224

Merged
merged 6 commits into from
Dec 12, 2019
Merged

InvalidTagsCheck #224

merged 6 commits into from
Dec 12, 2019

Conversation

Bentleysb
Copy link
Collaborator

Description:

This is a generic check for flagging features using TaggableFilters.

The check uses a configurable list of filters. Each filter has 2 parts. The first is a list of AtlasEntity classes (node, edge, area, etc.). The second is a TaggableFilter. If a feature is one of the classes given and passes the TaggableFilter then it is flagged.
The TaggableFilter is also used to generate the instructions for a flag. For each TaggableFilter that an object passes an instruction is added to the flag. The instruction uses the tag keys from the TaggableFilter to give guidance on what the problem is.
There is currently only one filter for this check. It is described in the filter example below.

Filter Example:

Areas and Relations with the tag boundary=protected_area should have a protect_class tag.
A filter to flag this would look like the following:
["area,relation","boundary->protected_area&protect_class->!"]
The first string is a list of the 2 AtlasEntity classes we want to look for. The second string is the TaggableFilter that is looking for the combination of boundary=protected_area without a protect_class tag.

This would flag an osm feature like the following: Way 673787307.

The instruction for flags produced by this filter would look like: Check the following tags for missing, conflicting, or incorrect values: boundary, protect_class

Potential Impact:

This check is similar to ConflictingTagCombinationCheck and ConflictingAreaTagCombination, but more generic. It is possible that those checks could at a later date be absorbed into this check.

Unit Test Approach:

Unit test check a number of combinations for each part of the configurable filter system. Multiple AtlasObject classes and TaggableFilters are tested. There is also a test for the dynamic instructions.

Test Results:

Tested in 7 countries and sampled 129 flags. All flags were true positive cases.

Copy link
Collaborator

@smaheshwaram smaheshwaram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left minor comments. Code LGTM.

*/
private static Set<String> getFilterKeys(final TaggableFilter filter)
{
return Arrays.stream(filter.toString().split("[|&]+"))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regex can be made as a static final variable string.

/**
* Convert a {@link String} of comma delimited
*
* @param classString
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Description for params is missing.

Copy link
Collaborator

@danielduhh danielduhh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I'm a big fan of making these types of checks completely configurable.

@chrushr chrushr merged commit 4ee5c58 into osmlab:dev Dec 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants