Different icon for benches with backrest

[Tomasz-W]

Due to Taginfo, out of 872k benches, 294k of them are tagged with backrest=yes. https://taginfo.openstreetmap.org/tags/amenity=bench#overview

As sitting on non-backrest benches is not comfortable, I think there should be 2 different icons for 2 different bench types.

• (current amenity=bench icon)
• (amenity=bench + backrest=yes icon proposal)

[matkoniecz]

I am strongly against this idea. It is not important info, it is not relevant for orientation, it is too detailed for a general purpose map.

[eehpcm]

Sounds good to me.

[ghost]

Nice

[matkoniecz]

See https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md#main-goals

The aim is not however to show all or even most of the OSM data.

Unfortunately showing everything is not feasible.

[eehpcm]

Unfortunately showing everything is not feasible.

Indeed. Last week I mapped a public space which had two picnic tables. Sadly, they are too close together and so only one is shown by the renderer. I can live with that. I understand. There's not enough room to fit in two symbols that close together. I can wish for higher zoom levels so they can be shown, but I don't expect that to happen (my wish for lots of money didn't come true, either, but that doesn't stop me wishing).

This is different. Icons are standard sizes and I think the proposed bench-with-back icon fit into that standard size. If I'm wrong and it was a little larger, it could be redrawn to fit. So if it's feasible to fit a bench-without-back icon it's feasible to fit a bench-with-back icon. The hard part (once a symbol that fits the standard icon size has been created) is modifying the carto code to choose one symbol or the other depending on whether or not it has backrest=yes.

I can understand "it's too much work when we have so many other issues to deal with" but not "showing everything is not feasible" when in this case showing it is feasible. Nor can I understand "it's too much detail" when, for some people, it may be an important consideration.

Just my opinion. You have the final say.

[dieterdreist]

FWIW, while i agree this level of detail is not something I'd usually expect from a general map, I believe this could still have been merged because it clearly is a feature our mappers are interested in. There are 356.735 of this right now, all of them being either "yes" (83%) or "no" (17%) (with very few other tags like "partial" (17), "Banco" (5), "Bench" (4), "broken" (4) and some typos of "yes"). Compared to 876 820 amenity=bench, almost every second bench has this attribute. It could be one of the examples where our data is different to what commercial map providers deliver, because we have a bottom up approach and map what the mappers are interested in.

[kocio-pl]

It's interesting to me to hear what it means "too much". As long as we can reasonably easy (design is simple, it's not adding clutter and not eating our resources) show something very popular, we should do it IMO.

I believe vector styles will help to choose the lighter or richer style, and even personalize it, and I hope this will make such discussions moot eventually.

[matkoniecz]

Compared to 876 820 amenity=bench, almost every second bench has this attribute.

Are you sure that it is not result of a large import?

Also, I mapped some backrests with StreetComplete, it does not mean that I think that this data should appear on a general purpose map.

[dieterdreist]

2018-04-30 15:39 GMT+02:00 Mateusz Konieczny notifications@github.com:

Compared to 876 820 amenity=bench, almost every second bench has this attribute.

Are you sure that it is not result of a large import?

yes, completely sure. What makes you think we could have half of our benches imported? See this graph from taghistory.raifer.tech:

[kocio-pl]

See this graph from taghistory.raifer.tech:

The graph is missing.

[dieterdreist]

maybe because it was an svg here is a png

[Tomasz-W]

@matkoniecz As there are people people interested in this feature and we don't have test renderings yet, please re-open this issue. Closing it that early was unfair to another users.

[Adamant36]

@kocio-pl, any chance of reopening this for the reasons @Tomasz-W gave? Id like to see backrests rendered myself.

[kocio-pl]

OK, but reopening won't change too much, the most important thing is having discussion and new arguments or decisions.

[eehpcm]

@kocio-pl

the most important thing is having discussion and new arguments

OK. Not "all-new" but some new and some rehashing...

1. For some of us, this is an important detail. If you have back problems, the presence or absence of a back rest determines whether or not the bench is usable. Perhaps it's more psychological than physical (at least in my case) but a bench without a backrest gives me back pain after a few minutes.

