Kyℓe Hensel

iD already supports this for well-known brands: if you want to add a missing brand, you'll need to raise an issue at [osmlab/name-suggestion-index](https://github.com/osmlab/name-suggestion-index)

> By the way, for minimal plugin implementation, access to a variable with the iD context will be sufficient. This is done in one line of code. Lets discuss hacky...

see also: https://github.com/ideditor/schema-builder/issues/35

> Is it possible to solve this by preserving the `ParenthesizedExpression` around it? I couldn't find an idiomatic solution using this approach, some more pointers would be appreciated

Coming from #1392 - I realise this issue is focused on browser extensions, but if you just want access to `coreContext` for spontaneous debugging, [`queryObjects(Rapid.Context)`](https://developer.chrome.com/docs/devtools/console/utilities#queryObjects-function) works in RapiD, but not...

@UKChris-osm do you have an opinion about how the overpass query should be constructed for features with both `brand` and `operator`? should [the green styling](https://overpass-turbo.eu/s/2fR5) require both `brand[:*]` and `operator[:*]`...

okay, updated. Here's [an example](https://overpass-turbo.eu/s/2g9k) of the query that's generated for presets with both `brand[:*]` and `operator[:*]`

the code already filters out tags with less than 2500 uses, but there is an exception for low-use tags that have a wiki page. Which is why `hashtags` appears. https://github.com/openstreetmap/iD/blob/50250f23d9fa8b3c53c84bfba55b77b4f282ad50/modules/services/taginfo.js#L79...

> More specific to this case, I don't understand why it isn't filtered out based on the information in iDs presets These suggestions come purely from taginfo, presets are not...

At the moment, no, it just stays off. Do you think users would expect it to automatiaclly re-enable?