remove buildings catch-all rendering?

[nebulon42]

I just noticed that we still use catch-all rendering for buildings. Was this an intentional decision or was it just not removed yet? Admittedly, there would be a lot of values to cover, but we do so also for shops.

Why have I noticed? I have seen that building=ruins (used roughly 4.7k times according to Taginfo) is rendered in the same way as normal buildings (proposal for changing rendering of this tag in #1898). Just to bring an example.

[matkoniecz]

The problem with catch-all rendering for buildings is that there is no clear list of valid values.

Tagging rules for building key are also rather poor and messy - for example ruined church fits both building=church and building=ruins.

Rejecting special rule for building=proposed is relevant here - see #485

[gravitystorm]

Was this an intentional decision

Certainly not by me! We should move to a defined list, as per shops etc, even though the list might be large and ill-defined. This will help avoid problems like building=Residential(46k typos)

[dieterdreist]

sent from a phone

Am 05.10.2015 um 12:26 schrieb Andy Allan [email protected]:

Certainly not by me! We should move to a defined list, as per shops etc, even though the list might be large and ill-defined. This will help avoid problems like building=Residential(46k typos)

this approach will discourage tagging of more detailed building types though (e.g. industrial rather than "production_hall"), or even rather than any type, and might even encourage people to simplify existing values in order to get a building rendered.
In contrast to this, 46k "typos" of Residential can be quickly fixed with a manual edit, would be a no-brainer (fwiw residential is a poor detail level for building type anyway)

[imagico]

this approach will discourage tagging of more detailed building types though (e.g. industrial rather than "production_hall"), or even rather than any type, and might even encourage people to simplify existing values in order to get a building rendered.

This is a general problem and not in any way specific to buildings.

For buildings as for many other things it is probably desirable to have a limited set of primary classification values and not encode minute details in the primary building tag.

[kocio-pl]

We probably don't even have a proof that this approach works as expected and I'd like to have a tool to analyze which is better. Who knows, maybe the list of accepted values really helps us avoid showing low quality data, but one can also argue that it simply discourages mappers from trying more accurate tagging and pushing them to using *=yes (which is less valuable than specific type, so it's also of lower quality).

Even if the list might work in general, there are some details to think about. How should we know which values will be included on the list and which ones we exclude? What about Wiki pages and Taginfo numbers - do we want to rely on them somehow or we want our own special rules? How often should we update the list?

I plan to revisit shops list, so any kind of guide to creating and keeping such list up to date will be useful also there.

[matkoniecz]

I plan to revisit shops list, so any kind of guide to creating and keeping such list up to date will be useful also there.

In case of shops the decision in end was to render everything with 100 occurrences and more, except clearly bad values - see https://github.com/gravitystorm/openstreetmap-carto/blob/master/scripts/shop_values.rb

[nebulon42]

I think the diversity for building values is already quite large. So I guess that the problem that not rendering everything might discourage more specific values will not be that severe (provided that the threshold is sufficiently low). Maintaining clear criteria and some list like @matkoniecz pointed out for shops would be necessary IMO.

[pnorman]

For buildings, I think a rendering where building is not null and building != no is suitable. I distinguish this from the catch-all renderings we used to have which rendered anything with name.

[matthijsmelissen]

For buildings, I think a rendering where building is not null and building != no is suitable. I distinguish this from the catch-all renderings we used to have which rendered anything with name.

+1

[kocio-pl]

That would also work for me. The list would be hard to maintain or too restrictive.

[matkoniecz]

For buildings, I think a rendering where building is not null and building != no is suitable. I distinguish this from the catch-all renderings we used to have which rendered anything with name.

+1, after building=no will be nearly eliminated by JOSM validator (below 1000 occurrences worldwide? below 100? 0?) support for this value also may be dropped.

edit: building=no appears 12 292 times as of 2016-03-24 - http://taginfo.openstreetmap.org/keys/building#values

[nebulon42]

I do not agree. I think there are more problems with the catch-all than with the list. Take only the examples of building=proposed and building=ruins (not taking into account the above mentioned typos and something like building=mylittlebuildingcategory) however ill-defined they may be. They are not really buildings (not the mylittlebuildingcategory) and should be omitted. The arguments for closing the respective issues were not too convincing to me as they bascially stated that mappers should follow the rendering rules.

The situation is also not different from shops and from other catch-alls. It's as undesirable to render every value within the building key as building as displaying any name. It's also about consistency. It's hard to understand why catch-alls are mentioned to be bad practice (e.g. in CARTOGRAPHY.md) and then some are eliminated and some are not. That would be a bit contradictory.

If the catch-all is kept, why is there a list for shops? And the other way round: If there is a list for shops, why is there no list for buildings?

[dieterdreist]

sent from a phone

Am 06.10.2015 um 08:17 schrieb Michael Glanznig [email protected]:

I think there are more problems with the catch-all than with the list. Take only the examples of building=proposed and building=ruins

I d consider at least the building =proposed a tagging error. It's not very different to someone tagging building=yes, proposed =yes

"proposed" is neither yes nor a building type and should not be tagged. Better tagging would be sth like proposed:building=mall to avoid misinterpretation

[kocio-pl]

It all depends on our answer for questions like "what kind of problem we want to solve?". We can have a catch-all, we can have a list of all accepted values or just a list of the common "excluded" values - but once we start to have a list, we take the responsibility from the mappers and we tell what values are "good" and which are "wrong".

It will create a loopback response: people will start to realize that some values are not rendered and may tag them differently or abstain from tagging. It will cut typos, sure, but it will also have effect on some possibly proper values like "concert_hall" for example.

however ill-defined they may be

How do we know if mylittlebuildingcategory is "well" or "ill" defined then? With shops we didn't solve that issue at all ("shop=winery" was there until I removed it lately) and using the same rule - "all above given limit" - we still won't be sure. That's why I ask for Wiki definitions and also for updating: some of the values will cross the limit one day, others will be removed and replaced with something else. OSM tagging is dynamic process, not just a static list of values we can make once and forget it.

Buildings (but also shops and amenities) are broad categories and maintaining list for them is not as simple as, for example, list of the highways. So it's important to know what do we want to achieve exactly - list is just a tool and should be used properly to do what we want.

[matkoniecz]

The main problem is that building=proposed (and similar) tagging scheme is bad and should not be encouraged by honouring it and not displaying building tagged like that.

I am not considering dropping catch-all as a good idea, values of building tag are a complete mess.

But in case of dropping catch-all I propose to deliberately display building=proposed (and similar).

[gravitystorm]

I do not agree. I think there are more problems with the catch-all than with the list.

Yes, that's my view also. Having catch-alls breaks the mapper feedback loop (e.g. "but building=Residential renders, so that must be the correct tag")

The list would be hard to maintain or too restrictive.

Having a defined list of tag values is useful. Having a complete free-for-all is not, and it doesn't promote collaboration if every value is valid and nobody can either agree what's valid nor document any of the values.

We should do what we do with shops for starters, e.g. take the top 100 non-typo, non-confusing values, and go from there.

[kocio-pl]

We should do what we do with shops for starters, e.g. take the top 100 non-typo, non-confusing values, and go from there.

Sounds like reasonable solution for a start, I can even imagine excluding all the typos, but I don't know what do you mean by "non-confusing values" and what really bothers me is that it's just a short term "rescue" plan and we have no idea what to do in the long run. With shops it's already time to review them, so it would be good to think how to deal with such big lists once we have them (and we do have one now).

Having catch-alls breaks the mapper feedback loop (e.g. "but building=Residential renders, so that must be the correct tag")

It works both ways: "but building=stadium is listed on key:building page, so why doesn't it render - is it wrong?".

[pnorman]

After #2415 I'm going to close this. The long tail of building values is just as long as shop values, and it would have the same problems with being unmaintainable.