Id: car_repair overwrites building tag

Created on 18 Sep 2020  路  10Comments  路  Source: openstreetmap/iD

If I select a building and choose the preset for "Autowerkstatt" (car repair), ID tags the building with shop=car_repair (correct) but it also overwrites any present building= key with building=yes. This should not happen.

considering

Most helpful comment

Then the intentions are wrong. An OSM editor should never silently remove information from the database without the user's consent. And it doesn't really matter if the user is "supposed to" use presets like that.

All 10 comments

This is intended behavior, see #4315 :(

Then the intentions are wrong. An OSM editor should never silently remove information from the database without the user's consent. And it doesn't really matter if the user is "supposed to" use presets like that.

Hi folks, this is actually a really tricky issue. #4315 is several years old. See #7221 for newer details on this, but I'll elaborate again here.

When you switch presets in iD, you're saying "this feature isn't an instance of Preset A, it's instead an instance of Preset B". So iD naturally removes all the tags defining Preset A, otherwise you'd have old tags piling up every time you switch presets. So when you switch from say, Church Building to Cafe, you're saying "this isn't a Church Building". iD removes the information you asked it to remove鈥攊t's not silently removing anything.

The problem is that buildings are special in OSM. You can say "this is a Church Building, but it is also a Cafe" (which arguably violates the "one feature one element" principle). When you're using the preset switcher in iD, you might have it in your head that you just want to add the Cafe, but you're in fact swapping out the Church Building like any other preset.

While we could theoretically make the switcher work differently for these cases, I contend that inconsistency would be confusing for many mappers. There's a good chance the feature was never a Church Building in the first place. If the preset change is simply a correction, then retaining the building value would be wrong.

As you point out yourself, buildings and POIs are independent of each other in OSM. I do understand that you want consistency in how ID behaves when you select a preset. In my opinion the solution should be that building presets and POI presets should behave independently from each other. This means that the car repair preset should not contain a building tag and building presets should only contain building-related tags, no POI tags.

So the workflow for a church would be to first select the church preset and then select the place of worship preset or the cafe preset, depending on what the church building is used for.

What do you think?

Apart from that I think that ID should always give a message when a preset overwrites existing tags, like Vespucci does for example.

While we could theoretically make the switcher work differently for these cases, I contend that inconsistency would be confusing for many mappers. There's a good chance the feature was never a Church Building in the first place. If the preset change is simply a correction, then retaining the building value would be wrong.

Note that it already works specially by deleting detailed building tag but keeping building=yes.

Maybe a good idea would be to keep detailed building value but display in the left menu "this object is still tagged as church building" with buttons "this is correct" and "change to unspecific building type"?

Or have popup asking for that decision but it would be likely to annoying (or maybe not? How often it is done? Probably not many times in row)

A good solution would be not to connect the POI with the building.

A good solution would be not to connect the POI with the building.

This is common mapping practice supported by wiki documentation and nothing we can change in this issue.

Any progress here? With the current behavior iD is slowly degrading OSM's data quality.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

bhousel picture bhousel  路  3Comments

tordans picture tordans  路  3Comments

tordans picture tordans  路  3Comments

tordans picture tordans  路  3Comments

jidanni picture jidanni  路  3Comments