Description
Check for bad tags, tags that have a typo, and unwanted tags.

For unwanted tags, the tag should exist in OSM Wiki Data (e.g., https://wiki.openstreetmap.org/w/api.php?action=wbgetentities&sites=wiki&titles=Key:lanes&languages=en&format=json -- human readable here). This also affects tags that have a typo (if the key indicates that it has well-known values (example: Key:bridge:movable), if there is not a wiki item for that value, then more work must be done). This requirement is due to the Meta information that each key can have (de facto, in use, approved, rejected, voting, draft, abandoned, proposed, obsolete, deprecated, discardable, and imported). discardable and rejected are definitely unwanted, while obsolete and deprecated should be used to indicate that there is a newer tagging method to the user.

Requirements

1. Check Candidate

• Has tags
• Is not already flagged by an existing bad tag/key/value check (this may be difficult to do, see ConditionalRestrictionCheck, a utility class/parent class may be necessary to register keys that have specific checks, but probably calling validCheckForObject will be good enough).

Use Cases
This section summarizes the various use cases for this check and provides potential enhancement suggestions if needed. The uses cases should act as a test in a way, such that when the analysis/enhancement is completed, these types of use cases should be found or eliminated.

For each use case, please add a screenshot of the feature & openstreetmap.org link (or other sources). If necessary, edit the screenshot to better illustrate the use case.

Example:

Case 1: Invalid Highway Tag (Togo)

• highway=Station de carburant pour voiture should be flagged (and should already be flagged). This check is primarily for instances where hardcoded values are not available (as it is with highway).
• https://www.openstreetmap.org/node/5343281075
  

Further investigation
It is expected that there will be false positives where a proposal has recently been accepted, but a Wiki Data item has not been created. An additional script should be provided to parse the json for items that may need to be added to the wiki (automatically done for keys by bot when a tag matches a regex AND there are more than 10 instances).

Supported regions
All countries

What's not supported (optional):
Autocorrections -- this may be possible with the addition of Levenshtein distance calculations, when there is expected to be a well-known value (so names need not apply).

Intended methodology:

• InvalidTagsCheck will be modified to check the key and value of an object if it is not flagged already (the assumption being that the specific flags are more accurate than those on the wiki)
• If a local TagInfo database exists, query the database for the key and value incidence. Record this to a variable.
• For each key, get the appropriate wiki data item (preferably from a data dump, not the live server, a utility script similar to this should be written).
  • If the key has the well-known values classification, check that the tag page exists. Else if there is a regex, check the value against the regex. Else continue on.
  • If the key has a status of discardable, rejected, abandoned, or imported (imported is a maybe), flag for removal.
  • If the key does not exist in wiki data, and the key is over a specific (configurable?) threshold, write instructions for a wiki editor
  • If the key does not exist in wiki data, and the key is under a specific (configurable?) threshold, write instructions for modification/removal
  • If the key is over a specific (configurable?) threshold, is not well-known, flag for a wiki editor to add a regex expression checker for (so a name tag could be expected to match .*).
  • If the key is prohibited on the current element (node/way/area/relation), add instructions to that effect
• A script must be written to remove and consolidate instructions for wiki editors, to separate those from those that should be fixed.

References

• OSM Data Items
• OSM Wiki Dump (either this, making lots of network calls)
• Value Validation Regex (example)
• TagInfo Usage Database
• Deprecated Tags
• Tagwatch Cleaner

Which Atlas check is the fix suggestion related to?

Duplicate Node Check
Description: The purpose of this check is to identify Nodes that are in the exact same location
Script: https://github.com/osmlab/atlas-checks/blob/1a7dc0d816021e7cfb751ede47445e9e1c6d1186/src/main/java/org/openstreetmap/atlas/checks/validation/points/DuplicateNodeCheck.java

Describe more details of suggested fix(es)

Suggested Fix 1:

• Type of fixing: Geometry fix

• Operation: Delete

• Suggested Action: Remove duplicated node(s)

Is there any code enhancement needed if adding the fix suggestion component?

No

hi

just exists some official docker image for running in standalone way this tool?
I have only found references to continuous integration config realtive to docker..

Which Atlas check is the fix suggestion related to?

MixedCaseNameCheck
Description: https://github.com/osmlab/atlas-checks/blob/dev/docs/checks/mixedCaseNameCheck.md
Script: https://github.com/osmlab/atlas-checks/blob/main/src/main/java/org/openstreetmap/atlas/checks/validation/linear/edges/OverlappingEdgeCheck.java

Describe more details of suggested fix(es)

Suggested Fix 1:

• Type of fixing: Tag fix

• Operation: Modify

• Suggested Action: Modify name(s) to appropriate case

• Restriction: Fix should align with languages in selected countries

Is there any code enhancement needed if adding the fix suggestion component?

No

Description
This checks for highway tag changes greater than one classification.

Requirements
Must be a car-navigable highway Edge
Flag edges where the edge requires a link highway tag

Use Cases
True Positive
Case 1:
The VALID case where an edge is connected to another edge of different classification NOT through a *_link edge
Highway=primary Edge connects directly to a highway=tertiary Edge
This should likely be set as highway=primary_link
https://www.openstreetmap.org/way/698449634

False Positive
Case 1:
Highway=primary Edge connects directly to a highway=residential Edge
This is correct due to a gated military base causing a valid drop in classification along the path
https://www.openstreetmap.org/way/290065445

Supported regions
This should be fine in all countries

Which Atlas check is the fix suggestion related to?

FloatingEdgeCheck

Description: https://github.com/osmlab/atlas-checks/blob/dev/docs/checks/floatingEdgeCheck.md

Source Code: https://github.com/osmlab/atlas-checks/blob/dev/src/main/java/org/openstreetmap/atlas/checks/validation/linear/edges/FloatingEdgeCheck.java

Describe more details of suggested fix(es)

Suggested Fix 1:

• Type: Geometry

• Operation: Delete

• Action: Remove the floating edge

Is there any code enhancement needed if adding the fix suggestion component?

No

It looks like the newest version of Atlas has a lambda function that is not serializable, which is causing a NotSerializableException. More specifically, when I run the project, I'm getting this error:
Exception during serialization: java.io.NotSerializableException: org.openstreetmap.atlas.tags.filters.LineFilterConverter$$Lambda$67/1932303196.

It looks like it's fixed by this PR. Once there's a new version of Atlas with the fix available, we should bump the version of this project as well.

Which Atlas check is the fix suggestion related to?

Orphan Node Check
Description: https://github.com/osmlab/atlas-checks/blob/dev/docs/tutorials/tutorial2-OrphanNodeCheck.md
Script: https://github.com/osmlab/atlas-checks/blob/dev/src/main/java/org/openstreetmap/atlas/checks/validation/points/OrphanNodeCheck.java

Describe more details of suggested fix(es)

Suggested Fix 1:

• Type of fixing: Geometry fix

• Operation: Delete

• Suggested Action: Remove unconnected nodes with no tags and which are not part of a relation

Is there any code enhancement needed if adding the fix suggestion component?

No

Description

Migration of Osmose check #7310. This check will flag navigable Ways which appear to have limited height clearance, but do not have an explicit maxheight tag. The use cases include tunnels, roads with covered=yes tag and roads passing under bridges.

Requirements

• Atlas object is an Edge
• It has a highway, railway or waterway tag
• It either has a tunnel or covered tag, or crosses another Edge tagged as bridge
• It does not have a maxheight or maxheight:* tag

Use Cases

Case 1: A tunnel without height limit. (Norway)
OSM link: https://www.openstreetmap.org/way/627321678

Case 2: A covered road without height limit. (Brazil)
OSM link: https://www.openstreetmap.org/way/742680126

Case 3: A road without height limit, passing under a bridge. (Poland)
OSM link: https://www.openstreetmap.org/way/397757002
(this case does not appear to be fully implemented in Osmose at present - there is only some code that is commented out)

Supported regions

All countries.

Describe the bug
Atlas check -> OverlappingEdgeCheck
Method -> isPartOfClosedWay
stream(nextEdge.outEdges()) returns both Master and negative edges.
To fix the issue add .filter(Edge::isMasterEdge)

To Reproduce
Pass OSM Way: 97245856
https://www.openstreetmap.org/way/97245856

in ubuntu 18.04 with openjdk 11 obtain this error after follow the instructions
(gradle installed via apt install gradle, version 4.4.1)

./gradlew run

Downloading https://services.gradle.org/distributions/gradle-6.3-bin.zip
.........10%..........20%..........30%.........40%..........50%..........60%.........70%..........80%..........90%..........100%

Welcome to Gradle 6.3!

Here are the highlights of this release:
 - Java 14 support
 - Improved error messages for unexpected failures

For more details see https://docs.gradle.org/6.3/release-notes.html

Starting a Gradle Daemon (subsequent builds will be faster)
> Task :compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Could not target platform: 'Java SE 11' using tool chain: 'JDK 8 (1.8)'.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.3/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 4m 27s
1 actionable task: 1 executed

Description
This check identifies potential roundabouts that are not properly tagged.

Requirements
This check is to look for suspicious circular junctions that may be roundabout without the “junction=roundabout” tag.

1. Check Candidate (example)
   a) Closed way e.g. start and end location shared same lat/lon
   b) Intersecting at least with two navigable roads
   c) circular shape: angle between sections is > 10 or < 40 degree

