I think we should show not just shops and amenities, but also some objects with craft= and office= key. Case by case analysis is probably needed to know which we want to show and how - sometimes the same icon and/or color may be used as with already rendered POIs, but when it doesn't match, maybe generic black/brown/violet dot and label would work.
Looking at the most popular POIs from these categories:
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):
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.
:+1: 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

copy from #1966
for craft=brewery - it is for places
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:
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: https://github.com/gravitystorm/openstreetmap-carto/issues/108#issuecomment-328904162.
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:


(cable)
(flash)
(tap)
(tools)

2018-02-14 11:26 GMT+01:00 Tomasz Wójcik notifications@github.com:
Icons proposals for some craft=* tags:
very nice, I like almost all of them,
for the electrician I prefer the cable, the flash could be used for power
stations and substations.
plumber: tap
shoemaker is the only one I find hard to read.
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:
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.

(grapes)
(barrel)Quick remarks:
Some remarks:
Shoemaker, tailor and brewery I like.

craft=brewery proposals comparsion:
(vessel + mug)
(mug + hop)
(vessel + hop)
I'd take vessel + hop before mug + hop.
plumber - tap
winery v2 - great!
shoemaker - fixed version is good (but maybe the shoe shape could be simplified by merging the soles to reduce the anti-alias blur?)
All the other icons are very good!
Thanks for all the great work on these icons!
Of course the small details can't all fit with the pixel grid, and so the icons won't be as crisp as many of the bold new SVGs. But it's amazing how well the details still are readable. We should do some test runs on real data to see how they look "in the wild".
vessel+hop version mostly works for me too. Maybe mug+hop version would be better if you use this icon (the one you used does look different):
https://github.com/gravitystorm/openstreetmap-carto/blob/master/symbols/biergarten.svg
@daganzdaanda Would you like to make a test PR and some renderings? I'm surprised that you have never been a code contributor to osm-carto, despite the long history of being active here. :smile:
I'm surprised that you have never been a code contributor
Yeah, I know ;) The thing is that I already feel I'm spending too much time on OSM stuff... but thank you guys for starting that Docker thing, maybe sometime I can try that.
OK!
We need more active people in this style in general:
Any activity makes us stronger, but currently we have enough bug reports, nice icons and quite conclusive discussions, I can merge the PRs and try to make monthly releases, so the weakest link is preparing code for PRs at the moment.
If anyone wants to try, I can help to start it. In my opinion working Docker containers are really important step toward healthy project, yet we need some people to play with it. :smile:
Gist links:
All of @Tomasz-W 's icons above look good, the only one that might be too complex and less recognisable is the brewery icon.
Maybe a conical flask and beer bottle?

