See also #108.

Given we already have too many different icons, we need to be careful about this.

We also need consider where we're going cartographically. For a general purpose map, I would be against rendering office=yes.

amenity-brown is mostly dedicated towards touristic/cultural features (see also #1624), it should not be expanded to commercial activities as in crafts.

@polarbearing This interpretation is too narrow - what about post office, town hall, police station, fire station or even courthouse? Amenity is all about different services, while shop is all about buying goods. That was my conclusion when thinking about where the bank/atm belongs and now it makes a lot of sense for me.

@pnorman You're right, after leaving safe shops/amenities area we're on terra incognita and we have to watch our steps carefully. I am not against rendering office=yes, but I definitely want to take some precautions here (which I didn't mentioned just to keep the list compact):

• I would do it at the lowest possible level (z>=19)
• I would do it after gaining some experience with other craft/office POIs

Cartographically there's not too much things on highest levels to show and office=yes may be as useful for some people as shop=yes.

👍 I completely agree, the possibility to view office POIs would be something very valuable for me.. even at Z=18 ! :)

^ especially office= government which is of public importance

https://twitter.com/kmohankar/status/690738296314462209

copy from #1966

for craft=brewery - it is for places

• where it is impossible to buy anything (otherwise it would have pub or bar icon or at least would be tagged as shop)
• it is impossible to visit them for tour or something similar (it would be tourism=museum/attraction)
• are not big enough to draw even small landuse
• are even not filling entire building (building names are rendered)

I am unsure whatever rendering name would be valuable (alcohol-related icon would be clearly misleading as it is not bar/pub/shop so it is unacceptable).

In general - I strongly oppose new icon, labels are likely to be useful for offices. I am unsure about labels for craft.

As I look here now, designing right icons may be hard, so I would start with showing at least labels with dots for those keys.

I'd agree that "labels with dots" for offices makes sense too. Over at https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua I mapped a long list of nonspecific shop, office, healthcare and leisure items to purple, black, pink and green dots. It probably wouldn't be feasible or desirable to have as along a list in osm-carto, but I think the approach makes sense.

I think the difference between amenity, shop, craft and office is somewhat blurred - especially we don't know what "amenity" really is (and that's probably just a legacy general type for POIs). But we also don't know what is "craft" - it can be "amenity" or "shop" if we think about tailor for example, since it can be a workshop alone (that is strictly craft), but also the place you can bring your coat for repair ("shop" as in hairdresser currently, but if you think that "shop is all about goods and amenity for services" that would be "amenity" for sure).

The result is that I don't want to be strict about icons for those types. I would put:

• (brown) paragraph sign for a lawyer, no matter if it's tagged as an "office" or "amenity"
• (brown) needle/button for a tailor, no matter if it's "craft" or "amenity"
• (violet?) house icon for real estate agency, no matter if it's "office" or maybe "shop"

because for simple map user these are typical, easily recognizable POIs and it's just our internal problem that we don't have clear ontology they could fit in.

So I would propose to start rendering craft and office as a dot+label, but try to make icons case by case if it's possible, not looking too much into the tagging schemes.

Whats the current state? Any further discussions? Carto currently shows house numbers instead of names. This leads to repeated house numbers in case of multiple offices. In my eyes a rather bizarre and puzzling rendering result. Wouldn't be a simple dot + name a much better solution?

We're discussing implementation details now: #108 (comment).

I think we should discuss in which cases #3061 is enough, and in which cases we still need an separate icon.

Icons proposals for some craft=* tags:

• craft=brewery
  
• craft=carpenter
  
• craft=electrician (-> I'm not sure what is this tag for - a repair point, where you can bring broken device, or kind of office for workers which are typically working outside; if it's a second option, I think a dot would be enough here)
  (cable)
  (flash)
• craft=plumber
  (tap)
  (tools)
• craft=shoemaker
  
• craft=tailor
  