Use Cases
This section summarizes the various use cases for this check and provides potential enhancement suggestions if needed. The uses cases should act as a test in a way, such that when the analysis/enhancement is completed, these types of use cases should be found or eliminated.

For each use case, please add a screenshot of the feature & openstreetmap.org link (or other sources). If necessary, edit the screenshot to better illustrate the use case.

Example:
tbd

Supported regions
globally

I tried to run checks on Irans map (116 Mb obf ) which is a lot bigger than the Belize, of course atlas-check needs more ram to handle that
I increased Linux Ram to 6000 MB but after running atlas-check there was an error, “java.lang.OutOfMemoryError: Java heap space”

I checked this command to see how much is the heap size

root@kali:~/atlas-checks# java -XX:+PrintFlagsFinal -version | grep -iE 'HeapSize|PermSize|ThreadStackSize'
     intx CompilerThreadStackSize                  = 1024                                   {pd product} {default}
   size_t ErgoHeapSizeLimit                        = 0                                         {product} {default}
   size_t HeapSizePerGCThread                      = 43620760                                  {product} {default}
   size_t InitialHeapSize                          = 98566144                                  {product} {ergonomic}
   size_t LargePageHeapSizeThreshold               = 134217728                                 {product} {default}
   size_t MaxHeapSize                              = 1572864000                                {product} {ergonomic}
    uintx NonNMethodCodeHeapSize                   = 5824844                                {pd product} {ergonomic}
    uintx NonProfiledCodeHeapSize                  = 122916698                              {pd product} {ergonomic}
    uintx ProfiledCodeHeapSize                     = 122916698                              {pd product} {ergonomic}
     intx ThreadStackSize                          = 1024                                   {pd product} {default}
     intx VMThreadStackSize                        = 1024                                   {pd product} {default}
openjdk version "11.0.3" 2019-04-16
OpenJDK Runtime Environment (build 11.0.3+1-Debian-1)
OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1, mixed mode, sharing)

I don't know how to increase it, I tried to edit gradlew file
changed Line 31 from
DEFAULT_JVM_OPTS='"-Xmx64m"'
to
DEFAULT_JVM_OPTS="\"-Xmx5024m\" \"-Xms256m\" \"-XX:MaxPermSize=5024m\""
but it didn't work. The JAVA process during checks was using 1.7G Ram %30 of dedicated ram to Linux

Running from dev branch and gadle4.7. I get the following:

gradle run

...

> Task :run FAILED

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/maning/projects/git/atlas-checks/build.gradle' line: 314

* What went wrong:
Execution failed for task ':runChecks'.
> Process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/bin/java'' finished with non-zero exit value 52

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
See https://docs.gradle.org/4.7/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 11m 55s
7 actionable tasks: 7 executed

Atlas checks is throwing a ConcurrentModificationException based around the EventService class. This is a run time exception that is breaking execution of the program

