prevent survey markers from being moved #10122
Conversation
| survey_point: true | ||
| }, | ||
| latitude: true, | ||
| longitude: true, |
There was a problem hiding this comment.
I'm not sure if encouraging these two keys is a good idea, since most appear to be introduced by bodged imports
There was a problem hiding this comment.
Yeah, I could see this legitimizing the two keys as a “one weird trick” for locking a feature. Imagine someone pranking other mappers by adding a longitude to all the POIs they map. It would never show up in the fields, only the raw tags, hidden by default.
There was a problem hiding this comment.
Should we apply any styling to the point on the map, so that it looks locked before the user tries to futz with it?
Lines 296 to 304 in b5f1f78
Will mappers get annoyed that they can’t move the point and delete it instead? A wikidata=* tag locks a feature from getting deleted too.
| @@ -232,6 +232,9 @@ export function modeDragNode(context) { | |||
| isInvalid = hasInvalidGeometry(entity, context.graph()); | |||
| } | |||
|
|
|||
| if (entity.type === 'node' && entity.isLocked()) { | |||
There was a problem hiding this comment.
Would it be feasible to allow the drag when some modifier key is held down, like Alt/Option, when the mapper is sure they know what they’re doing? If not, another approach would be to create a filter for things like survey points and hide it by default, as we do with boundaries.
/ref #9255 (comment)
| survey_point: true | ||
| }, | ||
| latitude: true, | ||
| longitude: true, |
There was a problem hiding this comment.
Yeah, I could see this legitimizing the two keys as a “one weird trick” for locking a feature. Imagine someone pranking other mappers by adding a longitude to all the POIs they map. It would never show up in the fields, only the raw tags, hidden by default.
|
All your suggestions seem like good ideas, I'll wait and see if there are any other comments before making changes.
I'm pretty sure it's possible since we have access to |
There was a problem hiding this comment.
This looks like a reasonable behavior for iD. Yes, not every survey point mapped in OSM was imported from a source with authoritative precision, but I would say that accidentally moved survey points are a bigger issue than misplaced survey points which are not correctable easily in iD. An override for advanced users to still edit the location of such points would be nice to have, but a relatively easy workaround is to just change the feature temporarily to a different preset while moving.
I'd also exclude latitude/longitude from the tags for this feature. 👍
As far as I see, it does not fully fix the issue reported in #9255, as the validation warning is still shown. Perhaps the validation should not be triggered when all of the affected entities are locked.
True, it isn’t a big inconvenience in the grand scheme of things. However, the lock design seems superficially like the Wikidata lock, except that it locks something other than a field that can actually get in the way when mapping – and it doesn’t protect the feature from getting deleted. Will we consider using the same affordance for anything else? Conceptually, I don’t see a difference between these survey points and other things that non-experts should think twice before touching, such as boundaries and (takes a deep breath) abandoned railways. A filter would be a more robust solution to this problem, because the user has an opportunity to keep immovable features from cluttering the map as they map other types of features around them. A filter wasn’t an option for Wikidata-tagged features because that’s a secondary attribute. |
Closes #9255, Closes #9867