• craft=metal_construction (-> same thing as in craft=electrician)
• craft=winery (it wasn't mentioned here, but it has 4,4k uses now, so I think we should discuss a separate icon)
• office=* rendering will be resolved soon by Render offices as dots + names #3061 (I don't think we need separate icons for estate agents and insurance)

for the electrician I prefer the cable, the flash could be used for power stations and substations.

I though the same thing, so I did a review od a power=* key. There are only 2 tags which we should consider for flash icon:

• power=plant -> it's rendered as industrial area, so there will be problem with labeling on size (there are many tags with this problem, but discussion about it stuck)
• power=substation -> I've chcecked my neighbourhood and some other places, and I think there are too many substations for rendering them (remember that it's not a common-needed feature)

shoemaker is the only one I find hard to read.

I'll work on that.

There are in fact quite a few office tag values, some of which could benefit from having icons. I can't check it right now but government, lawyer, IT sound like potential targets.

I would indeed prefer to have #3061 merged first and work on icons later, but that's mostly due to my interest in fixing the mapping feedback issue, not because I don't like icons.

• craft=shoemaker fixed a little bit:
  
• craft=winery icon proposal
  (grapes)
  (barrel)

All I know is e.g., in iD the user types sawmi... and iD offers him sawmill, which is what he wants. He finishes his edit only to be informed by his friends a month later that they never found the sawmill he said he put on the map, and had to give up and turn back.

All I know is e.g., ...

Than stop polluting this issue.
Your comment will not change anything and annoy many people which are subscribed to the repository / issue.