2018-10-19 10:16:55 ERROR Command:285 - Command execution failed.
org.apache.spark.SparkException: Job aborted due to stage failure: Task 0 in stage 0.0 failed 1 times, most recent failure: Lost task 0.0 in stage 0.0 (TID 0, localhost): java.util.ConcurrentModificationException
        at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
        at java.util.HashMap$KeyIterator.next(HashMap.java:1466)
        at java.lang.Iterable.forEach(Iterable.java:74)
        at org.openstreetmap.atlas.checks.event.EventService.complete(EventService.java:65)
        at org.openstreetmap.atlas.checks.distributed.IntegrityCheckSparkJob.lambda$start$1401df6c$1(IntegrityCheckSparkJob.java:372)
        at org.apache.spark.api.java.JavaPairRDD$$anonfun$pairFunToScalaFun$1.apply(JavaPairRDD.scala:1018)
        at org.apache.spark.api.java.JavaPairRDD$$anonfun$pairFunToScalaFun$1.apply(JavaPairRDD.scala:1018)
        at scala.collection.Iterator$$anon$11.next(Iterator.scala:328)
        at scala.collection.Iterator$$anon$14.hasNext(Iterator.scala:389)
        at scala.collection.Iterator$class.foreach(Iterator.scala:727)
        at scala.collection.AbstractIterator.foreach(Iterator.scala:1157)
        at org.apache.spark.rdd.RDD$$anonfun$foreach$1$$anonfun$apply$32.apply(RDD.scala:912)
        at org.apache.spark.rdd.RDD$$anonfun$foreach$1$$anonfun$apply$32.apply(RDD.scala:912)
        at org.apache.spark.SparkContext$$anonfun$runJob$5.apply(SparkContext.scala:1869)
        at org.apache.spark.SparkContext$$anonfun$runJob$5.apply(SparkContext.scala:1869)
        at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:66)
        at org.apache.spark.scheduler.Task.run(Task.scala:89)
        at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:214)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

This appears to be caused by the updates in #74. Line 65 iterating through processors and removing from processors by calling unregister().

Which Atlas check is the fix suggestion related to?

Invalid Tag Check
Description: https://github.com/osmlab/atlas-checks/blob/ca315302ff16b1743593a5d4b4aa71c4b4e57b02/docs/checks/invalidTagsCheck.md

Script: https://github.com/osmlab/atlas-checks/blob/ca315302ff16b1743593a5d4b4aa71c4b4e57b02/src/test/java/org/openstreetmap/atlas/checks/validation/tag/InvalidTagsCheckTest.java

Describe more details of suggested fix(es)

Suggested Fix 1: Invalid Area Tag in Roundabout

• Type of fixing: Tag fix

• Operation: Delete

• Suggested Action: Remove "area=*" tag on roundabout

Is there any code enhancement needed if adding the fix suggestion component?

No

Describe the bug
Improve check output by implementing following logic:

1. Remove Turning loops, Turning Circles.
2. Remove navigable ways with motor_vehicle=no
3. Remove navigable ways with foot=yes
4. Remove navigable ways with footway tag
5. Remove navigable ways with construction tag

To Reproduce
Turning Circle: example
Turning Circle: example2
Navigable but motor_vehicle=no: example
Navigable with foot=yes: example
Navigable with footway tag: example
Navigable with construction tag: example
Navigable with access=private: example

Expected behavior
All above cases should be extracted from the RoundaboutMissingTagCheck

Is your feature request related to a problem? Please describe.

• Create FeatureChange & ChangeDescription deserializer.

This deserializer will read CheckFlag GeoJSON outputs and convert the fix suggestions in the ChangeDescription model. This will allow us to leverage all that comes with the FeatureChange and ChangeDescription classes

Description
OSMOSE 4020 migration. This check will flag roundabout with attached Area tag.

Note: this check will be added to existent Altas Check: InvalidTagsCheck

Requirements

• Atlas object is an Edge
• Must be a roundabout with tag “highway=(regular navigable roads)” and “junction=roundabout”
• "area=yes" should not be attached to roundabout
• "area=no" is redundant

Use Cases
Case 1: False Negative (Columbia)
Area=yes is applied in the roundabout to make the geometry invalid as a drivable way
OSM Link: https://www.openstreetmap.org/way/563144251

Case 2: False Negative (Brazil)
Area=no tag on the geometry is redundant. With the area tag the road will be still presented a drivable way.
OSM Link: https://www.openstreetmap.org/way/328196762

Supported regions
All regions

What's not supported (optional):
This check only looks at Edges

Describe the bug
MalformedRoundaboutCheck is missing logic of checking whether the roundabout contain SyntheticBoundaryNode. As a result properly shaped roundabout got flagged (false positive).

To Reproduce
Run MalformedRoundaboutCheck against San Marino. Roundabout https://www.openstreetmap.org/way/288170227 is flagged due to border crossing between Italy and San Marino. See screenshot below.

Expected behavior*
Roundabouts with SyntheticBoundaryNode should not be flagged.

Screenshots & Stack traces

Is your feature request related to a problem? Please describe.

• Create a text processing job that converts auto-fix suggestions into JOSM files.

The JOSM file format is created when saving and loading data into JOSM.
Supported operations: modify, delete

<?xml version='1.0' encoding='UTF-8'?> 
<osm version='0.6' generator='JOSM'> 
  <bounds minlat='51.5076478723889' minlon='-0.127989783553507' maxlat='51.5077445145483' maxlon='-0.127774884645096' origin='OpenStreetMap server' /> 
  <node id='346364767' action='delete' timestamp='2009-02-16T21:34:44+00:00' user='dankarran' visible='true' lat='51.5076698' lon='-0.1278143' /> 
</osm> 

Which Atlas check is the fix suggestion related to?

Highway To Ferry Tag Check
Description: https://github.com/osmlab/atlas-checks/blob/6c987dd8bb0e87df4900e9a7a605f6a13ecfce7d/docs/checks/highwayToFerryTagCheck.md
Script: https://github.com/osmlab/atlas-checks/blob/6c987dd8bb0e87df4900e9a7a605f6a13ecfce7d/src/main/java/org/openstreetmap/atlas/checks/validation/tag/HighwayToFerryTagCheck.java