Or just a barrel? http://g0cqw3d93gz443uvqwvpy0l8.wpengine.netdna-cdn.com/wp-content/themes/bbwnew/img/icons/brewery.svg or https://d30y9cdsu7xlg0.cloudfront.net/png/9236-200.png ?
Basic query for craft added(tailor) can add others once approved
As I understood, all from https://github.com/gravitystorm/openstreetmap-carto/issues/1697#issuecomment-367432772 was accepted. @kocio-pl ?
Are we adding:
metal_construction
gardener
confectionery?
If so what icons are needed?
Is brown the colour we are going with because it's a service?
Are we having a generic dot/symbol for other craft values?
We haven't discuss it yet, but for me there are only 2 colours to consider:
The rest (basing on current state and pending discussions):
violet is for shops, blue for offices, black for administrative offices https://github.com/gravitystorm/openstreetmap-carto/pull/3061, green for leisure elements and red would be propably a healthcare color someday https://github.com/gravitystorm/openstreetmap-carto/issues/2938, orange (the only one colour don't used now and didn't considered for other features, but it wouldn't match craft=* tag)
amenity-brown is heavily loaded already,
man-made-grey would suit.
I was thinking about using kind of orange for eating places once, see https://github.com/gravitystorm/openstreetmap-carto/pull/2824#issuecomment-328521710.
@lakedistrictOSM @polarbearing @kocio-pl
@james2432 is waiting with https://github.com/gravitystorm/openstreetmap-carto/pull/3126 :) We have to decide what to do with some tags, my proposition is:
What do you think?
It might have sense, but I have to see how does it look like.
I think we should avoid grey dots where possible because they might look like bollards.
I'd suggest a generic "craft" icon of a spanner and a hammer similar to the one iD uses. Food and drink "crafts" like confectionery can have their own icons. If we use the current confectionery icon (cake) for craft=confectionery then we should design a new icon for shop=confectionery (probably a sweet like the .fr map or one of the ones suggested in https://github.com/gravitystorm/openstreetmap-carto/issues/1534#issuecomment-100043472)
I think we should avoid grey dots where possible because they might look like bollards.
They don't because craft=* node is usually on building area, so it would be propably intuitive that is not a bollard there.
I'd suggest a generic "craft" icon
As I know, we don't use generic icons for whole keys in osm-carto
If we use the current confectionery icon (cake) for craft=confectionery then we should design a new icon for shop=confectionery
There are examples of the same icon used in different colour for different features (eg. green picnic sites and brown picnic tables or brown art centres and violet art shops)
so is it man-made-grey or gastronomy-orange?
It's testing time...
added screenshots in pull request for all three colours
It's shown here: https://github.com/gravitystorm/openstreetmap-carto/pull/3126#issuecomment-387588250.
@pnorman doesn't want strokes in svgs
sent from a phone
On 9. May 2018, at 02:47, James notifications@github.com wrote:
so is it man-made-grey or gastronomy-orange?
it could be business pink like the shops.
There are probably no strokes in our icons and these are only settings for strokes, which are placed by Inkscape automatically.
Any ideas for craft=metal_construction icon?
@Tomasz-W a couple of I beams stacked on top of eachother?
craft=metal_constriction icon proposals:
(screws)
(3 i-beams)
(4 i-beams)I vote for 'screws'.
Do we have a consensus on a proper colour for craft=* key? Brown seems to be the best, but on the other hand it's heavy loaded with other map features... Another thing to discuss is to add generic dot for craft=* tags without an icon.
screws look good to me they look thick enough to be lagg bolts
@james2432 Gist link: https://gist.github.com/Tomasz-W/b83cecde97e3d0351ba3c198b4836cb7
@Tomasz-W Is there a way to piggy back by off of James2432's craft PR or something to get this done? Or are we stuck waiting until he gets a new laptop? I think the craft icons are an important addition to the map and I'd be willing to do a new PR for them or finish James2432s work after I do a few other things if its possible.
@Adamant36 For more technical questions ask @kocio-pl , I'm an icon designer, not a coder, so unfortunately I can't help you.
@kocio-pl ?
@Tomasz-W OK
Nice to hear you want to do something with that!
Please talk with @james2432 for a start. It's always possible to just create your own PR, because they are independent and may be even competing, as long as they're not merged. But it's better to start talking and do a team work if possible.
Well dont copy what i've done exactly because as Paul has stated, the way I did it needs a database reimport, I need to replace craft(and remove the new column in a few files) and replace it with tags->'craft'
This is technical detail - it would be easily visible when testing.
What I try to reach now is some simple planning: making sure who wants to do what and when.
Fixed, pixel aligned icons here: https://gist.github.com/Tomasz-W/4c4febd2f19dbfd8ec201100b54946ea
@jeisenbe, I might be interested in reviving the craft PR if there's a will for it. What do you think?
I would be in favor of a simple dot + text rendering similar to office= at
z18 or z19, to start.
Specific icons for certain types could be discussed later.
That would work. It would definitely make things easier to implement. Any opinion on the color? It looked like both brown and purple were explored in the PR but there was never a decision on which color was best from what I remember.
I think they are similar enough to offices (as places of business which are not shops) that we can try using the same color for both craft= and office=, to avoid having to create another new icon color. There were at least 3 comments in favor of this before: https://github.com/gravitystorm/openstreetmap-carto/pull/3126#issuecomment-419638860, https://github.com/gravitystorm/openstreetmap-carto/pull/3126#issuecomment-419727349 and https://github.com/gravitystorm/openstreetmap-carto/pull/3126#issuecomment-420213083
(You could also try one of the new colors mentioned in #3641, for example #12a98d Lch(62,43,174) - somewhat similar to office, or #c84a74 Lch(50,54,3) - similar to shop, but this may not be necessary)
I think a different colour would be better. To me "craft" means manual (not industrial) work (e.g. painter, goldsmith, etc.) in opposite to brain work or administrational work performed in an office. Also people often can drop in here, to discuss the colour of paint, the design of a golden ring, to pick up a produce, etc. So it shares some features with shop as well.
When adding a POI, I always question myself, is this POI _mainly_ about selling (-> shop), administration (-> office) or manual work (-> craft).
sent from a phone
On 3. Sep 2019, at 08:36, geowas-github notifications@github.com wrote:
When adding a POI, I always question myself, is this POI mainly about selling (-> shop), administration (-> office) or manual work (-> craft).
this system is not completely consistent with the actual data, if you look at the top 10 shop values, 3 are about services and one is unclear (yes): hairdresser, beauty and car_repair
Craft can also be combined with shops, e.g. craft=confectionary or craft=optician
On 3. Sep 2019, at 08:36, geowas-github @.*> wrote: When adding a POI, I always question myself, is this POI mainly about selling (-> shop), administration (-> office) or manual work (-> craft).
this system is not completely consistent with the actual data, if you look at the top 10 shop values, 3 are about services and one is unclear (yes): hairdresser, beauty and car_repair Craft can also be combined with shops, e.g. craft=confectionary or craft=optician
Right.
I'd second jeisenbe and use office colour. All involve some labour.
I don't mind mind using office blue either.
If this was to be more fine grained, I would prefer using either office or shop colours depending on availability of walk-in commercial services.
This is similar problem to amenity/shop issues. It is not clear if we should blindly follow keys (shop -> violet, amenity -> brown, office -> blue) or if we should use some internal rules to make the difference. Blind key matching gives more of a tag feeling, while internal rules allow more real-object related feeling. For amenities we go with internal rules for example, for offices we go with blind match currently.
We could use some kind of pink also, because it's free now after healthcare objects are rendered in red.
Please add craft=electronics_repair in the list, it renders only the housenumber:
The key craft= is not yet imported as a polygon when mapped as a closed way, so to render these features we need to request the rendering servers reload the database. There are several other changes already approved, so this could happen soon.
Someone will need to submit a PR adding craft to the list in openstreetmap-carto.lua - you can see #3786 for an example of how to do this.
It's best to first fetch and checkout the schema_changes branch, which is also the branch to which the PR needs to be merged.
Hey all, I just noticed a number of breweries I added to OSM weren't rendering and found this discussion. Personally I like @Tomasz-W 's suggestions from here https://gist.github.com/Tomasz-W/4c4febd2f19dbfd8ec201100b54946ea -- or maybe just a barrel for the brewery? These are often pretty large and popular venues, I think it would be worth showing on the main map.
I also add bar=yes where appropriate, if there's some objections to adding breweries in general, I wonder if that could influence rendering? Maybe if it's craft=brewery and bar=yes in conjunction then it could show a regular bar icon?
@aawiseman - PR #4015 will need to be merged to and then we will have to organize a reload of the rendering database on the openstreetmap.org servers which render this style (and any other database users who update the style will also then need to reload their rendering database).
I hope this may be done in the next couple of months?
After that it will be possible to consider rendering features such as craft=brewery, if you are interested in submitting a PR to add the rendering.
sent from a phone
On 30. Jan 2020, at 01:21, Andrew Wiseman notifications@github.com wrote:
Maybe if it's craft=brewery and bar=yes in conjunction then it could show a regular bar icon?
there’s also this
https://taginfo.openstreetmap.org/keys/microbrewery
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 https://github.com/gravitystorm/openstreetmap-carto/issues/1697#issuecomment-580048697 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 https://github.com/gravitystorm/openstreetmap-carto/pull/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.
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.
Most helpful comment
(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 https://github.com/gravitystorm/openstreetmap-carto/issues/1697#issuecomment-580048697 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 https://github.com/gravitystorm/openstreetmap-carto/pull/4015 ) is ongoing".