2. The clutter issue doesn't apply. If there's room to render a bench without a rest there's room to render a bench with a rest. An area dense with detail may prevent a bench being rendered at all, but if a bench can be rendered a bench with a backrest can be rendered (assuming one can be drawn at the same size of icon).

3. As I see it (from my Dunning-Kruger understanding) one possible issue is that adding extra code to handle the two cases makes the rendering process hit a brick wall. As I understand it, even minor additions of conditionals can result in major increases in rendering time (by that I mean all stages involved in transforming the raw data into tiles). We won't know for sure unless somebody tries it.

4. The only other major possible problem is that there is too large a backlog of more important things to do. But importance is determined, in part, by how much demand there is for a particular feature.

5) One can spend some time adding a bench with a backrest or one can spend some time defending why benches with backrests will not be added every time the issue crops up.

[Tomasz-W]

Pixel aligned icon proposals:

1) 2)

Gist link: https://gist.github.com/Tomasz-W/5703292edb2d8b09aab74291636faaf2

If someone is going to make a test renderings, please remember about https://github.com/gravitystorm/openstreetmap-carto/issues/3326

[sommerluk]

I share the concerns of @matkoniecz

Further concerns are:

1. The proposed icon is not monochromatic. If full colours are used, this is problematic for a consistent colour usage (and also for automatic colour styling in mss files), and transparencies can be problematic also.

2. The problem is maybe not “too much clutter”, but over-differentiated icons. When we have too many different icons (that are not really very very intuitive), sooner or later people, especially casual users, while fail to recognize the meaning of individual icons. While rendering backrest=no would be in line with the main goal “A rich map”, it would be not in line with the main goal “Legibility and clarity”. I do not think the gain is worth the cost.

3. What makes sure that backrest=no is a sensible default when this tag is missing?

[eehpcm]

@sommerluk

When we have too many different icons (that are not really very very intuitive), sooner or later people, especially casual users, while fail to recognize the meaning of individual icons.

I agree that some of the icons aren't intuitive. But is it really better to use a small disc instead? For everything? Surely not. So who decides "this gets an icon but that doesn't"? Because somebody has to draw the line if we decide not to provide icons for everything. Which ones get an icon and which don't and why? I don't use certain types of facility so I see no need for them to have icons: I've never bought a bicycle so the icon for bike shops is a waste of map space as far as I'm concerned. So which person decides "this is useful and should appear on a map but that isn't useful" and can do so objectively?

It's possible that two or more instances of a non-obvious icon will be present on the map, one with text rendered making it clear what it is and one without text. Users can at least use that to infer what the unlabelled icon is. Whereas if they both have small purple discs there is no clue as to what the unlabelled one is.

Your argument indicates that it's time the map legend included the icons as well as the cartography used for roads. Possibly on a separate button so there are two side panels available, the current one and a map symbols panel.

[sommerluk]

While I agree that bicycle shops are not a high priority, the icon is quite intuitive, will not be confused with other things, and the purple colour makes clear immediately that this is a shop. That’s different from the proposed bench icon.

it's time the map legend included the icons as well as the cartography used for roads

At this place I want to quote our guidelines at CARTOGRAPHY.md:

The map should be intuitively readable by users with some general experience using maps without a map key, preferrably with relatively little effort.

[kocio-pl]

This addition is subtle and it is very similar to the bench icon, so I expect no problems.

[eehpcm]

@summerluk

I'll deal with your points out of order.

At this place I want to quote our guidelines at CARTOGRAPHY.md:

The map should be intuitively readable by users with some general experience using maps without a map key, preferrably with relatively little effort.

I agree 100%. My opinion is that map keys and FAQs about user interfaces mean the map carto or UI is sub-optimal. UIs should have infrequently-asked questions to cover very rare use cases, the rest should be self-explanatory, or discoverable with tool tips. But we live in an imperfect world. Not all of the map icons are intuitive. Maybe some (perhaps even most) of them could be improved. But a pane with map symbols would be there as a last resort. Because with a poor icon and a pane of map symbols I can figure out what something is, but with nothing more than a small disc I cannot do more than place it into a broad category of shop or amenity or some such.