Describe more details of suggested fix(es)

Suggested Fix 1:

• Type of fixing: Tag fix

• Operation: Modify

• Suggested Action: Change the highway=* tag to ferry=* tag that aligns with the classification of connected highways

Is there any code enhancement needed if adding the fix suggestion component?

No

Description
The check should assure that conditional restrictions are following the expected format as described in the OSM Wiki page here: https://wiki.openstreetmap.org/wiki/Conditional_restrictions

Requirements

• any OSM primitive that has a tag containing ":conditional" is a candidate for this check

Use Cases
The conditional restriction can have one of the following formats (fields in square brackets [..] are optional):

1. <restriction-type>[:<transportation mode>][:<direction>]:conditional
   = <restriction-value> @ <condition>[;<restriction-value> @ <condition>]
2. In access tags that are limited to a specific transportation mode the restriction-type access: is usually omitted resulting in :
   <transportation mode>[:<direction>]:conditional
   = <restriction-value> @ <condition>[;<restriction-value> @ <condition>]

Restriction type = This can be any type of restriction that may have conditional validity
Transportation mode = This key-part specifies the vehicle category or transportation mode to which the restriction applies, e.g. bicycle, motor_vehicle, foot, agricultural.
Direction = Use forward and backward to indicate in which direction the restriction applies
Value = The value comprises the actual restriction followed by the @ character and the condition. Add spaces before and after the @ character to improve readability.
Condition = The condition could be :

• time and date
• road condition
• vehicle property
• vehicle usage
• user group
• purpose of access
  Except for very simple conditions like "wet" or "Su" it is recommended to enclose the condition in round brackets.

Example:

*Maxspeed:
maxspeed:conditional=120 @ (06:00-19:00)

*Motor vehicle
motor_vehicle:conditional=no @ (10:00-18:00 AND length>5)

motor_vehicle:conditional=delivery @ (Mo-Fr 06:00-11:00,17:00-19:00;Sa 03:30-19:00)

*Turn restriction
restriction:conditional=no_left_turn @ (length > 6)

*One way
oneway:forward:conditional=yes @ (Mo-Fr 07:30-10:00)

Others:
maxweight:conditional=none @ delivery
fee=no @ Monday

Full example list here: https://wiki.openstreetmap.org/wiki/Conditional_restrictions

Further investigation

Supported regions
All countries

What's not supported (optional):

• Parking lane restrictions as the parking lane scheme has defined its own way of dealing with conditions.
• Hour condition format check -> this should be a check on its own

References
https://wiki.openstreetmap.org/wiki/Conditional_restrictions
https://github.com/openstreetmap/josm/blob/master/src/org/openstreetmap/josm/data/validation/tests/ConditionalKeys.java

Flag examples

• The conditional key "stopping:conditional" does not respect the "<restriction-type>[:<transportation mode>][:<direction>]:conditional" format
• The conditional value "shared_bus_way|| @ (Mo-Fr 06:00-10:00)" does not respect the format "<restriction-value> @ <condition>[;<restriction-value> @ <condition>]"

The link to the Docker Sandbox 404's.

Description
This is largely a migration of Osmose 1070/1220 (waterway area overlaps, riverbank without river). This is a followup of #331 . This is in a separate pull request due to having slightly different requirements, and likely needing some work on the intersects logic. The waterway overlaps actually falls under Osmose 1150.

Requirements

• Is an Edge or a Line (logic should use LineItem where ever possible), in case there is an non-closed waterway area
• Is an Area or Relation (relations should be checked just in case, but it should be an area before it is passed to the check).
  and
• Has a waterway area tag (mapcss fragment)

area[waterway=riverbank],
area[natural=water],
area[natural=coastline]

Use Cases
This section summarizes the various use cases for this check and provides potential enhancement suggestions if needed. The uses cases should act as a test in a way, such that when the analysis/enhancement is completed, these types of use cases should be found or eliminated.

For each use case, please add a screenshot of the feature & openstreetmap.org link (or other sources). If necessary, edit the screenshot to better illustrate the use case.

Example:

• Case 1: Riverbank without waterway (Belize)
  
  Osmose issue

• Case 2: Overlapping water area (Belize)
  
  Osmose issue

Further investigation

• Osmose seems to ignore natural=water + water=river for riverbank area missing river way.

Supported regions
All countries

What's not supported (optional):
#331 has the rest of the relevant checks, and therefore a pull request for this issue will not duplicate those checks, and hence does not support them.

References

• OSM Wiki Waterways: https://wiki.openstreetmap.org/wiki/Waterways
• OSM Wiki Riverbank: https://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
• Waterway way checks: https://github.com/taylorsmock/atlas-checks/tree/feature/waterway-check

Description
Migration of Osmose check #7012. This check will flag bridges of significant size which only have a generic bridge=yes tag without any details such as bridge type or its structure.

Requirements

• Atlas object is an Edge
• Its length is greater than X meters (configurable, default value is 500.0)
• It it tagged with bridge=yes
• It is tagged with railway or highway=* where * is one of: motorway, trunk, primary, secondary
• It does not have a bridge:structure tag

Use Cases
Case 1: A long bridge without structure. (Germany)
OSM link: https://www.openstreetmap.org/way/4407849

Supported regions
All countries.

CheckFlagEvent.featureDecorator() throughs an IllegalArgumentException when flag objects have a highway tag value that is not in Atlas's HighwayTag Enum set. Normally this would not occur because highway tags are filtered out in atlas creation by the edge.json filter. However, when non-edges are flagged and have highway tags this can occur.

Which Atlas check is the fix suggestion related to?

OverlappingEdgeCheck:
Description: Checks that two Edges do not share the same two consecutive geometry points. Each segment of a
main Edge is checked for overlapping segments of other main edges. If an Edge has previously been
found to overlap some Edge, it will not be flagged unless it is overlapped by an Edge not flagged yet. It ignores edges that are part of pedestrian areas. (Document unavailable)

