Previously it was including a lot of data about the edge, and a very specific
crossing location. This meant that any tiny perturbation in the crossing ways
would generate a new issue hash, effectively "fixing" the old crossing issue and
creating a new one.
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
Before it was not actually checking that the osmvalue was in the vmap,
so we were testing a bunch of pairs like `highway/crossing` and
`highway/residential` that would never match a NSI category.
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).
On a slow machine, the preset list is painfully slow to search, as it
rerenders the list on every keystroke, which takes several hundred
milliseconds. By debouncing this, it is able to keep up.
Performance analysis:
Before: Typing the word 'stream' results in a 2.5s frame according to
Chrome's profiler. Each input event takes between 300 and 600 ms to run.
After: Typing the word 'stream' results in three 300ms frames. The first
and last input events take around 200ms, while the four in the middle
are ignored by the debouncer.
Bryan Housel