To avoid moving features unintentionally, as I’v seen happened atlist once and happened to me aswell, I suggest enabling navigation only with the arrow keys and pointing that out clearly, to minimize oversight error potential.
Alternatively, perhaps existing edit mode without making any edits easier, as with GIS software ‘Editing layer’ option toggling, so while navigating you’d exit editing mode.
Cannot replicate in JOSM unless the mouse is right on the selected object. If it’s not, it releases any selected object while left mouse holding and outlines and area (lasso) which then results in selecting everything in that area. Right mouse button holding pans the background/map.
But yes, at times the repair man in me needs to come out and run a revert on a node drag, which I think is distance limited. Greater than N and you get a warning. and are asked to confirm. Most of the times its flagged in QA because something starts crossing something else, a building node across the road, a road across a road witout connect and more.
I assume you’re referring to iD, which allows you to move a point (independent node) by dragging it? iD can’t require the user to pan the map using the arrow keys exclusively, as it also supports touchscreen tablets that may or may not have physical keyboards. Only a minority of users have multitouch input devices that support two-finger swipe as an alternative.
Separate selection and editing modes are common in graphics editing software, and separate left-drag and right-drag bindings are common in GIS software (hence JOSM’s design), but both affordances are extremely unfamiliar to laypeople, who will likely cause other problems in their confusion. By analogy, how many of us would cope with vim mode here on this forum? Instead of such a drastic change, we could mitigate the risk of accidental drags by requiring an extra click or hold gesture to move a point:
Okay I know this is just one post, but I saw the GitHub post too and no one is pushing back yet, so thought it was useful to have some other opinions.
I have reviewed hundreds and hundreds of change sets in the last few months, there are definitely people that mistakenly drag nodes, but it’s not such a major problem worthy of invasive changes to the ID editor! What has been suggested so far are tedious annoyances that might help reduce dragged nodes, but there are a lot of annoying things that could reduce errors. What if in ID any time you move anything a pop-up that asks “did you mean to move that?”.
I wonder if people would feel the same if JOSM did this? If JOSM made it so you wait 1s before you could drag a node, or you click on two times to select it first? Clicking 2 times or clicking.. waiting.. then moving your mouse is just unintuitive design. Changes like this would handicap everyone that uses ID, especially more advanced users.
We should strive for smarter changes that target the specific destructive behavior without degrading the tools and editor for everyone else.
I can think of better solutions: (Just off the top of my head)
Make it work like JOSM and other GIS software, Right click to select nodes and drag them, Left click to pan around the map. (For touch screen support I believe modern browsers can detect input types for touch/mouse).
If the warning message is shown that paths are crossed when publishing, make it so the user clicks it to go to the location and see a highlight the error, then make them confirm its correct before publishing. Another nice thing would be having an undo button right there to move the node back to its original location.
Have some detection if a node is moved an unusual distance even if it crosses nothing! This could also be a warning at publish time that must manually be confirmed correct too. Seem like this user (user_5359) might detect and filter for users that that move nodes “more than 100 meters over streets and buildings” https://www.openstreetmap.org/changeset/17277187
I hope this suggestion does not get traction, but if it does, this should be a user preference that can be shut off for users that don’t want to double click or wait around just to move nodes.
PS: I was mostly responding to the suggestions in that github post here for some reason, Sorry I didn’t make that clear and also if that makes no sense, just got fired up!
I definitely agree that we should maintain a sense of perspective. My suggestion was aimed at keeping the impact as light as possible, knowing that changing workflows is always hard no matter what. I think it’s less disruptive than nixing the ability to move the map at all, but I’m not wedded to my particular suggestion if there are better ones.
I edit OSM almost exclusively in iD, so I can’t speak to how JOSM users would feel. I would turn this question around and ask how iD users would feel if they had to go out of their way to pan the map. A typical user pans the map so much more often than they move an existing point around.
To me, this sounds like a solution only a JOSM user would ever find reasonable, but maybe I’ve just gotten burned too much as both a mapper and reviewer:
Or maybe because I use a Mac, so “right-click” dragging requires me to hold down the Control key. (Repetitive stress injury, now on two hands!) It’s one of the reasons I only fire up JOSM when I absolutely have to.
Unfortunately not very well. iD no longer supports two-finger panning in Firefox because of difficulties in detecting input types. Rapid resorted to making it a preference.
iD already requires you to select a way before you can move a node connected to the way. To the extent that users still move these nodes by accident, warnings about crossing ways appear immediately in the sidebar, before you click Save. If the move would cause the geometry of a route or other relation to become malformed, the cursor changes to a 
and the move gets undone automatically as soon as you release the mouse button.
If despite all that you do click Save, the same warnings about crossing ways appear. Clicking the warning cancels the save, navigates to the location of the problem, and selects one of the crossing ways. iD doesn’t support undoing individual operations out of order, other than for tag changes via the 
button above each field. Out-of-order undoing is a very nice feature in StreetComplete but trickier to implement safely in a more freeform editor.
JOSM has this warning, mainly because even power users rocking Expert Mode occasionally mix up their left and right mouse buttons. More broadly, iD’s validator is only capable of detecting problems in the current state of the editing session, not suspicious changes from the previous state to the current one. Some other component in iD would be capable of flagging a distant move, similar to the relation breakage I mentioned earlier, but someone would have to come up with a respectable UI for confirming such a move. Inevitably, a power user would come out of the woodwork to complain that it would hobble power users.
Now that I’ve finally gotten to train meself on Vespucci, bye bye ID on the tablet. Asked recently for multi-select, got long silence and then my ticket was closed noting that a 5+ years ticket for same was still open. Hopes thus ZERO. The Vespucci solution is elegant. A simple double tab to activate the multi-select to allow things like multi-object tag editing, moving, merging and so on.
Thanks for a thoughtful response! I’m also almost exclusively in iD, but I use a lot of other software like 3D modeling and 2D photo/vector editors, and and your right, its very common to have select and pan 2 different buttons/key combinations.
I was back and forth whether I should include my “better solutions” because I didn’t want to focus on my ideas since they were really just want came to mind first! But decided to add it since I wanted to give constructive feedback rather then bash an Idea with no alternative idea. I believe this issue can be solve in a smarter way!
So I might not have a solution, But I believe the click to select node before moving or a wait timer is not great either!
Wanted to respond too this though:
That doesn’t seem to be true for nodes at the ends of ways, or where two ways connect. So Unless something visually changes like hiding those nodes too when the way is not selected, I think it would be confusing. Sometimes you can move a node when you see it, sometimes you have to click two times? That’s not what I would expect as a new user to a piece of software.
Does that mean its not be possible to setup a warning in iD to detect If a node is moved to the other side of the county?
Does that also mean in this case instead of undoing, there would be no way to just make a NEW move back to the original location?
I appreciate the gut-check. Half the time I’m surprised no one has suggested something before, there’s a good reason for that. 
Oh, that’s true. It’s only the intermediate nodes (and the midpoints) that require you to select the way first. I think it was designed like that to give some indication that two ways connect, and so that indicator would naturally be interactive. I was basically supposing that any visible node would require a selection or pause before being movable.
Anything is possible technically. It’s just that the current validator architecture is only set up for stateless checks. Even so, there have been a slew of bugs about stale warnings over the past few years, so someone would probably need to really take a deep look at that part of the code and maybe rewrite it while they’re at it.
Also technically possible, but somehow users would need to intuit the difference between undoing and reverting on their own, since the UI doesn’t expose an undo list. This sounds very similar to a feature I secretly long for: undoing a deletion I made by mistake before saving, without having to undo a bunch of other changes.
Either way, it’s something that people have wanted for a long time, for a variety of reasons. The original developers apparently weren’t fond of Potlatch’s implementation:
Maybe it needs modifying so that if you have done something that has created warnings, then that CS can’t be uploaded?
Would help prevent a lot of vandalism, as seen in Israel last year!
There are three classes of issues:
Errors in red. You can’t save when there’s an error. For example, a way is untagged and doesn’t belong to any relation. The user likely forgot to come back and choose a preset. There’s pretty much no good reason to leave the way in that state.
Warnings in yellow. You can save when there are warnings, but your decision to ignore the warnings will be recorded on the changeset’s tags. For example, a road crossing a stream without a ford, bridge, or tunnel. If we force the user to resolve the issue before saving, there’s a risk that they’ll just guess, creating a hazard for end users. If in doubt, better to leave it ambiguous so full-fledged validators can flag it to someone who might have more local knowledge.
Suggestions in blue. There are no consequences to ignoring a suggestion. For example, a pedestrian crossing lacks one of the newer, more detailed crossing tags. Without examining element history, who’s to say anything is wrong? But there’s specific room for improvement.
Not a chance. They’d just move on to a different tool that would let them make even more of a mess. An editor’s built-in validator can only prevent its user from committing the most casual forms of vandalism.
Why not assign panning to a special keyboard key like spacebar and remove the panning option from the mouse? this way no features could be selected
Panning is one of the most frequent things people do in iD. Requiring the keyboard for it would severely hamper routine usage.