Id: Some preset removes building tag

Created on 12 Feb 2019 · 10Comments · Source: openstreetmap/iD

To reproduce:

find a building
click the building preset in the sidebar to change the feature
search for something like swimming pool or sports centre, and select one of those presets
the building=* tag disappears

For presets which are being applied to existing objects with a building tag then that tag should be left alone.

wontfix-confusing

Source

boothym

Most helpful comment

How about throwing some warning? Like "Hey, it's a building right now, are you sure want to make it a swimming pool? The building=* tag will be removed"

Right now I just have to explain the problem to every user, and know what's even worse? It's not really their fault, they just wanted to mark a building as a school or kindergarten, but instead they accidentally removed the building=* tag from several buildings.

This behavior is so sneaky I wouldn't notice it myself if my editor silently removed some tag while I apply a preset.

Here's a list of places where I had to restore a removed building=* tag and the offending preset which caused them to vanish:

Here's a list of editors in Estonia who suffered from this iD behaviour:
J4lamees
martin187
jemm
Сергей Легович
Taffer36
swaan

That's half of Estonian community (yes, it's a small country)

If you still think this is working as most people would expect it to work, then I don't know what else to say.

SviMik on 28 Sep 2019

👍9

All 10 comments

I think this is working as most people would expect it to work. Yes many presets will remove a building tag. Sports centers are supposed to be mapped around their grounds (#4682), and swimming pools are usually not buildings.

There are lots of other old issues related to building tags that are useful to read (#5084, #4668, #4639).

iD tries really hard to follow the advice on the wiki of what things are mapped as buildings, unless people sneak in changes to the wiki that go against how features are already mapped (#5056, #4265).

bhousel on 12 Feb 2019

@bhousel, you know I think iD try too hard. One day, maybe one day you'll consider a bit of open-ness in tagging.

5398

yvecai on 22 Feb 2019

@yvecai We try really hard to make iD the simplest tool for the most mappers. Sometimes this means making inferences that don't suit everyone. There is always the raw tag editor in iD and other OSM editing tools like JOSM where you can have complete control. I hope you can appreciate the nature of the project and keep feedback relevant and constructive.

quincylvania on 23 Feb 2019

I do understand the aim of ID, toward beginners. However I think that removing tags because two presets cannot coexist on the same element does not help, except on the very short term. And it had some drawbacks to.

yvecai on 23 Feb 2019

I just wanted to open an issue, and came across this.
The wiki explicitly references the building= tag being used in conjunction with sports_centre in some cases (e.g. an indoor facility).
I can definitely see how the building value should be optional in case of a new from-scratch area being added, but could there be a way to prevent this behaviour when a building= value is already set, especially if it is set to a specific value instead of generic "yes"?

tohaklim on 6 May 2019

I can definitely see how the building value should be optional in case of a new from-scratch area being added, but could there be a way to prevent this behaviour when a building= value is already set, especially if it is set to a specific value instead of generic "yes"?

@tohaklim This runs the risk of users inadvertently keeping the building tag, which doesn't seem better than the risk of users inadvertently removing the building tag. I agree with Bryan that the current behavior is fine—mappers have learned what to expect.

quincylvania on 21 May 2019

How about throwing some warning? Like "Hey, it's a building right now, are you sure want to make it a swimming pool? The building=* tag will be removed"

This behavior is so sneaky I wouldn't notice it myself if my editor silently removed some tag while I apply a preset.

Here's a list of places where I had to restore a removed building=* tag and the offending preset which caused them to vanish:

Here's a list of editors in Estonia who suffered from this iD behaviour:
J4lamees
martin187
jemm
Сергей Легович
Taffer36
swaan

That's half of Estonian community (yes, it's a small country)

If you still think this is working as most people would expect it to work, then I don't know what else to say.

SviMik on 28 Sep 2019

👍9

Adding amenity=fuel to a building=roof area removes it. That one has been bugging me for a while. It should at least stay in that instance. I've been wasting a lot of time re-adding it when using the name-index presets to update gas station tags.

Adamant36 on 29 Sep 2019

👍1

It sounds to me, that the issue is, that a preset is applied to the wrong existing element. There is a building, it gets the preset "kindergarten". But it should be mapped differently, the building of the kindergarten should stay as is, and a new area should be added around the building, using the preset.

Would you agree, that iDs current behavior results in correctly mapped tags, but wrongly mapped geometries?

I wonder: With the new UI, is there a way to guide the user to the more-correct way of mapping?

Something like…

I click the building
I choose the kindergarten preset
iD switches to area-draw-mode with the dark-gray-help-box saying "draw the area that is used by the kindergarten (around the building)."

Or, maybe go for Nodes …

I click the building
I choose the kindergarten preset
iD switches to a node-UI with the kindergarten presets attached and asks the use to place the node. Or maybe it will place the node inside the center of the building.

(For both of those quick ideas, the question how to extract information like an address from the building is yet to be thought through.)

(https://www.openstreetmap.org/way/53471307/history, https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dkindergarten)

tordans on 29 Sep 2019

My comment from February still stands.

Fuel Stations

@Adamant36 : We recommend that people map fuel stations as areas around the station, not tagged on the building=roof feature. This is because the wiki says to do it that way.

Screenshot 2019-09-29 09 09 05

Schools

@SviMik : We recommend that people map schools as areas around the school grounds, not tagged on a building=school feature. This is because the wiki says to do it that way.

Screenshot 2019-09-29 09 10 19

Honestly it is pretty frustrating that we are still talking about this issue, after I already linked to a bunch of old issues where we patiently explain why iD does what it does, and how we style buildings a consistent way, and how we try to follow the guidelines on the wiki even when it is inconsistent about how POI-like features should be mapped. Just because a few of you you want to put the amenity tag with the building tag on the same feature doesn't make it right.

@tordans