Building nodes are invisible

[pnorman]

Nodes with building=* appear to be invisible. See for example http://www.openstreetmap.org/edit?editor=id#map=18/32.30267/36.31946

cc @mikelmaron

[hajo4]

It is hard to see what is on the ground at that spot.
Also, whole buildings tagged as kitchen or toilet ?

I made a few new things at http://www.openstreetmap.org/browse/way/248817177
There, the buildings look pretty normal/visible to me.

[pnorman]

That's a building=yes way that you created, not a node.

[jfirebaugh]

What's happening here is that iD has a threshold for rendering points -- if there are more than 100 points (nodes not belonging to a way) visible, they aren't rendered. This is both for performance and to avoid covering the screen with markers at e.g. z16. If you zoom in a couple levels, the points will be rendered.

This has worked pretty well so far -- as far as I know, this is the first time anyone has noticed this behavior -- but I'm open to ideas. As a start we can bump the threshold up. 100 is pretty low.

[hajo4]

Maybe we can also exclude from that count all points
that will will be rendered as "simple icons", e.g. trees.

[pnorman]

What's happening here is that iD has a threshold for rendering points -- if there are more than 100 points (nodes not belonging to a way) visible, they aren't rendered. This is both for performance and to avoid covering the screen with markers at e.g. z16. If you zoom in a couple levels, the points will be rendered.

I have to zoom in to z21 to see them. I would suggest a) increasing the point threshold and b) showing all points when at or past z18

[bhousel]

@jfirebaugh: Thoughts on something like this? I want to implement density dependent rendering. I'm thinking of assigning some objects a rendering penalty (sidewalks, POIs, buildings) and culling some features away if the viewport is too dense. But if we're going to do this, it's important to let the user know what's going on.

[jfirebaugh]

Well, we've been reluctant to selectively hide features because it introduces the possibility of changing a visible geometry without realizing that it also affects connected (or otherwise related, e.g. parallel) geometry that is hidden. (POIs are a bit of a special case because by definition they are not connected to other features.)

Showing a message for the existing hiding behavior seems like a good idea though.

[pnorman]

(POIs are a bit of a special case because by definition they are not connected to other features.)

Are you talking about POIs in general, or some subset of POIs? See 773141803 for an example of a POI connected to another feature.

[jfirebaugh]

Yeah, I mean what iD calls "Points" -- tagged nodes that aren't members of any way. That's the only type of feature that it currently hides selectively.

[bhousel]

I'd like to put together a PR that addresses this issue and also #1871, #1299, #1520. It would be a sidepanel with some controls to allow the user to disable some features, maybe also using the bar in the screenshot above to remind them when features are disabled.

#1520 scares me because I don't really want to mess with editoff/on while a user is just panning around at one zoom level. Imagine they start drawing a feature and then happen to move to a place that is too dense and editoff happens - bad idea.

[jfirebaugh]

Addressed by feature filtering (#2357).

[pnorman]

Addressed by feature filtering (#2357).

Were defaults for point filtering adjusted at the same time?

[bhousel]

Yes, the threshold is bumped up a little. It's viewport dependent now too, so a bigger screen will show more points.

I set it to 250 points per 1000x1000 of viewport. Which is totally arbitrary but felt ok in my testing.

[pnorman]

We should probably have no threshold for z18+, as at some point you want to show any points or the user will never realize they are there.

[bhousel]

We show the user a message now if anything is hidden from them.