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

[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 notifications@github.com 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.