Open jeisenbe opened 5 years ago
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.
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.
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
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.
the key
office=
has a broad definition and there is no specific definition foroffice=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).
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.
doesn't matter
It would be interesting to know a situation where the correct key is known, supported, but adding it doesn't matter.
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:
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.
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:
In summary, the new rendering is buggy, inconsistent and encourages incorrect (not just incomplete) tagging.
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."
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, includingoffice=yes
,office=unknown
andoffice=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 beamenity=doctors
),office=therapist
(should be underhealthcare=
?),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.