#11775 Validation: Remove layer fixes for building overlaps; recommend level tags#11822
#11775 Validation: Remove layer fixes for building overlaps; recommend level tags#11822ak8abhinay wants to merge 1 commit intoopenstreetmap:developfrom
Conversation
ak8abhinay
force-pushed
the
fix/remove-building-layer-suggestions
branch
from
bd187c3 to
3ded861
Compare
| building-building: | ||
| reference: "Buildings should not intersect except on different layers." | ||
| message: "Buildings should not intersect. If they are vertically stacked, please use the level tag instead of layer." | ||
| reference: "Buildings should not intersect. If they are vertically stacked, please use the **level** tag instead of **layer**." |
There was a problem hiding this comment.
why? If they are in fact vertically stacked buildings then layer is appropriate.
level is for this on different levels (and BTW things on single level may be still vertically stacked)
There was a problem hiding this comment.
is wiki advising this anywhere?
There was a problem hiding this comment.
the Key:layer Wiki page advises for buildings in the final para :
'Ways in buildings... should be mostly described with level= instead of layer.'
After looking at the review, I've realized my current code logic is incomplete. While I've updated the message, the validation still incorrectly allows layer as a fix, which is inconsistent. As these changes were made some time ago, I’d like to take some time to properly review and adjust the implementation.
There was a problem hiding this comment.
'Ways in buildings... should be mostly described with level= instead of layer.'
it refers to ways in buildings, not to buildings themselves
There was a problem hiding this comment.
I am not entirely sure is layer= proper solution of vertically stacked buildings*, but level= is surely not - as it refers to position within a building.
*this is distinct form whether pushing mapper to add fake layer= instead of fixing almost certainly bad geometries is appropriate - hiding "just add layers" when both are buildings makes sense to me
There was a problem hiding this comment.
I understand now. I’ll re-evaluate how overlapping building features should be handled in the validator and adjust the logic accordingly.
| fixes.push(makeChangeLayerFix('higher')); | ||
| fixes.push(makeChangeLayerFix('lower')); | ||
| // For overlapping buildings, do not suggest changing the `layer=*` tag. | ||
| // Vertically stacked buildings should use `level=*` instead. |
There was a problem hiding this comment.
I added the check if (!isBothBuildings) here to specifically disable the 'Make Higher' and 'Make Lower' layer buttons for building-to-building overlaps.
By removing these buttons, we stop the editor from suggesting layer as an automated fix and encourage mappers to handle manual fix or fix the geometry. However, I've realized my current logic is a bit inconsistent since the validator still technically allows the tag, so I will review this and come up with proper implementation
2 participants
This PR modifies the crossing_ways validation logic to prevent the iD Editor from suggesting "Tag as higher" or "Tag as lower" (which adds layer=*) when two building features overlap.
The Problem Currently, mappers often use the "Quick Fix" layer buttons to silence validation warnings for overlapping buildings. This creates "layer soup"—data where buildings are incorrectly marked as floating in the air. Per community best practices and my recommendation [2026-01-15], buildings should stay on layer=0. If they are physically stacked, the level tag is the correct way to map them.
The Fix
Logic: Updated modules/validations/crossing_ways.js to identify building-on-building overlaps and suppress the changeLayer fixes.
Education: Updated the validation message in core.yaml to explicitly guide mappers toward using the level tag instead of layer.
Validation
Verified that "Tag as higher/lower" buttons are hidden for building-building crossings.
Verified that these buttons still appear for valid cases, such as bridges or tunnels (non-building crossings)
Closes #11775