Disable boundaries in iD by default

[1ec5]

Boundaries can be difficult to edit correctly. Often a new user ends up munging a boundary by accident, especially if it is connected to another feature.

An example standalone version of iD addresses this usability issue by hiding the boundary layer by default if no disable_features parameter is included in the URL hash. Users who feel confident editing the boundary layer can enable it in the Map Data panel, and iD will remember the setting across sessions.

https://github.com/openstreetmap/iD/blob/70a117a38cfaf5518d0099adf70816bc5d196138/dist/index.html#L49-L53

The iD project has received requests for the instance embedded on osm.org to do the same: openstreetmap/iD#8454. However, since the need to disable boundaries is specific to an OSM environment where new users frequent, the least risky, most straightforward implementation would be in this repository, either right after this statement:

openstreetmap-website/app/assets/javascripts/id.js

Lines 23 to 29 in 5662220

	var id = idContext
	.embed(true)
	.assetPath("iD/")
	.assetMap(JSON.parse(container.dataset.assetMap))
	.locale(container.dataset.locale)
	.containerNode(container)
	.init();

or as an else right here, where the application translates its own disabled_features parameter into one that iD understands:

openstreetmap-website/app/assets/javascripts/edit/id.js.erb

Line 26 in 5662220

if (hashParams.disable_features) params.disable_features = hashParams.disable_features;

[tomhughes]

Surely disabling boundaries is just as dangerous, if not more so, as you can wind up editing something that you don't even know exists if it shares nodes/ways with other features?

[matheusgomesms]

Surely disabling boundaries is just as dangerous, if not more so, as you can wind up editing something that you don't even know exists if it shares nodes/ways with other features?

Doesn't iD block editing any feature when a boundary is connected to it but is invisible?

[1ec5]

Correct. In that case, iD will advise the user to enable the boundary layer if they really want to move or delete the shared node. This is preferable to munging a boundary they might not even notice because of an overlapping feature. There’s considerable debate about what can legitimately be connected to a boundary, if anything, but this request is specifically intended to prevent mistakes that can arise even when there’s consensus that something should be connected.

One possible downside is that we might start to get questions on the forum along the lines of: I wanted to edit a boundary I see on [osm-carto], but I can’t see it when opening [iD]. Hopefully the “n hidden features” indicator in the status bar will clue in some mappers though.

[AntMadeira]

That or produce an info box stating that boundaries should only be edited with caution and after activating the boundary layer.

One possible downside is that we might start to get questions on the forum along the lines of: I wanted to edit a boundary I see on [osm-carto], but I can’t see it when opening [iD]. Hopefully the “n hidden features” indicator in the status bar will clue in some mappers though.

[AntMadeira]

Surely disabling boundaries is just as dangerous, if not more so, as you can wind up editing something that you don't even know exists if it shares nodes/ways with other features?

Doesn't iD block editing any feature when a boundary is connected to it but is invisible?

Yes, it does.
So, it's just a matter of disabling that layer by default.