Source Code:https://github.com/osmlab/atlas-checks/blob/dev/src/main/java/org/openstreetmap/atlas/checks/validation/linear/edges/OverlappingEdgeCheck.java

Describe more details of suggested fix(es)

Suggested Fix 1:

• Type: Geometry
• Operation: Delete
• Action: Remove the duplicate highways

Is there any code enhancement needed if adding the fix suggestion component?

No

If yes, provide details about what and where the enhancement is needed. Ex. the fix requires excluding checks on relation

Description
Suggestion for adding some extra reasons to flag turn restrictions in the already existing InvalidTurnRestrictionCheck.

Requirements
Check Candidate for the extra steps:

• Is a Relation that has already passed the original check

Requirements to be flagged:

• if any of the members that are of Edge type do not have the highway=* tag, the object should be flagged.
• if any of the members that are of Edge type have the oneway tag but the restriction does not respect the direction, the object should be flagged.
  Detailed steps:
  • from member with oneway=yes and firstNode='via' or oneway=-1 and lastNode='via'
  • to member with oneway=yes and lastNode='via' or oneway=-1 and firstNode='via'

Use Cases

Case 1: Bad oneway direction on member (France)

• in this case the no_right_turn should be implied since the to member has a oneway=yes tag. From wiki page: "There is no need to restrict turning into the wrong way of a one way street. This is taken for granted."
  -https://www.openstreetmap.org/relation/1697422
  

• similar with the above example: https://www.openstreetmap.org/relation/1697421

Case 2: Bad oneway direction on member (USA)

• in this case the from member should not be possible since it is a oneway in the opposite direction.
• https://www.openstreetmap.org/relation/10997568
  

Supported regions
All countries

What's not supported (optional):

References
https://wiki.openstreetmap.org/wiki

Description
The InvalidTagsRegexCheck could have a similar approach as the InvalidTagsCheck but would use regex to verify certain tag values.
To begin with it should verify if the source tag describes a legal source of data imported in OSM.
Examples of invalid sources: Google, Here.

Requirements

• Any OSM primitive that has a source tag should be feasible for this check.

Use Cases
There are multiple examples of cases where certain information in OSM comes from illegal sources like:

• Google
• Here
• vworld
  OSM blacklist

Example:

Case 1: [Cycleway originating from Google.] (Romania)