(for reference see the related help question at https://help.openstreetmap.org/questions/73116/how-to-check-how-a-tag-renders )

A reply of "stop polluting this issue" is perhaps a little strong, especially as the very first line of the very first entry above was "I think we should show not just shops and amenities, but also some objects with craft=* and office=* key". I understand that #1697 (comment) means that essentially it's not really possible to work on this right now, but perhaps the poster does not?

I can fully understand that repeated requests from "customers" (whether it's things like this issue or whether it's me elsewhere banging on about the unsuitability of OSM Carto for hiking routes) can be annoying the umpteenth time you've heard a particular request from different people, but perhaps a more polite response would have been "I'm sorry, but due to the technical limitations we're currently working under - the data in the database that the main OSM.org maps are rendered from - we simply can't fix this at the moment, although work (see the links from #4015 ) is ongoing".

It is now possible to submit a PR to render this feature. Since v5.0.0 all craft=* features will be imported as polygons when mapped as closed ways.

What about craft=caterer?

There are already multiple craft objects with usage above 2k (see https://taginfo.openstreetmap.org/keys/craft#values ). I guess pink color from the old healthcare objects could work, but nobody has tested it yet. Also the icon codes from gist designed by @Tomasz-W are not accessible now, so we lack files to test them and some new ones should be created (or just reposted).

Also the icon codes from gist designed by @Tomasz-W are not accessible now, so we lack files to test them and some new ones should be created (or just reposted).

In case they will be needed, I can reupload it. Just contact me ;)

Is there anybody willing to try to prepare the code?

We still lack consensus on #3635 and it is not at all certain that there will be consensus to add specific icons for certain craft=* features.

We still lack consensus on #3635 and it is not at all certain that there will be consensus to add specific icons for certain craft=* features.

There should really be a time limit or something on it or something. Or at least intermediate alternative/options in the meantime. Heck even some kind of specific "review rendering X category of icons" issues would be better then nothing. Otherwise, there will be no incentive or will for it to be resolved. Things with it aren't going to just magically improve or be dealt with by referencing the issue every time someone wants to add a new icon either. Ultimately, rendering new things and dropping rendering of older ones should just be a normal part of style maintenance IMO. Obviously priorities will change over time. There's zero reason it should be a (big) thing and it's not fair to anyone involved, or OSM more generally, that it is.

Even more (or less? I'm not sure) so though because there doesn't seem to be the will to alter the "style purpose" file or whatever it is and it still has a mapper feedback as part of that purpose. I know in this case at least that rendering craft icons help a lot in that regard. At least in my experience there seems to be a lot of miss-tagging of craft places as shops or other things that do render. At the end of the day the important thing is to balance the pros and cons, and I think the pros of rendering craft icons outweigh the cons. Especially given that (again, I'm only saying in my experience) the objects are already being rendered as other things anyway. So, at least from what I've seen this won't increase map clutter by that much. The problem with a catch all prohibition on rendering anything until some amorphous thing is dealt with is that it doesn't account for such things as that though.

As @jeisenbe wrote mentioning #3635 has the purpose of making it clear to developers that while some maintainers might express encouragement to develop a change to add new symbols to this style there is no consensus on that among maintainers and such changes are therefore currently likely to be rejected.

#3635 will not go away by letting time pass. It will be resolved by either all maintainers showing a willingness to develop a consensus for the strategic direction of the style in that regard or by developers developing changes that resolve the issues pointed out in #3635 and that achieve consensus among maintainers practically.

The discussion in #3635 is open and anyone willing to work towards a consensus there is welcome. @jeisenbe and me also have in #3951 worked towards ideas how to ensure consensus based decision making works in cases some maintainers express a sustained non-constructive attitude.

As @jeisenbe wrote mentioning #3635 has the purpose of making it clear to developers that while some maintainers might express encouragement to develop a change to add new symbols to this style there is no consensus on that among maintainers and such changes are therefore currently likely to be rejected.

I know. I just don't think pointing to an issue that hasn't had a comment on it for a year except for ones that are off topic every time someone wants to implement something new really moves things forward at all. Even #3951 hasn't had any activity since January. There is a point where things will just natural proceed how they were before the issues were opened if no one takes the time to actually resolve them. Like I said in my other comment anyway, it's not a black and white thing where they either get dealt with or they don't. There's intermediate steps that can taken in the meantime. A few have been suggested, but from what I remember you tossed them off as not adequate because they didn't completely reinvent the wheel or whatever (I.E. weren't system wide changes), but you can only eat the elephant one part at a time. Books are written a page at a time. The journey of a thousands starts with...Etc etc..Otherwise, it can be akin to analysis paralysis.

You say that it can be resolved by "developers developing changes that resolve the issues pointed out in #3635", but from what I remember there wasn't even clear changes pointed out that would resolve it. Let alone any with consensus. There was a lot of generalities and vague comments though. I have some ideas, but they are not "system wide" and are likely to be rejected. Some similar suggestions already have been. No one is going to develop things just because either. Especially since this is a maintainer problem, not a developer one. It's on the maintainers to have a clear direction for the style and make it explicit what's acceptable or not. Not to just be like "do a PR for whatever, and maybe it will accepted and maybe it won't." That's not a good way to do things. At least @kocio-pl is 100% clear in position and what direction he thinks the style should go in. I think @jeisenbe is to some degree also. Although less so. You seem to be less specific in what exactly you want done and more so about what you don't. That's just my reading of it though. I could be wrong, but I've read through all the discussions a bunch of times.

Like do a project with specific issues that can be discussed and resolved to lead to a resolution. It's not that difficult and it's how things will ultimately get resolved. Either way though, there has to be clear, specific things to take action on.

@Adamant36 - If you want to discuss our decision making processes here then #3951 is the place to do that - not a specific design issue like this. Same for the general strategy on POI rendering - that is a matter for #3635, not here.

If you think they are off-topic, simply don't introduce them.

@kocio-pl - sorry, i have no idea what you mean.

As @jeisenbe wrote mentioning #3635 has the purpose (...)

It is you trying to discuss some other issue here.

I was explaining to @Adamant36 in more detail the relevance of mentioning #3635 on this issue and encouraged further discussion on generic matters beyond the scope of this issue on the relevant other issues. I repeated this suggestion more strongly today after further generic commentary without specific connection to this issue. Your comments do not seem to make much sense in that context to me. If you want to discuss the way we structure communication on this issue tracker into separate issues that would deserve possibly opening a new issue.

But you have not discussed it there, but here, yourself in the first place. Why did you not tell to @jeisenbe to move there and even joined him, but to @Adamant36 when he replied to you on your own topic?

Sorry @kocio-pl - i can't follow your logic here. In any case - if you want to discuss procedure or communication style please do so at a separate issue.

Do not treat the same topic from different persons in a different way, as you did here.

I opend a new PR for craft (#4809) and would be happy to get some input about the design choices: Do you like the colour choice? Or should craft be displayed in office blue? And should rendering start at 17, like for shops, or rather at 18, like for offices?