Hide artwork with location=underground

[bgo-eiu]

Expected behavior

An artwork object mapped as a node with the location=underground tag hidden from view rather than crowding above ground features.

Actual behavior

Artwork is visible the same way as it would be if it were above ground regardless of the location=underground tag.

Links and screenshots illustrating the problem

https://www.openstreetmap.org/node/9686988569

This artwork is located on the back wall of an underground subway station entrance. (This is the deepest station in the network, so the entrance extends as a few levels of escalator/stairs before getting to the platform.)

[imagico]

Related to #552, #3506.

I am skeptical of this idea. IMO it only makes sense if you consider the purpose of rendering artwork to render it as a landmark. As such an underground artwork is not visible - hence there is no point in rendering it.

If however you consider rendering of artwork as a POI or an object of touristic interest then an underground artwork is not any less meaningful than one above ground.

A good solution would possibly be to develop a POI symbol addition/variation that can be applied to any/most kinds of symbols and recognizably indicates that this feature is an underground feature. That would add valuable information to the map user without universally making assumptions on what is and what is not of interest for the map user.

[bgo-eiu]

Well, the artwork would be of interest to people using the subway station. I think the context of why an artwork would be underground is what makes it confusing it to render - an underground artwork would most likely be in a subway station, a cave, or an underground parking lot. As far as I know none of those underground features are themselves rendered so the fact the artwork is connected to one of those underground features gets lost. This example in the screenshot is less confusing because it is under one of the entrances, but there are unmapped artworks in that station closer to the platform under the road intersection - rendering an artwork in the middle of the street is potentially confusing.

When I was searching for related issues, the decision was also made not to render indoor artworks like those at the Louvre, so I think it makes sense in context of the expected behavior in similar situations.

[Adamant36]

I've gone back and forth about this myself in relation to graffiti under bridges in my local area. On the one hand the rendering definitely looks weird, but on the other they are important local landmarks. I'm not sure what a good solution would be either. While @imagico suggestion makes sense, there's zero chance of anyone developing such a rendering scheme or it being implemented if they did, and in the meantime the status quo obviously doesn't work. I don't think there could be a reasonable way to render underground artwork that is in the middle of the street either, but again, not rendering underground artwork (in the street or not) just seems like a bad solution.

[bgo-eiu]

Under bridges is a different case I think because it is still accessible from the ground level - with features in subway stations, the only way to get to them is through other features which are never rendered. If you have to open or enter some kind of structure to see it, I don't see why it couldn't be treated like any other indoor feature - the station itself is the landmark/point of interest, and the artwork is part of it, in the same way a museum or a library is a landmark

[Adamant36]

I get where your coming from, but I don't necessarily agree with you. There's plenty of cases where between a bridge and some graffiti under it the bridge is the landmark/point of interest. Not the graffiti. There's also a ton of graffiti in tunnels. One of the places in my local area that I'm talking about is like a 150 foot tunnel/drainage ditch with graffiti in it. The fact that you can get to both by way of other features that are rendered is pretty ill relevant. There's lots of things that are rendered that can't be gotten to by other through other rendered features, same goes for the opposite. It would be weird if that was a factor in what to render or not.

[bgo-eiu]

Perhaps this is a case of something that could be rendered on the basis of how crowded it makes the map then necessarily having a blank it rule about underground artwork/POIs. Some kind of prioritization scheme in the same way labels get prioritized, or things only show at certain zoom levels basically.

I think it would make sense for example, if there are artworks in very close proximity on different levels/layers, they wouldn't show or at least collapse to a smaller icon (like the little waste basket icons, just a picture frame silhouette or something). That way they don't overcrowd things to a point where it defeats the purpose of seeing them. If there is say an artwork that is underground to a roadway, maybe only show it if the position is out of the way of where the roadway line itself is drawn. I don't think it would be as confusing to see features like that around the periphery of a road, but on top makes it seem like something you are going to see while driving on the road.

Honestly, the more I think of it, even just smaller/simpler icons is a solution I think I would be happier with. If graffiti and murals were shown just as little picture frame silhouettes rather than looking the same as an outdoor sculpture it would be a lot more obvious why that icon is there. The iD editor already does this with its iconography. As it is right now in the screen shot I showed, it is conceivable that someone could think there is some kind of sculpture to look at either behind the entrance or under it, when really there is just a mural on the wall. That kind of artwork is always going to be on the wall of something, so just a different icon for it would make it more clear that its related to the building/structure rather than a free-standing object.

[daganzdaanda]

I agree that this rendering can lead to some real confusion. Of course, it does not only concern artworks - most POIs with an icon will be rendering the same with "location=underground" or without. We only seem to have a few exceptions for underground parking and underground malls (or does that code do something different?)
Underground shops are rendered with icons, as are amenities:
https://www.openstreetmap.org/way/313420257
https://www.openstreetmap.org/node/294197623

We could drop rendering for everything that is underground, since it can't be seen from the ground. But, what about things on level=1 or higher in buildings? There are lots of examples of well mapped shopping centers that just look awfully confusing on the map, because all of the icons from all of the floors are visible.

For a perfect solution we would need a style that can switch between levels. We won't get that anytime soon.
With what we have, I think we should not go the radical route and make a clean map for only the ground level. That would be poison for the mapper's feedback.
So we should try and make the confusion a little more bearable by having some difference in rendering for POIs according to their location.

rendered on the basis of how crowded it makes the map

I think that would be awesome, but it seems it is technically very hard, see also #1957 and the issues linked there. I really hope we can get to use density-based rendering sometime!

smaller/simpler icons

Most of our icons are very small already in pixels, and will not shrink gracefully, I believe. Using new, smaller icons might be confusing, too. People who aren't mappers probably can only guess what many of the icons mean, adding even more versions will make that even worse.

That said, one easy step could be to drop any name rendering for POIs that are not on the ground, leaving only the usual icon.

If we want to go further we could maybe use dots instead of icons. That would be fine for shops, since they are already known. Using brown dots for amenities is not done yet, I think, and could lead to new confusion, especially if artworks were also to be turned into brown dots.

Another possibility would be to use the regular icons but with a lighter and desaturated colour. Being less visible on most backgrounds might reduce the optical crowding. Of course, adding more colours in the already quite packed pallette could lead to some new problems. To get around that, we could use only a single colour (grey?) for everything that we want to mark as on another level, be it icons or dots.

[Adamant36]

We could drop rendering for everything that is underground, since it can't be seen from the ground. But, what about things on level=1 or higher in buildings? There are lots of examples of well mapped shopping centers that just look awfully confusing on the map, because all of the icons from all of the floors are visible.

I don't know if it's along the lines of what your thinking, but #3364 deals specifically with indoor rendering. Although it was closed because rendering indoor objects would clutter the map to much. The solution, at least for this issue, might be to tag the artwork as being indoor so it doesn't render though. I'm not usually a fan of tagging for/not for the rendering myself, but I don't think it's technically wrong here.

That said, one easy step could be to drop any name rendering for POIs that are not on the ground, leaving only the usual icon.

Rendering the names of POIs is extremely important for reviewing if the name field is being used properly or not. I don't think it would be intuitive to have the name of a business render if it's on the ground versus not anyway. People would just think it's a bug or something. Same goes for dot rendering. There's zero way for someone instinctively know the dot means "below ground" just by looking at the map. Dots aren't currently used in that way either.

Another possibility would be to use the regular icons but with a lighter and desaturated colour.

There's an issue related to moving away from using desaturation as a rendering method. I can't find it right now, but if I'm remembering correctly the tl dr is that it's not a good way to render things.