Reconsider rendering all values of office=

[jeisenbe]

Expected behavior

@imagico has mentioned that he would prefer that we not render all values of office=* with a dot and text label, but only a fixed list of values we have verified to be used consistently by mappers.

For example, we could only render values of office=* which are documented with a page on the wiki and do not conflict with another similar tag.

This also might include dropping support for office=yes most likely.

Actual behavior

Currently all values of office=* are rendered with a dot and text label at z19, including office=yes, office=unknown and office=nonsense.

Documented and common values are included in a "whitelist" which renders them slightly sooner. See #3796 which adjusted this list slightly.

Several values are currently excluded: 'no', 'vacant', 'closed', 'disused', 'empty' - but not some other possible mistakes:

office=physician (undocumented, used 2583 times, probably should be amenity=doctors), office=therapist (should be under healthcare=?), office=medical (Possibly should be healthcare= or amenity=clinic/doctors/etc., unless it's an insurance company or health corporation office), office=healer, office=healthcare (ambiguous), office=dentist, etc.

[kocio-pl]

This is the same problem we have with buildings for example, but much smaller:

I would say building=yes is the worst problem (294+ mln out of 369+ mln of uses!), but there are 10k+ building tags, of which only a tiny part is documented and there are clearly many mistakes. I don't see how could we maintain such lists not punishing people for the fact that there are many valid values.

[imagico]

No, building=* is not in any way comparable to office=* - neither in semantics nor use nor how we render it. The fact that building=yes is widely and consistently used and has a well defined meaning is testimony to that - while office=yes makes about as much sense as highway=yes.

The comparison to rendering of shops is more fitting - see #3718, #3730.

The approach discussed in #3730 for shops should in principle also be usable for offices - though since the scope of office=* is much less clearly defined than that of shop=* maintaining a list of rejects would probably be more important than for shops.

[kocio-pl]

I don't see any more (or less) consistency with building=yes, it is just a "basic value", which does not have any real meaning. Same for shop=yes, office=yes, highway=yes etc. This is equally consistent for all such cases - mapper just does not give any details but is sure that it belongs to this key. The only problem for a highway is that we lack generic rendering for roads, while for all the others we have.

I approved removing shop=yes because we provide rich rendering for most common values and basic rendering for most of the rest, so people have choice and are encouraged to give more details, and sometimes it is used as a secondary tag for fuel stations which is not intended for rendering probably. But since this is not yet deployed and we can't say if that really works, I would like to wait before eradicating other similar cases. This is a foot in a water test for me, so please hold on.

With lists - I'm afraid of growing it without control (we had shop whitelist disaster, so this is real danger), but if we can find some guidelines for it, it might make sense to make it bigger. Otherwise we can get flooded with countless "car_repair" (maybe it's wrong, or maybe car repair has the office here?), "Forsyth␣Institute" (mistagging for name), "Rental" (different than "rental"), which I got from the end of this list: https://taginfo.openstreetmap.org/keys/office#values

[jeisenbe]

The tag `building=yes` is pretty consistently used for a man-made structure which has a roof and at least 3 walls. The more specialized values of building, like `building=roof` or `building=carport` might only have a roof, and there's also some use of the `building=` key for houseboats, static caravans (mobile homes) and permanently moored ships, but I believe building=yes is used the vast majority of the time for structures which match the usual definition including a roof and walls. This means that `building=yes` already tells you most of what you need to know. Compare this to `highway=yes` which could be a path, footway, cyclepath, track, or a major road, or perhaps something else related to highways. In contrast, `office=yes` is not defined; it could be a place of business which provides retail services to customers, or only provides business-to-business services with no public access, or could be a private office within a larger feature like a hospital or even a private home, since the key `office=` has a broad definition and there is no specific definition for `office=yes`. A `shop=yes` is at least a retail business which sells goods or services to the public, so it's definition is a little clearer - but we are no longer going to be rendering this, preferring that mappers pick a more specificvalue instead. But I agree that we can see how things work with the deployment of the change removing shop=yes rendering, and then discuss this issue further in a month or two.

[kocio-pl]

the key office= has a broad definition and there is no specific definition for office=yes.

Both definitions are broad, and rightly so. "A place predominantly providing services, frequently selling them" is as broad as "man-made structure with a roof, standing more or less permanently in one place." for me. Houseboat is completely different than yurt or industrial building. The only thing in common for buildings is a roof and there is no definition for building=yes (it doesn't even have a page, it's just mentioned as "the most basic use"), but so is true for office=yes - it's a basic, generic value.

This means that building=yes already tells you most of what you need to know.

Maybe that's what is enough for you, but for me it's not. I can imagine typical building and typical office with ease, but I want to encourage people to make more specific tagging in all the keys. Rendering *=yes less prominently for office makes sense, but we don't yet encourage people to make more specific tagging for buildings by less prominent rendering of building=yes and this problem is huge (~300 mln objects).

[andrzej-r]

This may not be a popular view here but you are abusing your position. Simply display popular tags as mapped and leave tagging decisions to others and mappers.

There is a reason shop/office/building=yes exist - either the value is unknown to the mapper, doesn't matter, or there is no consensus about tagging it yet. That's not an issue for you to resolve.

[Adamant36]

doesn't matter

It would be interesting to know a situation where the correct key is known, supported, but adding it doesn't matter.

[andrzej-r]

Sorry, that's a simplification but it relates to the most common case we end up with imprecise data. I know I do it a lot.

Say, I am mapping an area and adding data in bulk, for example adding buildings from imagery or offices from a board in front of an office building. I have three options:

1. not add this information at all,
2. add what I known and move on to another location,
3. ask questions, search the web or guess.

I use all three options all the time, 1 being by far the most frequent, then 2, and 3 remote last. Each adds an order of magnitude more effort so pick the option depending on how much this information matters to me.

What I am asking you to do is not to interfere with this process. This decision does not belong to the renderer, especially one that is supposed to follow broader community consensus, and is harmful, as it is far more likely people will choose option 1 than 3 you intended.

[andrzej-r]

For offices specifically, the most common fall back is to tag them as a name of the building. This results in nice rendering (big font from z17), too bad it is often incorrect (when building has its own name), only works for single occupant buildings, and provides zero information about the meaning of that name. Even office=yes is more specific.

This is how business parks now look like in my area:

Notice three issues:

• Company names which were added as building names are shown prominently. I.e., this is what the last change really encourages,
• Some businesses falling under a shop category are not affected (shown as shop dots)
• All offices tagged correctly tagged as office=company or office=yes are now rendered as an addr:housenumber (this is a regression to a bug fixed when office=* rendering has been added).

In summary, the new rendering is buggy, inconsistent and encourages incorrect (not just incomplete) tagging.

[jeisenbe]

Notice three issues:

@andrzej-r please open a new issue to discuss those problems - I can open one for you, but it would be best if you could summarize the problems mentioned above in a fresh issue. This issue is about whether we should render a marker and text label for all values of office

the value is unknown to the mapper, doesn't matter, or there is no consensus about tagging it yet

Generally this style does not render features that do not yet have a consensus way of tagging. See the goals of this style at https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md - "It's an important feedback mechanism for mappers to validate their edits and helps to prevent unfavorable fragmentation of tag use."