re: the fix for #8632 - we can't actually skip validation on these.
The better solution is to move the check to getIssues() so the user isn't
credited for causing the issues unless it's something they actually touched
This fixes a situation where several entities in the queue are involved in a
disconnected crossing, and the first one detects the disconnection, but a
later one clears out that first detection from the cache. Now we clear
caches one time before starting the validation work.
This will catch the situation where an edit or undo affects something related without
actually touching the item - for example an undo can cause a connected way to disconnect
from the main graph.
This can occur if there are several ways disconnected from the graph and
the user fixes these, but then partially undoes their fixes.
The current diff might not contain the entity that fixed the issue
(reconnected the disconnected graph), but they did fix the issue elsewhere.
(closes#8632)
For example, a user can undo some work and an issue will still present in the
head graph, but we don't want to credit the user for causing that issue.
From what I can tell, this code is nearly the same as what the "complete"
difference already gives us - combined nodes from both previous and current,
multipolygon members, parents of nodes/relations
The previous code was grabbing _all_ parent relations, which is too much.
For example: if a user changed a road, the validator was treating it like
the user had changed bus and highway routes along that road.
(closes#8613)
(helps a lot #8612)
The "center" of the issue might be a spot of map that doesn't contain the relation.
This code chooses a piece of the relation that has been downloaded and focuses on that.
Filtering returns a new array, which was clobbering the "provisional" flag.
This was causing provisionally results to not be reprocessed later,
which meant that certain "outdated_tags" results would not be in the baseCache.
(cache of issues _before_ user edits).
This involves a few things to make the validator less weird
- _headGraph shouldn't be allowed to change while validation is happening..
- So we don't allow that to happen anymore, and keep track of _headPromise and _headIsCurrent
- If head graph falls behind, kick off another validation to catch it up
- Separate head and base work queues, so we aren't waiting for the base entities to validate
before providing feedback to the user about what they are editing
(the base queue can get quite large around metropolitan areas)
- implements a validation work queue, jobs are run during browser idle callbacks
- when merging base entities, don't run validations 2x on both base and head graphs (this was wasteful)
- keep track of resolved issues in a separate set (it's not a simple compare of base/head anymore)
this happens after validation queue is empty and avoids race conditions and inaccurate resolved counts
I got this to happen after some issues had been detected on the live map,
then starting the intro walkthrough (which replaces the graph).
No time now to dig into the root cause, but this might make the problem go
away so the tutorial doesn't get too weird.
Only include issues created by the user in the "warnings" changeset tags
Include counts of issues resolved by the user in the changeset tags (close#6459)
Don't include "fixme" issue counts in "warnings" changeset tags since they're not created by the user (close#6658)
Don't cache crossing ways issues at the rule level
Use spherical distances for very close nodes validation
Don't flag very close nodes from different ways
Don't flag very close nodes if both have interesting tags
Update very close nodes validation reference string