While I agree that bicycle shops are not a high priority, the icon is quite intuitive, will not be confused with other things, and the purple colour makes clear immediately that this is a shop. That’s different from the proposed bench icon.

Of all the things on the map I don't use, and am never likely to use, I chose bike shops because I'm well aware that OSM has a high level of input from the hiking/biking/touring community. We should strive to cast aside our own subjective preferences when judging which facilities are useful enough to deserve an icon. Otherwise I demand bike shops no longer have an icon. :)

And yes, the purple bike icon is obvious and it's clear it's a bike shop. How obvious would it be if I had my way and it were demoted to a small purple disc? Unless the name of the shop has "bike" or "bicycle" in the name and the map is uncluttered enough at that location for the name to render, it wouldn't be obvious.

At least we've progressed from "I don't use this so there's no need to map it as anything other than a disc." to "I find it difficult to figure out what this icon is so lets have a disc even if it's obvious to other people what the icon means."

To me it still seems that the problem is that we need better icons and that until we have better icons a map symbols pane would mitigate the problem. In the longer term vector mapping may mean we have fancy JSON trickery so you hover over an object and a pane pops up giving more details of anonymous discs. But when we have vector mapping we'll be able to zoom in so much we can use larger, clearer icons at the highest zooms.

[Adamant36]

Personally I dont see how its not obvious what @Tomasz-W's icon is. Theres really nothing else it can be mistaken for that I can think of. So I dont see whats unintuitive about it. If there is a slight chance someone wont get it automatically though the context around it like woods etc would probably make it clear.

[polarbearing]

Which woods?

So we would need at least 3 icons, one for yes, one for no, and one for the ca 50% untagged?

[Adamant36]

I dont know. Its called an example. Pick a random bench in the woods. The point was it probably wont be confused for a store icon or anything and its the places where they are located usually helps. Like, theres only so many icons that would be in a park along a path for instince. People use the surrounding context in identifying things on a map to some degree even if the icon is perfectly clear. The bench icon clearly looks like a bench though. So I dont know why it even matters. At least to me. Otherwise, what else does it look like or how specifically is it unintuitive?

[meased]

The bench+backrest icon does not look like a bench to me.

Going by @kocio-pl's size argument, a bench is already a very small object, and now we're talking about rendering a detail on a small object? Playground equipment is much bigger and more important that the back of a bench, and that was rejected. I guess we should also rethink grit bins, light poles, and surveillance cameras too.

[kocio-pl]

The difference is that benches have well known shape and playground equipment icons do not exist yet (I'm talking about real 14 px version), so they had no chance to be rendered.

But playgrounds have their icon, even if they are twice as less popular as benches:

The back rest is very popular, so we would promote more precise tagging with rendering small additional detail for very popular tag:

In fact back rest benches are comparable in number with playgrounds, so it makes sense to show them a bit differently. It's also easy to notice if they have back rest or not.

[polarbearing]

So where lies the backrest=no in the graph, and what to do with the untagged?

[Tomasz-W]

@polarbearing proposed icon is only for combination with backrest=yes, all the rest would stay with current generic icon

[kocio-pl]

The usual way is to make generic tags look plain and simple. Simple bench does not promote adding backrest=no, because they will still look the same, however at least we would promote adding the feature, because there is a visible change.

[imagico]

Traditionally this style always aimed not to assume defaults for supplemental tags unless they are generally accepted by the community (like access tags) and have a basis in reality (i.e. for the vast majority of features the default does apply) because this would clash with the goal of providing constructive and intuitive feedback to mappers. Therefore we do not render forests without leaf_type like mixed forests but indicate the lack of leaf_type tagging explicitly in styling.

[polarbearing]

I'm not against rendering backrest= (though it's not on my priorities, but I accept it is some mappers playground). However when doing so both values should be addressed. Today's stats: amenity=bench 943368 backrest= 388831 backrest=no 66405 backrest=yes 322222

[matthijsmelissen]