• The way has a google maps link as a source
• (https://www.openstreetmap.org/way/560117102)

Case 2: [Park originating from Google.] (Italy)

• The park has google as source
• (https://www.openstreetmap.org/way/276514644)

Case 3: [Building originating from VWorld.] (South Korea)

• The building has VWorld as source
• (https://www.openstreetmap.org/way/368940416)

Case 4: [Building originating from Here.] (Germany)

• The building has Here as source
• (https://www.openstreetmap.org/node/4062814842)

Further investigation

Supported regions
All regions should be supported.

What's not supported (optional):

References
https://wiki.openstreetmap.org/wiki/Key:source
https://wiki.openstreetmap.org/wiki/Tag:boundary=administrative

Which Atlas check is the fix suggestion related to?

Road Name Gap Check
Description: https://github.com/osmlab/atlas-checks/blob/dev/docs/checks/RoadNameGapCheck.md
Script: https://github.com/osmlab/atlas-checks/blob/dev/src/main/java/org/openstreetmap/atlas/checks/validation/tag/RoadNameGapCheck.java

Describe more details of suggested fix(es)

Suggested Fix 1:

• Type of fixing: Tag fix

• Operation: Add or Modify

• Suggested Action: 1) Add proper road segment name tag when it's missing. 2) Modify proper road segment name tag when it's inconsistent with its connected road segments

Is there any code enhancement needed if adding the fix suggestion component?

No

3040 IncorrectTagCheck - Requirements

Developers: Brian Jorgenson
Date: 08/20/2020
PR #404

This document describes the requirements for the improvement to the existing InvalidTagCheck.

Description

This improvement will check specific tag values that they are lowercase aphanumeric with no spaces.
The following tags will be checked:

• abutters, access, admin_level, aerialway, aeroway, amenity,
• barrier, bicycle, boat, border_type, boundary, bridge, building, construction,
• covered, craft, crossing, cutting,
• disused, drive_in, drive_through,
• electrified, embankment, emergency,
• fenced, foot, ford,
• geological, goods,
• hgv, highway, historic,
• internet_access,
• landuse, lanes, leisure,
• man_made, military, mooring, motorboat, mountain_pass, natural, noexit,
• office,
• power, public_transport,
• railway, route,
• sac_scale, service, shop, smoothness, sport, surface,
• tactile_paving, toll, tourism, tracktype, traffic_calming, trail_visibility,
• tunnel,
• usage,
• vehicle,
• wall, waterway, wheelchair, wood

With exceptions:

Further Investigation

There is a list of tags that should be checked for these incorrect tag values in the Osmose analyzer. There could be more tags that would need to be included in this list. Same with an exception list.

Supported Countries

This check will be valid in all countries.

References

• https://github.com/osm-fr/osmose-backend/blob/master/plugins/TagFix_BadValue.py
• https://wiki.openstreetmap.org/wiki/Osmose/issues#3040

Which Atlas check is the fix suggestion related to?

AreasWithHighwayTagCheck
Description: https://github.com/osmlab/atlas-checks/blob/dev/docs/checks/areasWithHighwayTagCheck.md
Script: https://github.com/osmlab/atlas-checks/blob/dev/src/main/java/org/openstreetmap/atlas/checks/validation/areas/AreasWithHighwayTagCheck.java

Describe more details of suggested fix(es)

Suggested Fix 1:

• Type for fixing: Tag fix

• Operation: Delete

• Suggested Action: Remove area=yes tag on the flagged feature(s)

Is there any code enhancement needed if adding the fix suggestion component?

Yes

• When the flagged feature is a relation, the suggested fix shouldn't be applied

I tried to use atlas check on windows 7, debian, ubuntu... but no luck
I don't know if I'm doing something wrong or not
I installed jdk:

c:\Users\admin\atlas-checks>java -version
java version "1.8.0_212"
Java(TM) SE Runtime Environment (build 1.8.0_212-b10)
Java HotSpot(TM) 64-Bit Server VM (build 25.212-b10, mixed mode)

and gradle:

c:\Users\admin\atlas-checks>gradle -v

------------------------------------------------------------
Gradle 5.4.1
------------------------------------------------------------

Build time:   2019-04-26 08:14:42 UTC
Revision:     261d171646b36a6a28d5a19a69676cd098a4c19d

Kotlin:       1.3.21
Groovy:       2.5.4
Ant:          Apache Ant(TM) version 1.9.13 compiled on July 10 2018
JVM:          1.8.0_212 (Oracle Corporation 25.212-b10)
OS:           Windows 7 6.1 amd64

and atlas-checks version 5.0.10
everything is by default even configuration.json

at first I ran this command (cmd as administrator): c:\Users\admin\atlas-checks>gradle run
when it failed I used this: c:\Users\admin\atlas-checks>gradlew run

at it also failed to check
I attached output of gradle --debug run and gradle --stacktrace run , hope it helps

stacktrace.txt
debug.txt

Which Atlas check is the fix suggestion related to?

One-Member Relation Check
Description: https://github.com/osmlab/atlas-checks/blob/dev/docs/checks/oneMemberRelationCheck.md
Script: https://github.com/osmlab/atlas-checks/blob/dev/src/main/java/org/openstreetmap/atlas/checks/validation/relations/OneMemberRelationCheck.java

Describe more details of suggested fix(es)

Suggested Fix 1:

• Type of fixing: Geometry fix

• Operation: Delete

• Suggested Action: Remove the flagged relation

Is there any code enhancement needed if adding the fix suggestion component?

No

Which Atlas check is the fix suggestion related to?

Malformed Roundabout Check

Description: https://github.com/osmlab/atlas-checks/blob/dev/docs/checks/malformedRoundaboutCheck.md
Script: https://github.com/osmlab/atlas-checks/blob/dev/src/main/java/org/openstreetmap/atlas/checks/validation/linear/edges/MalformedRoundaboutCheck.java

Describe more details of suggested fix(es)

Suggested Fix 1:

• Type of fixing: Geometry fix.

• Operation: Modify

• Suggested Action: Correct roundabout direction according to country driving rules

• Restriction: Auto fix should be only applied when flagged error is 1) Wrong-way-roundabouts, OR 2)Multi-directional roundabouts

Is there any code enhancement needed if adding the fix suggestion component?

No

A jump in false positive flags for both UnusualLayerTagsCheck and EdgeCrossingEdgeCheck has been traced back to a change in the LayerTag method that is used in both.
In #62 both checks were altered to use the getTaggedValue method in place of the getTaggedOrImpliedValuemethod that was breaking the checks due to a return type alteration. Unfortunately, this meant the loss of the default value system the checks are dependent on. This has caused false positive rates to jump 40%+ for UnusualLayerTagCheck and 50%+ for EdgeCrossingEdgeCheck, in some countries.

Examples:
UnusualLayerTagCheck:
https://www.openstreetmap.org/way/465528364 is now improperly flagged, because it does not have a layer tag. This would have been avoided before because it would have been assigned a default layer tag.
EdgeCrossingEdge:
https://www.openstreetmap.org/way/118837631 has a layer tag of 1.
https://www.openstreetmap.org/way/118837630 has no layer tag.
These two ways cross, but are improperly flagged because they are on different layers. The layer comparison breaks because the second way (with no layer tag) is no longer assigned a default for the comparison.

Water Way Check
Description: https://github.com/tsmock/atlas-checks/blob/dev/docs/checks/waterWayChecks.md
Code: https://github.com/osmlab/atlas-checks/blob/dev/src/main/java/org/openstreetmap/atlas/checks/validation/areas/WaterAreaCheck.java

Describe more details of suggested fix(es)

Suggested Fix 1:
Type of fixing: Way fix
Operation: Modify
Suggested Action: reverse the way direction

Is there any code enhancement needed if adding the fix suggestion component?

No

Description
This checks for ways that were done crudely, there is a discrepancy between the drawing and the real way especially in the curve. Roads are expected to be smooth and consistent, large changes in directions are suspect of poor drawing. Fixing these visually improves the map.

Requirements

• Is an Edge
• Has a highway tag that is car navigable
• Edge has more than one segment

Use Cases
Case 1: False Positive (US)

• This gets flagged due to the sharp angle in the edge, this edge is the same road throughout and matches the imagery
• https://www.openstreetmap.org/way/608161473

Case 2: True Positive (US)

• Curves are not smooth, poorly drawn
• https://www.openstreetmap.org/way/40195903

Supported regions
All Countries

What's not supported (optional):

References
https://wiki.openstreetmap.org/wiki/Osmose/issues#1190

Is your feature request related to a problem? Please describe.

• Update the CheckFlag class to optionally include FeatureChanges.
• Add FeatureChange descriptions to CheckFlag geojson

4070 ConstructionCheck - Requirements

Developer: Brian Jorgenson
Analyst(s): [Name]
Date: 08/31/2020
PR: #358

This document describes the requirements for the new ConstructionCheck.

Description

This check checks if a features construction tag has not been updated for more than 2 years or the opening date has been exceeded.

Requirements

• Contains a highway, landuse, or building tag with the value of “construction”.
• Contains a tag that is either: “construction” or starts with “construction:” but is not “construction:date”

Use Cases

Case 1: [TP]

• This way has had the construction tag for more than 2 years.
• https://www.openstreetmap.org/way/511874260
  

Case 2: [TP]

• The opening_date has been passed.
• https://www.openstreetmap.org/way/722090480
  

Case 3: [FP]

• The opening_date has not been passed.
• https://www.openstreetmap.org/way/717763385
  

Further Investigation

It is expected that people will have inserted dates that cannot be parsed, we could still flag these cases but with a different instruction (to fix the date). The portion of the osmose check that validates for tag usage could be implemented using #334

Supported Countries

All countries.

References

• https://wiki.openstreetmap.org/wiki/Key:construction
• https://github.com/osm-fr/osmose-backend/blob/master/plugins/Construction.py
• https://github.com/osm-fr/osmose-backend/blob/master/plugins/Construction2.py
• https://github.com/osm-fr/osmose-backend/blob/master/plugins/Construction2.validator.mapcss
• https://wiki.openstreetmap.org/wiki/Osmose/issues#4070

Which Atlas check is the fix suggestion related to?

Building Road Intersections Check
Description: https://github.com/osmlab/atlas-checks/blob/dev/docs/checks/buildingRoadIntersectionCheck.md
Script: https://github.com/osmlab/atlas-checks/blob/dev/src/main/java/org/openstreetmap/atlas/checks/validation/intersections/BuildingRoadIntersectionCheck.java

Describe more details of suggested fix(es)

Suggested Fix 1:

• Type of fixing: Geometry fix

• Operation: Delete

• Suggested Action: Remove the building that intersect/overlap with a road

Is there any code enhancement needed if adding the fix suggestion component?

No

Hi friends - Might someone have the bandwidth to fill out https://github.com/osmlab/atlas-checks/blob/dev/docs/cluster.md at some point? It would be a nice entry point to this project and to Atlas generally.

Is your feature request related to a problem? Please describe.

• Create a text processing job to convert auto-fix suggestions into OSC change files.

The OSM change file is an accessible XML format that describes differences between OSM elements.
Supported operations: create, modify, delete

<osmChange version="0.6" generator="acme osm editor"> 
    <modify> 
        <node id="1234" changeset="42" version="2" lat="12.1234567" lon="-8.7654321"> 
            <tag k="amenity" v="school"/> 
        </node> 
    </modify> 
</osmChange>

Description
Extension of the InvalidTagsCheck to look for missing tags in certain tag combinations containing or requiring highway tags, like junction or oneway.

Requirements

1. Check Candidate (example)

• is Edge| Node
• matched a specific TaggableFilter provided for each case

Use Cases

1. highway tag missing on a junction ( junction->*&highway->! )
   https://www.openstreetmap.org/way/802707014

2. highway tag missing on oneway ( oneway->*&highway->! )
   https://www.openstreetmap.org/way/823990367

3. highway tag missing on tracktype ( tracktype->*&highway->!&leisure->!track )
   https://www.openstreetmap.org/way/300713929

4. ref tag missing one emergency access point

5. highway missing footway, path or construction for footway=sidewalk

https://www.openstreetmap.org/way/29408268

6. Motorway without ‘ref’, ‘nat_ref’, ‘int_ref’, ‘noref’ tag
   https://www.openstreetmap.org/way/674134910

Further investigation

Supported regions
All countries

What's not supported (optional):

References
Junction tag usage: https://wiki.openstreetmap.org/wiki/Key:junction
Oneway tag usage: https://wiki.openstreetmap.org/wiki/Key:oneway
Emergency access point: https://wiki.openstreetmap.org/wiki/Tag:highway%3Demergency_access_point
Tracktype tag usage: https://wiki.openstreetmap.org/wiki/Key:tracktype
Footway tag usage: https://wiki.openstreetmap.org/wiki/Key:footway

Is your feature request related to a problem? Please describe.

• Update the MapRouletteUpload command to convert auto-fix suggestions into Cooperative Challenges

Cooperative challenges bring in-progress work to a MapRoulette task for completion or verification. Tag changes can be committed directly to OSM from within MapRoulette.

Supported operations: create, modify, delete tags

{
	"cooperativeWork": {
		"meta": {
			"version": 2,
			"type": 1
		},
		"operations": [{
			"operationType": "modifyElement",
			"data": {
				"id": "way/792729120",
				"operations": [{
					"operation": "unSetTag"
				}]
			}
		}]
	}
}

Description
This is largely a migration of Osmose 1070/1220 (waterway overlaps, waterway intersecting waterway without junction, unconnected waterway, and closed waterway).

Requirements

• Is an Edge or a Line (logic should use LineItem where ever possible), since waterways may become an Edge in the future (specifically navigable waterways, so rivers, not small streams), and has valid waterway water values.

Use Cases
This section summarizes the various use cases for this check and provides potential enhancement suggestions if needed. The uses cases should act as a test in a way, such that when the analysis/enhancement is completed, these types of use cases should be found or eliminated.

For each use case, please add a screenshot of the feature & openstreetmap.org link (or other sources). If necessary, edit the screenshot to better illustrate the use case.

Example:

Case 1: Sinkhole area (Colorado, US)

• This should not be flagged, since sinkholes act as an exit for waterways.
• https://www.openstreetmap.org/way/538940188
  

Case 2: Sinkhole point (Utah, US)

• This should not be flagged, since sinkholes act as an exit for waterways. Note that this is apparently not a sinkhole (see the description tag, but that is a separate issue).
• https://www.openstreetmap.org/node/7704038746
  

Case 3: Closed waterway (Colorado, US)

• This should be flagged. It looks like it should be natural=water + water=canal instead of waterway=ditch (it looks more like a canal than a ditch).
• https://www.openstreetmap.org/way/46115766
  

Case 4: Waterway ending in an ocean (Florida, US)

• This should not be flagged, since water ending inside an ocean has a sink
• https://www.openstreetmap.org/way/556331627 (Coastline)
• https://www.openstreetmap.org/way/163762083#map=15/29.2075/-89.2731 (River -- waterway)
  

Case 5: Waterway crossing waterway (Colorado, US)

• This should be flagged, if the layer tags are the same. This example has a duplicate node at the crossing location as well, but that should not be necessary.
• https://www.openstreetmap.org/way/40979547
• https://www.openstreetmap.org/way/41180223
• https://www.openstreetmap.org/way/40950607
• https://www.openstreetmap.org/way/41068197
  

• Case 6: Deadend waterway (Colorado, US)*

• This should be flagged. Waterways must have a sink. Multiple waterways may deadend into each other (so converge into a dead end). For the purposes of a navigable network, a waterway ending on a water area is considered a dead end (see linked way).
• https://www.openstreetmap.org/way/41207956
  

• Case 7: Tidal Channel (Belize)*

• This should not be flagged as missing a sink. It may be flagged for other reasons, such as overlapping/intersecting with another waterway.
• https://www.openstreetmap.org/way/796347512
  

Further investigation
A sample region needs to be tested to see what the approximate false positive rate is. Belize had 311 flags for the standard waterway checks.

Supported regions
All countries

What's not supported (optional):
This check is not currently doing area checks (so riverbank without river, crossing waterway areas, since the crossing waterway areas currently has a bug whereby two areas sharing a point is considered an intersection).

References

• OSM Wiki Waterways: https://wiki.openstreetmap.org/wiki/Waterways
• OSM Wiki Riverbank: https://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
• Waterway way checks: https://github.com/taylorsmock/atlas-checks/tree/feature/waterway-check

Developers: Alex Iannicelli
Analyst: Yunzhi Lin
Date: 09/22/2020

Description
Detect and flag objects that should not be tagged with the railway=level_crossing tag. Create missing railway/highway intersections. Tag railway/highway intersections that are not properly tagged as railway=level_crossing.

Requirements
There are three railway intersection scenarios that this check looks for:

1. railway intersection node is missing.

• Is a Line
• Has railway tag, values include rail, tram, disused, preserved
• Intersects with a car navigable highway on the same layer
• No node exists at intersection

2. railway intersection node exists, but railway=level_crossing tag is missing on the intersection node.

• Is an Line
• Has railway tag, values include rail, tram, disused, preserved
• Intersects with a car navigable highway on the same layer
• node exists at location, but railway tag doesn't exist or is not equal to level_crossing

3. a railway=level_crossing tag exists,
   a) and this tag is on a node, but is lacking of either highway or railway going through the node (osmose 7090)
   • Is an Node or a Point
   • Has railway tag, values include level_crossing
   • Count number of Edge with highway tag that is car navigable.
   • Count number of Line with railway tag values including rail, tram, disused, or preserved
   • Either Edge or Line count is 0.
     b) but not on a node, instead, on the related way features (osmose 9015)
   • Is not an Node or a Point
   • Has railway tag, values include level_crossing

