Add filters for data to make it easier to edit dense multilevel areas

[mkv123]

In areas where features are in multiple levels, it would make editing much easier and clearer if there was a way of filtering shown features.

[tmcw]

Related / possibly duplicate: #1299

[bhousel]

@jfirebaugh I have some time to hack on this today.. Any thoughts on what I did so far?

Obviously I'm just displaying the object keys of the thing right now, will replace with t() strings and tooltips later.

[jfirebaugh]

Yeah, this would definitely be useful in dense areas and is worth spending some time on. Some thoughts:

How are features categorized? This should be tied into the preset system somehow and be flexible enough to support a "Water" layer that includes both waterway=* and natural=water, for example.

Instead of adding another hamburger menu, should we include this in a redesigned "Layers" panel that includes both imagery and data? (cc @samanpwbb, @peterqliu)

The status bar is a good idea. Are there other ways we can preempt concerns that this might encourage edits that accidentally break geometry that is shared with a hidden layer? One thing I thought of was to make "hidden" layers not fully hidden but wireframes (1px semitransparent lines) instead.

[bhousel]

How are features categorized? This should be tied into the preset system somehow and be flexible enough to support a "Water" layer that includes both waterway=* and natural=water, for example.

My plan was to implement each featureset as a filter function that operates on entities, then I think these could be passed as a filter function in the d3 rendering code. So a filter to remove "Water" might look like:
function(d) { return !(d.tags.waterway || d.tags.natural === 'water'); }
(I'm expecting it to be more complicated than that).
But this is nice because say you have some kind of mixed up feature, like Abandoned Canal, it would be hidden by either the "water" filter or the "pastfuture" filter. This is also why I want to keep it separate from the presets, because there will be weird things in osm that we would never make presets for.

Instead of adding another hamburger menu, should we include this in a redesigned "Layers" panel that includes both imagery and data?

I thought about this too, but the Background pane is already pretty crowded. And it will get even more crowded if we do #1141 (WMS support), but that's a good thing if there are better background imagery sources locked up in WMS servers (I know where I live that is the case). I would make the Map Features icon maybe more like stacked lines instead of reusing the existing hamburger. Or I guess it could work if the pane opens and there are separate ui tabs for background and foreground features.

Are there other ways we can preempt concerns that this might encourage edits that accidentally break geometry that is shared with a hidden layer?

I was planning to disable actions involving hidden features. e.g. if a path crosses a road, and the path is hidden, obviously the user shouldn't delete that vertex. Maybe add an isHidden function to Entity, so the actions code can check this easily. I think the best place for this is in the actions themselves maybe in disabled, but not sure.

[jfirebaugh]

Addressed by feature filtering (#2357).