This is really getting to detailed. Increasing the number of icons used on the map will make it harder to recognize/learn the meaning of icons. This has also already been stated by @matkoniecz and @SomeoneElseOSM, so I'm going to close this issue again.

[eehpcm]

@matthijsmelissen

This is really getting to detailed. Increasing the number of icons used on the map will make it harder to recognize/learn the meaning of icons

Do you have a citation to back that up? Have formal studies been done? Or are you merely reasoning that more icons means more to recognize and leaping to the conclusion that more icons make the map less usable? I don't think it's that simple.

If all icons are replaced by the appropriately-coloured disc then nothing is recognizable yet we've "simplified" things greatly. So it's clearly more complex than "fewer is better." I repeat the questions I asked earlier: if we restrict which objects get icons then who decides and how do we ensure it is done objectively?

Here are two ways in which a bad icon (bad meaning unrecognizable, not misleading) is better than the anonymous coloured disc:

1. I at least know what it is not. It it not the same class of object as that different icon of the same colour I can't decipher. With discs all I know is that I don't know what they are. They might be the same class of object or they might not. With icons, even if one looks like a fly on its back and the other looks like a UFO, I know they're not the same class of object. Not a great improvement, but an improvement.

2. I know when it is the same class of object as another that is in view or I have seen recently and remember. One of them might have its name rendered, which allows me to deduce what type of object it is. For example, the icon for a butcher isn't very obvious to me, but if I see that icon with the label "Keith's Butcher" then I know that the other place I see that icon is also a butcher. If neither is labelled and I use the query tool to find out that one is a butcher I don't have to repeat the query to find out what the other one is. With anonymous discs I have no choice but to query both. And maybe a lot of other anonymous discs with no labels.

As a general argument, I find the idea that more icons will make the map harder to use is unconvincing. In this particular case, benches, it's hard to imagine what other kind of sidewalk object they could be confused with.

[Adamant36]

@matthijsmelissen, I don't think SomeoneElseOSM is a good example here. His map is more detailed in some respects then ours. For instance he renders street lamps when we don't at the moment. So your really picking and choosing. I also think its a little out there to close this issue based on your own opinion on it when there is clearly support for it and the whole "there is no consensus anymore" discussion is going on. Like @eehpcm has said, where is the evidence to back up your assertions and why is it applicable to this particular icon? The important thing is that it acts as a feedback mechanism for more people add the backrest tag. Which I think it will do.

You can't really use the "clutter" or "to many icons" argument here because bench's are already being render. The bottom half of the bench with the back rest is exactly like the normal bench. Your making a major assumption about the intelligence of mappers if you believe they wont make the connection between the two in this case. I'm pretty sure 99% of people are pretty acclimated to how the normal bench icon looks at this point. So I don't see why they couldn't deduce what the new icon. Its not really that different. Otherwise, back it up with some tests or something. Even @polarbearing said he wasn't against it and he's usually pretty bearish on things not being rendered excessively. That should tell you something.

[sommerluk]

there is clearly support for it

That’s not true. There have been opinions in favour and there have been opinions against. There is definitively not a clear support for this. Let me add also that among the opinions against this change, if I counted correctly, there are three of the maintainers of this style.

[Adamant36]

@sommerluk, notice I said didn't say majority or even equal. There has been a few PRs that I was involved in where the majority where in favor of it but only @polarbearing was against it. Me and the others were perfectly willing to not take action on it until he had been heard out though. Although I know discussion is necessarily killed off by an issue being closed, I still don't see why it is necessary here. Even if three maintainers are against it. There are plenty of open issues going years back that had zero favor but never got closed. There's no reason this one should be unique. Especially considering the discussion was still on going. He could of at least waited until it petered out or the test renders ended up failing massively. Then at least there could have been a reasoned argument for closing it. Where does it say that maintainers have ultimate say over the rest of community anyway?

