Openstreetmap-carto: Add rendering for amenity=* and office=*

[jremillard]

Hi,

Any point that has an amenity or office tag and a name tag, should at least get its named rendered even if we don't have an icon at max zoom.

Most of the POI's in the mall are not rendered.

http://osm.org/go/ZfJD0RleX--

• [x] bench #194
• [x] public_building (won't fix)
• [x] bicycle_parking #591
• [x] waste_basket #418
• [x] townhall #77
• [X] parking_space #776 (won't fix)
• [x] hunting_stand #966
• [ ] vending_machine #1561
• [x] fountain #705
• [x] social_facility #1776
• [x] car_wash #1777
• [x] marketplace #751
• [x] dentist
• [x] waste_disposal #419
• [x] community_centre #506
• [x] taxi #879
• [x] fire_hydrant (won't fix)
• [x] veterinary clinic #1656
• [ ] parking_entrance #270
• [ ] nursing_home
• [x] arts_centre #2520
• [x] nightclub #456

[dieterdreist]

Il giorno 09/ago/2013, alle ore 03:41, Jason Remillard [email protected] ha scritto:

Any point that has an amenity or office tag and a name tag, should at least get its named rendered even if we don't have an icon at max zoom.

or craft or shop

[jremillard]

Yes, I meant to include shop too.

[dkniffin]

I fixed the shop portion of this with #117.

I might submit another pull request with a generic rendering of amenity= although unlike shop=, it'll probably only be named amenities.

I can't find any instances of craft= or office= already being rendered

[b108]

Craft= and office= are not rendering. That will be very good improvement to start render them.

[tuxayo]

I fully agree with this, when the pull request of @oddityoverseer13 will be ready, doing the same thing for office=* and amenity=* should be easy?

[matthijsmelissen]

We dont't want to render spelling mistakes, so we should come up with a list of tags to render.

[dkniffin]

Yea, we can do something very similar to #604 for office, amenity, and craft. The script I wrote can be easily adapted for that. Maybe we can come up with a different generic office, amenity, and craft icon?

[matthijsmelissen]

Craft is not in the database, so cannot be done straightaway. I would focus on office and amenity first. Not sure if a blacklist-system for amenity would work well, because the amenity thing key contains all kind of different things and we might not want to render most.

[dieterdreist]

Am 20/giu/2014 um 18:34 schrieb oddityoverseer13 [email protected]:

a different generic office, amenity, and craft icon?

for bigger office areas we show the information with the landuse=commercial tag

the various amenities and crafts are so different in nature that an icon doesn't give you any more information, we could simply show a name label, but then this would also display objects with typos in the tags (not desirable for this map)

[pnorman]

Craft is not in the database, so cannot be done straightaway

It also gets us into a tagging mess, because craft=* is not generally used for crafts, but for trades, but it's not exclusively craft=*.

[dieterdreist]

Am 22/giu/2014 um 20:25 schrieb Paul Norman [email protected]:

It also gets us into a tagging mess, because craft=* is not generally used for crafts, but for trades, but it's not exclusively craft=*.

the tag comes from the German community and was intended to mean "Handwerk" which is basically a medieval concept but still valid in today's reality in Germany at least (I guess in most of Europe). My dictionary gives both terms, trade and craft, for the German word, not sure what the differences are. It has also to do with guilds, or nowadays the IHK (Industrie- und Handwerkskammer = ~ chamber of industry and trades/crafts). It is mostly not about handy craft.

[pnorman]

craft=electrician, craft=roofer, craft=plumber, craft=hvac, and craft=painter are excellent examples of trades. The key is a muddle of trades, industrial (craft=agricultural_engines, craft=sawmill), and actual crafts (craft=handicraft). Trying to add a generic rendering for craft would be like trying to add a generic rendering for amenity, which includes prisons to ice cream stores.

[dieterdreist]

2014-06-22 23:33 GMT+02:00 Paul Norman [email protected]:

The key is a muddle of trades, industrial (craft=agricultural_engines,
craft=sawmill), and actual crafts (craft=handicraft). Trying to add a
generic rendering for craft would be like trying to add a generic
rendering for amenity.

I agree that the description of craft in the wiki is poorly drafted, e.g.
because it doesn't tell how to differentiate between industrial and craft,
but aside from this it seems mostly a cultural / language problem. The term
"trade" is commonly translated as de:"Handel" (buying and selling), which
won't include any work like producing, repairing, etc.

The specific value craft=agricultural_engines was also emerging from
talk-de [1] and as I understand it shouldn't be applied to industrial scale
manufacturing instances of this (as industrial stuff gets tagged
man_made=works), but rather to relatively small businesses which offer
repair and maintenance of agricultural machinery (maybe a poorly designed
value) and often also sell these. A business like this relates to the
industry like a mechanic relates to a car manufacturer.

One of the reasons why "craft" was chosen as a key is also wikipedia I
guess, because the German article "Handwerk" translates to the English
"craft" [2] there, and the first sentence seems to fit more or less
("pastime" doesn't actually fit): "A _craft_ is a pastime or a profession
http://en.wikipedia.org/wiki/Profession that requires some particular
kind of skilled work http://en.wikipedia.org/wiki/Skilled_worker. In a
historical sense, particularly as pertinent to the Middle Ages
http://en.wikipedia.org/wiki/Middle_Ages and earlier, the term is usually
applied to people occupied in small-scale production of goods
http://en.wikipedia.org/wiki/Good_%28economics%29, or their maintenance
http://en.wikipedia.org/wiki/Maintenance,_repair,_and_operations, for
example by tinkers http://en.wikipedia.org/wiki/Tinker. The traditional
terms _craftsman
http://en.wikipedia.org/wiki/Craftsman_%28disambiguation%29_ and _craftswoman
http://en.wikipedia.org/wiki/Craftswoman_ are nowadays often
replaced by _artisan
http://en.wikipedia.org/wiki/Artisan_ and rarely by _craftsperson_ (
craftspeople http://en.wikipedia.org/wiki/Craftspeople)."

only at the end of the article there is a reference to trade [3] which
doesn't really explain the difference between a craft and a trade: "A
_tradesman_ is a skilled manual worker in a particular trade
http://en.wikipedia.org/wiki/Trade_%28occupation%29 or craft.
Economically and socially, a tradesman's status is considered between a
laborer http://en.wikipedia.org/wiki/Laborer and a professional
http://en.wikipedia.org/wiki/Professional, with a high degree of both
practical and theoretical knowledge of their trade."

If the current term "craft" is not well chosen for what it is intended to
describe we should re-discuss this on the [tagging]-ML, as this is a really
important part of today's economic reality in central Europe.

[1]
https://lists.openstreetmap.org/pipermail/talk-de/2010-November/079014.html
or http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.de/59615

[2] http://de.wikipedia.org/wiki/Handwerk ->
http://en.wikipedia.org/wiki/Craft

[3] http://en.wikipedia.org/wiki/Craft#Tradesman

[daganzdaanda]

Is there a difference in US and UK usage of the words "craft" and "trade"?

Linguee.com is useful to find out how a term is used and translated on the web. Of course, it depends on the texts that are available, which may not always have been translated very well...

"Handwerker" is a craftsman (or plural craftsmen).
http://www.linguee.com/english-german/search?source=auto&query=Handwerker

"Handwerk" is not clear: "craft" is used about 47% of the time, and "trade" about 35%.
http://www.linguee.com/english-german/search?source=auto&query=Handwerk

But the other way around, "craft" is translated as "Handwerk" nearly 75% of the time, while "trade" is translated mostly as "Handel" (50%) and only infrequently as "Handwerk" (6%).
"Handicraft" is 34% Handwerk and 25% "Kunsthandwerk" (i.e. more artisanal).

I get the feeling "craft" is OK to describe the German concept of Handwerk. Maybe "trade" would be more correct and sound better to a native speaker, but trade has more and stronger additional meanings which might confuse mappers.
Also, changing the tagging now might not really be a good thing, as has been explained with the power=sub(_)station issue. (Or would it still be okay, since it isn't rendered on most maps yet?)

It's still true that some of the things tagged with craft=* probably should be tagged as something else.

[AndiG88]

industrial (craft=agricultural_engines, craft=sawmill)

I agree that some tags don't seem to belong in craft at all, but I think the generall idea was to use craft for local traditional small scale production and man_made=works if it is industrial (e.g. brewery).

I guss a lot of stuff ends up in craft= simply because man_made=works is even worse defined. I mean how Am I supposed to tag a sawmill? man_made=works + product=wood? I think for this tag to be used more it need something like works=sawmill/chemical_plant/brewery/... and not just product=*.

[daganzdaanda]

These are the 60 most used amenity values that are not in the map style yet (Groups of 10):

bench 405 099
kindergarten 124 453
public_building 113 264
bicycle_parking 99 341
waste_basket 90 961
townhall 58 807
parking_space 55 866
swimming_pool 49 894
hunting_stand 49 868
vending_machine 47 722

fountain 46 669
doctors 37 908
social_facility 32 508
car_wash 28 509
marketplace 22 885
dentist 21 525
waste_disposal 19 918
community_centre 19 590
taxi 18 310
residential 15 833

fire_hydrant 13 787
veterinary 12 451
parking_entrance 10 367
nursing_home 10 329
courthouse 9 762
clinic 9 650
arts_centre 9 534
nightclub 9 259
bbq 8 883
ferry_terminal 8 844

grit_bin 7 430
car_rental 6 453
clock 5 622
driving_school 4 964
ice_cream 4 109
charging_station 3 291
bureau_de_change 2 756
boat_storage 2 400
sauna 2 084
shop 2 074

motorcycle_parking 1 905
food_court 1 893
shower 1 833
studio 1 785
watering_place 1 747
brothel 1 503
retirement_home 1 368
childcare 1 356
casino 1 261
gambling 1 054

garages 918
gym 881
social_centre 826
public_hall 802
payment_terminal 776
refugee_housing 694
compressed_air 635
youth_centre 630
water 621
building 619

I removed "yes" and "abandoned", hope I missed nothing worthwhile.
It is a very mixed bunch!

[matthijsmelissen]

Thank you for the overview, very interesting.

What does amenity=residential mean?

This is also very related to #660. Instead of making decisions for the individual cases, I think it would be good to have some strategy on how to decide which map features to add.

[daganzdaanda]

Here the values that are in the code, with empty lines to show what's missing

parking 1 438 945 
place_of_worship    604 588
school  596 793
restaurant  409 238

fuel    227 583
post_box    162 239
grave_yard  157 106
bank    156 345
fast_food   150 905
cafe    148 339
recycling   125 719

hospital    116 763
pharmacy    116 475

post_office 108 357
pub 102 829


toilets 89 873
telephone   82 900
shelter 79 048
drinking_water  73 417
atm 73 067
police  68 198
fire_station    67 923
bar 64 523





library 47 537

university  38 200



college 27 566
bus_station 25 261




theatre 18 543

cinema  15 865


bicycle_rental  12 574










emergency_phone 7 302
biergarten  6 493


prison  5 423
embassy 5 110

car_sharing 4 706

[daganzdaanda]

What does amenity=residential mean?

I'm sure it is an error. Maybe something that happens when an old value is still in an editor, after tagging landuse or highway=residential. But many seem to be combined with buildings, so could be that this should say these are "residences"?
Is there a way to find out if a specific editor is to blame? I used taginfo's overpass-query, and did not see any clear trend.

This is also very related to #660. Instead of making decisions for the individual cases, I think it would be good to have some strategy on how to decide which map features to add.

Yes indeed. amenity is a kind of catch-all, but some of the other tags are also not very uniform.
Also, there is probably another, better tagging for many of the lesser used amenities, so we don't have to render bad tagging...

Maybe we could come up with groups of POIs that should be treated in a similar way (not just in key:amenity)

• healthcare related stuff (doctors, dentist, pharmacy, clinic, hospital, ...)
• social infrastructure (community, youth, elderly, disabled, ...)
• transportation services (e.g. rental, fuel, charging, parking)
• food and drink (most are probably fine)
• shops (should be fine now, more or less)
• offices
• sanitation services? (toilets, recycling, wastebaskets? something else?)
• things that may be landmarks or useful for finding your way around?
• street furniture (benches, wastebaskets, lamps ...)

[matthijsmelissen]

I think the hardest ones are the government/social facilities.

We have public_building, townhall, social_facility, community_centre, nursing_home, retirement_home, refugee_housing, youth_centre, etc.

I think the name of these should be rendered on the map. But should they also get an icon? My gut feeling says that they would look better without icon, but I can't quite tell why. Also, would a text without icon look fine if these amenities don't take up a full building?

[daganzdaanda]

(social facilities) I think the name of these should be rendered on the map

Yeah, they do serve a public interest. Funnily, I had the same thought, that they don't need an icon! Maybe it's because the icons would not be easily recognizable or intuitive? How would an icon for a nursing_home look?
So just a name would be fine. Maybe all these can get a new color for the text, or a typographic treatment like italics? I guess we would have to see a test to gauge how it looks if it is not taking the full building, sitting off-centre or at an entrance.

Also, social_facility has a lot of sub-tags to replace many of the other tags:
http://wiki.openstreetmap.org/wiki/Social_facility
Should we start rendering nursing_home, youth_centre etc, or should we favour the social_facility route, or both?

[matthijsmelissen]

See also https://trac.openstreetmap.org/ticket/4420 (veterinary), https://trac.openstreetmap.org/ticket/2199 (brothel), and https://trac.openstreetmap.org/ticket/4742 (motorcycle_parking).

[matthijsmelissen]

@nebulon42 Do you have any suggestion for a dentist icon? The SJJB icon @nebulon42 is not that nice. I think a tooth would suffice.

[kocio-pl]

I also vote for the tooth icon with nothing else.

[matthijsmelissen]

I added the most used ones (>10000 occurrences) to the top of this post. For most of them, finding a suitable icon is the toughest task.

[matthijsmelissen]

I propose not to render amenity=fire_hydrant (too specialistic).

[matkoniecz]

Main problem with amenity=fire_hydrant is that displaying would make sense on z22 or z21. And that zoom levels currently are not used anywhere (AFAIK - it is also not going to change in near future).

[matkoniecz]

BTW, the same problem is with amenity=bench - though Humanitarian style displays benches on z19.

[AnBuKu]

Am 14.01.2015 um 08:25 schrieb Mateusz Konieczny:

Main problem with amenity=fire_hydrant is that displaying would make
sense on z22 or z21. And that zoom levels currently are not used
anywhere (AFAIK - it is not going to change in near future).

This is the only one I know with z21
http://www.osm.ch/#21

But, sure, emergency=fire_hydrant should not be rendered in the main map
(even if I'm a fanboy of fire hydrants :-)

And, amenity=firehydrant should be avoided or existing ones changed
towards emergency=fire_hydrant

https://taginfo.openstreetmap.org/tags/emergency=fire_hydrant -> 303 482

https://taginfo.openstreetmap.org/tags/amenity=fire_hydrant -> 12 274

—
Reply to this email directly or view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/108#issuecomment-69878437.

Andreas Bürki

[email protected]
S/MIME certificate - SHA1 fingerprint:
ED:A5:F3:60:70:8B:4C:16:44:18:96:AE:67:B9:CA:77:AE:DA:83:11
GnuPG - GPG fingerprint:
5DA7 5F48 25BD D2D7 E488 05DF 5A99 A321 7E42 0227

[matkoniecz]

I marked fire_hydrant as "(won't fix)".

[nebulon42]

@math1985 I have a suggestion for dentist (https://github.com/nebulon42/osmic/blob/master/health/dentist-16.svg) and will open a PR.

[matthijsmelissen]

dentist and townhall have been added in the meanwhile.

[matkoniecz]

I updated the first post marking implemented features.

amenity=public_building should be rejected based on its wiki page - http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_building

Short Answer: Don't.

[kocio-pl]

@matkoniecz nightclub is also already implemented and we have an open ticket for veterinary clinic.

I wish we start using Wiki for maintaining such big and long lasting lists of features...

[matkoniecz]

I would prefer individual tickets over collections like that - for example this ticket seems to offer absolutely no benefit over opening individual ones that may be handled separately.

[kocio-pl]

For me it does: you have a bunch of related issues together in one place if the problem is more general (like rendering important/popular objects other than just shop=*). Individual tickets are linked for individual cases related to this problem.

[matthijsmelissen]

I also like having the meta-tickets.

[matkoniecz]

I marked public_building as "won't fix" (as recommended by http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_building).

[kocio-pl]

While I agree we don't want to show the icon for public_building, I think we may render it as a "major" building type (currently only PoW buildings).

[matkoniecz]

According to wiki it is a bad tagging scheme, therefore not deserving promotion by using it in rendering.

[kocio-pl]

Ok, right :smile: - it's just very popular, but building=public is the answer. I guess once we start displaying them as major, people will start migrating.

[dieterdreist]

sent from a phone

Am 29.07.2015 um 13:04 schrieb kocio-pl [email protected]:

but building=public is the answer

I'm pretty sure it isn't ("public" is a very rough building type, could be anything from an office tower to a library or..., it is similar to "residential", where a more refined distinction is detached house or apartments etc.)

[kocio-pl]

It's always better to be more specific if possible, but I guess major buildings are just different kinds of public buildings. However it needs some testing probably to know if it's not too wide.

[tuxayo]

I agree that it would be useful to distinguish public buildings.

After testing few capitals
http://overpass-turbo.eu/s/aJL
http://overpass-turbo.eu/s/aK3
http://overpass-turbo.eu/s/aJI
http://overpass-turbo.eu/s/aK2
the density don't seem to pose visual cluttering problems.

[kocio-pl]

Community centre and veterinary clinic rendering is now merged.

[matthijsmelissen]

Updated

[kocio-pl]

car_wash is now merged too: https://github.com/gravitystorm/openstreetmap-carto/pull/1777.

[matkoniecz]

Updated, thanks.

[matkoniecz]

vending_machine

I think that in this case value of rendering it is rather low (though waste baskets are rendered) and rendering it in understandable way would be problematic.

[kocio-pl]

See https://github.com/gravitystorm/openstreetmap-carto/issues/1561#issuecomment-141659855.

[planemad]

• [ ] office=government https://github.com/gravitystorm/openstreetmap-carto/issues/271

In places like India government offices are the most important public amenity in smaller towns and villages. Can we please boost this up in priority? This will also help mappers retag amenity=public_building which is now an abandoned tag. cc @matkoniecz

[kocio-pl]

@jremillard: fountain and social_facility are now merged, so you can check their boxes as done.

[matthijsmelissen]

I can do so too :)

[valhentai]

can we add amenity=retirement_home to the list?

[polarbearing]

No that is old-fashioned tagging, used too little.
Such facility should be tagged amenity=social_facility + social_facility=assistant_living.
Social facilities are rendered.

[valhentai]

@polarbearing Thanks for the info. I updated tags in my city. now they are rendered.

[james2432]

Can we add:
office=tax_advisor
office=accountant
Both are used a lot :
http://overpass-turbo.eu/s/hi0 (tax_advisor)
http://overpass-turbo.eu/s/hi1 (accountant)

[matthijsmelissen]

Are there icons for them?

[james2432]

JOSM has them as:

Accountant = Person beside a box with a dollar sign on it
Tax Advisor = Same icon as Accountant but with a green arrow pointing down from above

[matthijsmelissen]

The JOSM icons don't seem to go very nice with this style though.

[james2432]

I'm aware they are ugly, but I'm not a graphics designer... and anything i'd make would look like rubish

[kocio-pl]

This is 16x16 PNG export of those icons in black - they are very similar, but IMO we may just use the same icon for both (1 is better, because 2 is less clear):
1)
2)

[polarbearing]

ATM and bank intentionally use a generic bank note icon. The above re-introduces a particular currency symbol.

[james2432]

So put a guy beside the stack of money, or use generic currency symbol https://en.m.wikipedia.org/wiki/Currency_sign_(typography)

[kocio-pl]

We have only 14x14 pixel monochrome matrix, so I see it as a very difficult task. Unless you - or anybody else - show some promising sketch, so I can refine it somehow, I doubt it can be done within our current framework.

Still I think at least (brown) dot with a name is better than not showing it at all (or as a house number) - see also https://github.com/gravitystorm/openstreetmap-carto/issues/1697 for similar POIs.

BTW: Currency sign is not known enough, so in my opinion it wouldn't work for most of the viewers. That's the same problem we had with hospital shown as cross - there is something more neutral than cross/crescent and it's called red crystal, but I expect that wide audience is not familiar with it, so we drop this idea.

[SomeoneElseOSM]

I know that while OSM carto has a liking for individual icons for individual shop types, but for offices I'd definitely start with something very generic - a dot, like the "other type of shop" dot, but in a colour that doesn't get confused with existing features.

Here's an example, using black for offices:

(that's http://www.openstreetmap.org/#map=19/52.95297/-1.15692 BTW).

Edit:
https://map.atownsend.org.uk/maps/map/map.html#zoom=19&lat=52.9529&lon=-1.156722
is a slippy map of that rendering.

[matthijsmelissen]

Here's an example, using black for offices:

Looks very nice to me. I agree keeping adding icons might be not good for readability.

[polarbearing]

Looks nice for one office per building. What do we do if a skyscraper fills up with 250 offices?

[kocio-pl]

The same as with malls: some of them will be eclipsed by the others.

[SomeoneElseOSM]

Yes - in that example at z19 you can see that not all offices have names shown for exactly that reason. Zoom in one more level and you get most (but all), and z21+ support AIUI needs some mod_tile changes, so very much in the distance I suspect.

For _very_ multilevel buildings you need something like http://wiki.openstreetmap.org/wiki/OpenLevelUp to make sense of them; I'd expect it'd be out of scope here. Have a look at New Street Station in Birmingham if you want an example of a multi-use, multi-level structure that's well mapped in OSM.

[ccamara]

As far as I see it, the main difference between most shop=* and office=* is that whereas the first sell goods, the latter sell services. For that reason I think that if it has been decided that shops have to be rendered because they might be of any interest, offices should be rendered as well, as they are at least as interesting as shops, if not more (I'm thinking now about government offices, which additionally may be considered of public interest).

It is quite another thing the already mentioned problems of readability, but IMHO that should be addressed later as a different issue (eg: by defining the right icons, colours and zoom levels), but that should come after displaying offices (I find @SomeoneElseOSM 's proposal a good workaround to be used in the meanwhile)

[boothym]

Agree with adding something for office=* - looks a bit strange to have the addr:housenumber displayed in High Street full of shops when for example a lawyer or accountant's "shop" is not rendered either with a name or icon.

[kocio-pl]

The question is - how standard office rendering should look like? Black dot + name? Adding icons for specific offices might be done later if needed, but we have to start with something generic.

And which offices should be shown?

[matthijsmelissen]

What about name only, without fot?

[kocio-pl]

We can try it, but I guess it will make it harder to guess which feature the label describes, because black is generic color we use for different things.

I guess office=government and office=administrative (#271) should be rendered brown as they are public services similar to townhall or police station. Maybe also some other offices too.

Maybe it would be good to have a test server to check how does it look all around the world.

[kocio-pl]

I think we should render nursing_home as we do with social_facility. It has 13 977 uses and is still gaining popularity:

[abdeldjalil09]

amenity=marketplace is now rendered (#2893)

[kocio-pl]

Thanks, updated.

[polarbearing]

I think we should render nursing_home as we do with social_facility.

Both iD and JOSM have recently updated their presets in favour of amenity=social_facility + social_facility=nursing_home. Your graph is not showing the 2017 development.

I wonder what (import?) caused that strange peak in 2011?

[kocio-pl]

Unfortunately http://taghistory.raifer.tech is not refreshed as frequently as I'd like it. Thanks for the info.

[andrzej-r]

I see my report #2953 has been referred here. Thanks.

However, this discussion is much broader and more open-ended. I would like to point out there is an actual bug (so it isn't just an enhancement request) in the way office PoIs are currently rendered:

The rendered uses a house number + house name instead of a name tag. I can't think of any scenario where such result would be desirable. Most likely it is a leftover from the address PoI implementation.

Could that be fixed first, before we sort out icons and other enhancements?

[kocio-pl]

Could you link an example?

[andrzej-r]

http://www.openstreetmap.org/#map=19/52.23241/0.14955

[kocio-pl]

Could that be fixed first, before we sort out icons and other enhancements?

You mean something like http://www.openstreetmap.org/node/5237606800 ?

I don't feel we could fix it in the other way than just start rendering kind of icon, probably just a grey dot similar to shop dot. What do you think could be done before, which could be easier?

[andrzej-r]

Icons would be great but I guess that may take some time (there are many office tags). For start, we could simply change the text we already render (from addr:housenumber to name).

BTW, iD currently renders an icon + the name tag. OsmAnd renders only a "name (addr:housenumber)" text, which personally I think is a bit too much.

The way company names are currently displayed discourages correct tagging. So it would be good to fix it first and focus on aesthetics later.

[kocio-pl]

I also think special icons will be needed only for some special types and we can work on it later. A dot should be easy (probably with man_made gray color) and I would use it because a name alone may suggest an area, while most offices are tagged as a node.

So - is anybody willing to prepare such PR and test it?

[andrzej-r]

I've just noticed https://map.atownsend.org.uk/maps/map/map.html renders office=company as a dot and a name. Perhaps the implementation can be reused.

[kocio-pl]

Would you like to prepare the code? That would help a lot.

[geesona]

I provided a suggest icon for a bbq #2996 a week ago is some one able to check it for me to see if it is suitable and maybe implement it?
https://gist.github.com/geesona/a5912e34c377d644e088889ecf40d09d

[Tomasz-W]

I think this issue should be renamed to "Render amenity=* as dots + names".

Let's review first comment https://github.com/gravitystorm/openstreetmap-carto/issues/108#issue-17843225 :

• vending_machine -> it has ticket for separate icon (#1561)
• parking_entrance -> it has ticket for separate icon (#270)
• nursing_home -> this tag was moved to a subtag of amenity=social_facility (which has it's own icon at this moment), so it's not up to date
• there are some amenity=* tags which already has separate tickets for icon and wasn't included here (e.g. bbq or studio) and it's ok because we don't mess up the topics

The only thing which stay left to discuss here is generic dots for amenities which don't have separate tickets for own icons.

[andrzej-r]

Can someone compile a list of amenity tags that are currently not rendered and could be added as a dot + name? The one from @daganzdaanda is a bit out of date now.

If so, I will prepare a PR similar to #3163.

[Tomasz-W]

After review of a topic, I think we shouldn't use dot-rendering for any amenity=*. This tag is so diversified that generic-dot may be confusing. We should just discuss using dedicated icon if we want to add rendering for some amenity.

[andrzej-r]

I partially disagree. Yes, we would like to have icons for amenity tags (BTW, office= tags are not an exception, there are some good candidates for an icon as well) but the priority should be in supporting all documented or popular tags in the first place.

What I propose is a 2 stage approach. First we implement all missing tags as dots and then, one by one, add icons for them.

[Tomasz-W]

I looked at all issues with "amenity-points" label https://github.com/gravitystorm/openstreetmap-carto/issues?page=2&q=is%3Aissue+is%3Aopen+amenity+label%3Aamenity-points
and also at all amenity=* issues which has been referenced here.
I don't see any amenity=* candidates for dot-rendering.

@andrzej-r Can you give examples which tags do you consider?

[andrzej-r]

@Tomasz-W there are over 9000 amenity tag values: https://taginfo.openstreetmap.org/keys/amenity#values

Over 110 are documented in https://wiki.openstreetmap.org/wiki/Key:amenity. ID currently have 25 presets for amenity=*.

As I mentioned in #3163, my (new) proposal is to have a catch-all clause rendering all amenity=* and office=* tags with a simple dot+name. On top of that we can special-case any other tag values (icons, custom filtering/rendering options) just like we are doing it now.

Even if we were to use an opt-in approach, it is still useful to have a fall-back rendering for tags do not have an icon for just yet.

[kocio-pl]

While office sounds OK for me to always be rendered with a dot, amenities are too different. It might be another kind of eating place, street furniture or almost anything else. Therefore I would be more careful when rendering amenities and do it only for whitelisted values. Probably some of them need to move to the new keys to make it more clear what they really are.

[dieterdreist]

sent from a phone

On 7. Apr 2018, at 11:28, kocio-pl [e-mail] wrote:

While office sounds OK for me to always be rendered with a dot,

I could imagine limiting these to large offices, i.e. on areas and >=limit

Generally, while bigger offices can be landmarks, most offices are IMHO not significant enough for this general style.

[andrzej-r]

dieterdreist, you have to tweak both icon and label rendering paths. Not saying it is not possible (I tried it before) but the combinations quickly pile up. For example, office= tags are quite often combined with landuse= (not just building= tags) and there are likely a lot of other corner cases. Also, without rendering at least an icon or dot you will often not see the tag at all - in congested areas labels often hidden even at z19.

Do more people agree that dots on the buildings are undesirable? If so, do you have any ideas for a solution?

[matkoniecz]

office= tags are quite often combined with landuse=

This sounds like a tagging mistake, can you give an example of place where this tagging is correctly used?

[andrzej-r]

There are many such unexpected tag combinations in use. Given their popularity I wouldn't automatically dismiss them as tagging errors. One reason is lack of support for office tags in carto, so there is no visual feedback to the mappers.

Edit: I noticed another use case - some ways are tagged with office=* only (no building or landuse tags).
example

Edit 2: or plain area= or indoor mapping like here.

I've even seen spotted a combination of landuse=school, amenity=school and office=educational_institution, although I'm OK treating this one as a tagging issue.

[Tomasz-W]

For me, this issue is resolved by #3163 .
See https://github.com/gravitystorm/openstreetmap-carto/issues/108#issuecomment-364636355 and later comments, there wasn't much support for amenities generic dots idea.

[matthijsmelissen]

I think we should still consider the last three individual amenities in the initial post.

[Tomasz-W]

I think we should still consider the last three individual amenities in the initial post.

@matthijsmelissen I agree, but:

• vending machines -> separate ticket https://github.com/gravitystorm/openstreetmap-carto/issues/1561
• parking entrances -> PR https://github.com/gravitystorm/openstreetmap-carto/pull/2875
• nursing_home -> this tag was moved to a subtag of amenity=social_facility (which has it's own icon at this moment), so it's not up to date

This meta-issue is unnecessary in this situation.

[matthijsmelissen]

Alright, happy to close this item!