This was taking a lot of time at app startup.
Instad now we resolve and index only the include and exclude parts.
We can still determine the valid locationSets at runtime in `locationSetsAt()`
by checking the `_locationIncludedIn` and `_locationExcludedIn` caches.
This also upgrades the locationManger to an ES6 class.
This also includes some hacky code in nsi.js so that the NSI will continue to work.
The NSI matcher can build its own location index, but it doesn't need to do this.
We monkeypatch a few of the matcher collections to work with the new LocationManager.
(fixes: https://github.com/osmlab/name-suggestion-index/issues/5693)
Previously the code would accept the first useful match, however this match
might be an "alternate" match. Now we keep iterating until we find a "primary"
match.
This bug could cause the validator to suggest upgrading well-tagged features to
a less wanted feature type. For example a "Tesla Supercharger" would flip to
a "Tesla Destination Charger" if it had "Tesla" anywhere in its list of tags
(because `short_name=Tesla` is an "alternate" match for both destination
chargers and super chargers)
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.
- Actually bail out properly if namelike values contain semicolon ';'
- Prioritize the canonical tags like `brand:wikidata`, `operator:wikidata`
- Don't insert a name into 'alternate' set if it's already in 'primary' set
Bryan Housel