Only the first node's position can be adjusted when a way is being created, not the next ones'

[PontiacCZ]

Vespucci Version 15.1.6

Download source: Google Play

Device (Manufacturer and Model): CAT S61

Android Version: 9

Behaviour/Symptoms

When creating a new way, I can adjust the position of the first node by tapping inside the dashed circle and moving. When I place second node (and next ones), using the same operation the whole map is panned instead.

Expected Behaviour

I expect to be able to reposition every freshly placed node surrounded by a dashed circle.

How to recreate

1. Start creating a new way in Vespucci - unlock, long tap on the desired spot and tap the plus symbol.
2. You are in the creating path mode and your node is surrounded by a dashed circle.
3. Try to move this first node - it is possible (when you touch the screen outside the circle, you pan the map which is expected)
4. Create a second node of the path by tapping somewhere on the screen.
5. Try to move this second node - you pan the whole map instead.

Crash dump submitted (no or yes + date)

No.

Any other potentially relevant information

[simonpoole]

This is related to https://github.com/MarcusWolschon/osmeditor4android/issues/1316 in the mean time I've addressed this, however it still wouldn't do what you want, because for all practical purposes it is treated just as a multiselect. That is both the "current" node and the way is moved (it just seems to be different for the first node because there is no way that could be moved).

So this potentially needs some more thinking what the desirable behaviour could be as both variants (moving everything, and moving just the node) are legit.

[PontiacCZ]

both variants (moving everything, and moving just the node) are legit.

I agree that both variants are legit and they are possible when the first node is drawn (as I write in step 3). It just does not work with following created nodes - you are then only able to move the node.

[simonpoole]

https://github.com/MarcusWolschon/osmeditor4android/commit/d26b13e5310ebf89b195a94c805a05877bd662f4 allows dragging of the whole way without creating a new undo checkpoint.

[Lee-Carre]

Suggested alternatives (‘workarounds’):

• place nodes individually, first, before making the way (or using the first few to make a placeholder way (with relevant tagging) which is then easy to extend / append with later nodes); they can then be repositioned individually at the time of placing them; this worked very well for adding a(n unmapped) footpath which I was walking by dropping nodes via the new-node-at-GNSS-position at places where the path angle was non-straight, so that placement was more accurate than by-hand, to then easily be able to do a dot-to-dot when extending (appending) the way every so often (and with the placeholder way pre-tagged, once I'd added the last node I just had to remove the just-in-case fixme, and it was ready to upload 🙂
• when placing nodes as part of making a new way, place them roughly / crudely, then after having made the way (& tagged it, while thinking about it, before context-switching (to)) refine the position of individual nodes; this works well for outlines (buildings (hence the squaring function), areas)

I find that either of these gives more control; that is, I'm more certain of Vespucci doing as I intend & expect (based on its current interaction model), because what I'm instructing is clear / unambiguous.

There seems to be an inherent ambiguity in interaction-design on a touch-display; how does one (in this case) differentiate between adding more nodes, moving the way, and moving individual nodes? On a micro-computer, the classic would be to hold one of (Control|Alt|Shift|Meta|Hyper) while clicking / dragging, to change which function was performed. Else left-click vs. right-click / middle-click. Obviously can't do any of that (normally) on Android. Thus, the interaction design has to account for this, such as with unambiguous input modes or such.

Even if the OP's request were implemented, I can foresee some users being utterly confused & frustrated by it; the UI doing something other than what they intended & expected (‘why's it moving the node?(!) I wanted to add a new node to the way’).

I speak from experience; took me a while to figure out how to insert a node into a way (without otherwise changing its geometry). I had assumed that it would have to be a multi-step process, so the UI making unclear assumptions & partially-automating it was unexpected & mysterious (especially since I was not in simple-mode). Once I figured it out, and better grokked the UI / editing model, I could see why it was designed that way. But, not as a newbie (and the documentation didn't help at all; unclear, assumed knowledge / familiarity).

This isn't the only case type, either; getting it to preserve ways (when modifying geometry), rather then delete & recreate, has been tricky, too.

Now, the same (over-)helpful behaviour is a problem when trying to add a node near a way (but not part of the way), such as a bench or defibrillator near a wall. It'll often snap-to, when that's not desirable. So, have to work around that, often.

Perhaps, looking more broadly for a moment, this should be something that depends on if simple-mode is enabled or not. When simple-mode is enabled, also enable the various trying-to-be-helpful UI behaviours (auto joining, snap-to, etc.) but with simple-mode disabled then so are the semi-automation features for much more granular control (joining nodes would then be manually-required).

However, since that would change existing UI behaviour (with which current users are already familiar), I can see reasons for not doing it. Except, perhaps, as a redesign, with a rename: power-user-mode or auto-complete-mode, or similar to indicate that functionality has changed.