Use Cases
Case 1: Bridge over Railway on same layer.

• Highway bridge goes over Railway, but layer missing on both railway and highway. The bridge should have a layer=1 tag
• https://www.openstreetmap.org/way/80459517
  

Case 2: Railway crosses a highway with no level_crossing tag

• The intersection node (OSM ID: 273135212) is missing a railway=level_crossing tag. Add the appropriate tag to the node.
• https://www.openstreetmap.org/node/273135212
  

*Case 3: Railway crosses highway with no intersection node.

• The intersection of railway (OSM ID: 550221984) and highway (OSM ID: 637449204) is missing an intersection node. Add an appropriate intersection node.
• https://www.openstreetmap.org/way/550221984 and https://www.openstreetmap.org/way/637449204 overlap without an intersection node.
  

*Case 4: Node is not a Level_crossing

• The node (OSM ID: 4147274783) is tagged with railway=level_crossing but is not the intersection of a railway and highway. Remove tag or add missing way.
• https://www.openstreetmap.org/node/4147274783
  

*Case 5: Non-node tagged with railway=level_crossing

• Unable to find non-node features tagged with railway=level_crossing in OSM maps. Tested this with unit tests.

Further investigation

• The inclusion of railway=disused is a bit wishy washy. This type of railway are not commuter railways, but the existence of a railway crossing on a highway, even if it is no longer in use, seems to make sense even for these two types of railways. When intersections are reconstructed so that the old rails are removed then it makes sense to change the railway tag to railway=abandoned.
• There are some railways that traverse along the same nodes as a highway. So on the map it looks like the train and the highway are on the same line, but actually there are two ways that include the same bunch of nodes. So that means that a check of each of the nodes that are included in both ways flags all the nodes as needing a “level-crossing” but actually it isn’t a crossing. This test will flag these "intersections" and it is best practice that the user separate that railway and highway so they are next to each other. Then we would only have to deal with the places were the rail crosses the highway at the beginning or end.