I'll also point out the issue for rendering a cross which was closed at the same time by @matthijsmelissen for the same none reason, when it could have just as easily stayed open also or he could of at least asked what other's thought of closing it. Taking both the issues together at the some time like they where makes me think it was more reactionary then anything. Otherwise, why not indulge me, @eehpcm, and the other people for it by rolling the dice and providing evidence for it shouldn't be rendered. Using the low hanging fruit as it where as reasons makes me think its more cartographic dogma then anything well reasoned though. Which is fine. Personally, id like to see it reopened and at least tested though. If the test turn out bad, Fine. But why kill it off hand before that point?

[Tomasz-W]

Let's count. Basing on comments/ likes:

• people who supported the idea or said that they are not against: @Tomasz-W @eehpcm @IVAN-RSM @dieterdreist @kocio-pl @Adamant36 @polarbearing [7]
• people against: @matkoniecz @igoreliezer @geozeisig @jbelien @meased @sommerluk [6]

I didn't count Imagico's comment, because it looks more like an information than a statement in this particular issue.

We haven't seen even single one test rendering, and with around 50:50 "votes" @matthijsmelissen closed the issue. I think after this situation he shouldn't have the power to closing them, or at least get some warning as he showed big disrespect for another users. There is no point in our Terms of use (https://github.com/gravitystorm/openstreetmap-carto/blob/master/CONTRIBUTING.md) that maintainers votes are more important than other users opinion, so there were no reason to closing the ticket.

[matkoniecz]

with around 50:50 "votes"

Decisions should be based on arguments, not on votes. I admit that sometimes it is really hard to judge arguments, but it is not a popularity contest.

[matkoniecz]

there were no reason to closing the ticket

There were reasons given above both for implementing and for rejecting this feature. You may be convinced that it is mistake to reject that idea and all arguments for closing were poor and unsufficient but please do not claim that there were not mentioned. Some were mentioned in a closing comment!

[matkoniecz]

Do you have a citation to back that up? Have formal studies been done?

Do you have citation or formal studies to make an opposite claim? While it would be nice and ideal world we would use high quality studies to guide our decisions this is done very rarely if ever.

I am not sure is it a good idea to suddenly demand them from the opposite side, without providing ones supporting your viewpoint.

[matkoniecz]

You can't really use the "clutter" or "to many icons" argument here because bench's are already being render. The bottom half of the bench with the back rest is exactly like the normal bench. Your making a major assumption about the intelligence of mappers if you believe they wont make the connection between the two in this case. I'm pretty sure 99% of people are pretty acclimated to how the normal bench icon looks at this point. So I don't see why they couldn't deduce what the new icon.

I think that it is desirable to make map where being an experienced OSM mapper is not prerequisite to understand it.

I made (without even attempt to double-blind, extremely low sample size, confounded as heck etc) some tests and typical person is unable to recognize even seemingly obvious icons.

For example many people were confuse by amenity=place_of_worship without icon, amenity=police icon, many shop icons, never noticed that all shop icons are purple so weird purple icons are another shops.

People also are generally confused by landuse rendering, bridge styling, tunnel styling, intermittent waterways etc.

[Adamant36]

@matkoniecz, yes decisions to a degree should be based on arguments, but none were provided for closing it, at least not one pertaining to this particular issue. It was more a general statement about detail that could literally apply to every open issue here. Although its not popularity contest, it is a community project is it not? So the opinions of the community should be considered and things shouldn't be closed based on a majority opinion or without at least testing it first or having reasoned discussion. That doesn't in any make it a popularity contest.

Once again, no reason was given that where specific to this particular issue. It was just a general statement that can apply any issue here. If this particular icon won't be recognizable, then show some evidence for it, but don't use SomeoneElse's map or some general thing about "clutter" as an excuse. Otherwise, we risk every issue and PR dissenting bickering over cartographic dogma. With nothing getting done.

I don't think its on @eehpcm to defend his position here. Its on the person that made the general statement about clutter to say how it specifically applies in this particular case. Otherwise, anyone can come along and derail anything by using the same tactic. The responsibility is on the person with the objection to prove why their objection holds water. Not the other way around. Last time I checked there is a feedback mechanism in place for people who have an issue with something on the map to complain about it if need be to. So if its true no one will understand it, why not let it be implemented, let someone complain, then we can revise the icon to be understandable later. Ultimately though its an icon issue though, not a "should this be implemented in the first place" issue.

I also think its a weak argument to expect everyone to prove why their imaginary people who do or don't recognize the icon is right. As I said, the icon is exactly like the original bench icon, just with a back rest added to it. Its not a new icon. We aren't reinventing the wheel. Everyone here recognizes that its a bench with a backrest, even the people that are against it, and we are all mappers. Maybe we didn't poll 2000 random people to find if they get it, but when do we? And saying people don't understand tunnel styling so they won't understand a backrest on a bench is a good what aboutism, but they are completely different and have nothing to do with each other. Plus, most people don't understand most things when they are first introduced to them, that's not an argument for or against anything though. The question is will they understand it in this case and I think they will. Since like I said, its almost the exact same icon we are already using with a minor addition. Its not a completely different icon or even really altered. That should be enough evidence.

[matkoniecz]

none were provided for closing it

You may be convinced that it is mistake to reject that idea and all arguments for closing were poor and unsufficient but please do not claim that there were not mentioned. Some were mentioned in a closing comment!

See https://github.com/gravitystorm/openstreetmap-carto/issues/3187#issuecomment-421650821

[polarbearing]

TLDR

[matkoniecz]

It was just a general statement that can apply any issue here.

It can be aplied to most "lets show detail of XYZ using a new icon", but for example it would not apply to #3396 #3394 #3393 #3392 #3385 #3355 (from most recent ones)

[imagico]

I didn't count Imagico's comment

As a general rule you can count me as 'boycott' in any attempt to turn design decisions into a popularity contest. The whole idea of voting on design decisions is a transparent attempt to scuttle the argument and evidence based development process. In a venue like this it is always easier to organize and astroturf popular support for a change than to find and present substantial arguments in support of it and to substantially consider and address critique, in particular of course if the change is a bad idea.

And to make this perfectly clear - the idea of making design decisions based on popular vote - even if including or being representative for the current mapper community - would be against the documented goals of this style.

[matkoniecz]

In a venue like this it is always easier to organize and astroturf popular support for a change

To be more specific: it is trivial to ask people on some forum/channel/mailing list to come here and vote or to create 20 sockpuppet accounts.

In case of making decisions like that voting is not a proper way to do it.

[sommerluk]

There is no point in our Terms of use (https://github.com/gravitystorm/openstreetmap-carto/blob/master/CONTRIBUTING.md) that maintainers votes are more important than other users opinion

There is not mentioned in CONTRIBUTING.md that there is a vote at all. In last consequence, the maintainers of this style take the decisions.

So the opinions of the community should be considered and things shouldn't be closed based on a majority opinion […] That doesn't in any make it a popularity contest.

The group of people participating in this discussion is around a dozen. That’s not really representative for the OSM community as a whole either.

I don't think its on @eehpcm to defend his position here. […] The responsibility is on the person with the objection to prove why their objection holds water.

No. If someone proposes something, he has to give arguments in favour of it.

@matthijsmelissen closed the issue. I think after this situation he shouldn't have the power to closing them, or at least get some warning as he showed big disrespect for another users.

No. @matthijsmelissen is a long-term maintainer and contributor of this style and is doing a great work. Honestly, I think it’s disrespect when in this discussion arguments against this change are ignored: When reading some replies here, I have the impression that the arguments against this change are indeed ignored of at least have not been understood completely and there was no real effort to understand them. Who is maintainer of this style is not object to public vote. Your behaviour with @matthijsmelissen was inappropriate.

[kocio-pl]

OK, cool down for a moment, please. There were too many "hot", emotionally loaded words and statements here lately.

What surprised me was sudden closing of a live discussion and I think this was a direct source of this heat. Closing on GitHub does not really stop discussion, but the change made people nervous (yet some wrote insightful responses I admired!), because it was completely unexpected. I'm not sure why some topics bring more positive or negative emotions than the others, but I hope that we can soon continue talking with less tension.

[matthijsmelissen]

The reason of closing it quickly was that there was talk about implementing this issue, and I really want to avoid people spending time on building something that will be rejected anyway. So I think a decision was necessary. What would you have preferred?