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.

[mmd-osm]

So this issue mainly talks about new users, and at the same time defines a default that applies to everyone. This feels a bit inconsistent to me. How should this work for experienced users? Should they be able to override this default, if so, how?

[matheusgomesms]

Should they be able to override this default, if so, how?

The same way it exists now: enabling it in the menu (right side menu, Map Data, Map Elements).

The idea is that this option is disabled by default, but once the user enables it, then it gets enabled forever (saved in the user's preference), as it happens as of today.

[mmd-osm]

Right, iD does not store this information in the user's preferences, but in the browser's Local Storage (underneath the "disabled-features" key). If we would forcefully disable the boundaries when calling iD (by setting some URL hash parameter), it then really depends which of these two settings takes precedence. It would be bad if we'd be constantly overruling whatever the user has decided for themselves. Has anyone already tried out how iD behaves in that case?

By the way, if the goal is to update some user preferences when toggling the boundaries flag in iD, that would need some support from iD side as well.

For avoidance of doubt, when i talk about user preferences, I'm referring to https://wiki.openstreetmap.org/wiki/API_v0.6#Preferences_of_the_logged-in_user:_GET_/api/0.6/user/preferences

[tordans]

The goal is IMO that all users that have no other settings specified for iD (wherever iD stores them) has smart defaults and one of those smart defaults is to disable boundaries. The few users that know what they are doing (in regards to boundaries) will find the filter and enable the boundaries manually.

However, I agree with Tom from 2021 that those changes are something that the iD Maintainer would ideally look into.