Supported regions
All countries.

What's not supported (optional):

• The railway=preserved tag is used in some areas and is “not liked by the OSM community”. The Wiki states that the community “suggest to use railway:preserved (https://wiki.openstreetmap.org/wiki/Key:railway:preserved)=yes instead“. So we could add another check for this failure case. I would suggest adding another atlas check to specifically check for any railroads with railway=preserved and switch them to railway:preserved=yes and railway=rail. For this specific check I will add this railway into the acceptable set of railways that we expect to see a level_crossing at so that they are treated like normal railway=rail ways.

References
https://wiki.openstreetmap.org/wiki/Tag:railway%3Dlevel_crossing
https://wiki.openstreetmap.org/wiki/Key:railway
https://wiki.openstreetmap.org/wiki/Key:highway
https://wiki.openstreetmap.org/wiki/Osmose/issues#9015
https://wiki.openstreetmap.org/wiki/Osmose/issues#7090

Describe the bug
Malformed roundabout condition "Car navigable ways inside roundabout" flagging following false positive cases:

1. Roundabout doesnt contain any highway=navigable road.
2. Roundabout contains highway=navigable but its an Area
3. Roundabout spatially intersects with highway=navigable but on different layer.

To Reproduce
Run MalformedRoundAboutCheck against following cases:

1. no navigable rd: https://www.openstreetmap.org/way/693509232
2. navigable but area: https://www.openstreetmap.org/way/792091627
3. multilayer: https://www.openstreetmap.org/way/383475883

Expected behavior
Do not flag roundabout

Screenshots & Stack traces

Which Atlas check is the fix suggestion related to?

Connectivity Check
Description: This check identifies nodes that should be connected to nearby nodes or edges
Script: https://github.com/osmlab/atlas-checks/blob/e36a240f37344c99a25b00eb42c8e1b77b228a88/src/main/java/org/openstreetmap/atlas/checks/validation/points/ConnectivityCheck.java

Describe more details of suggested fix(es)

Suggested Fix 1:

• Type of fixing: Geometry fix

• Operation: Modify

• Suggested Action: connect the node to proper nearest node or edge

Is there any code enhancement needed if adding the fix suggestion component?

No