Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QEP 69: Improved Node Tool #69

Open
wonder-sk opened this Issue Aug 26, 2016 · 55 comments

Comments

Projects
None yet
@wonder-sk
Copy link
Member

wonder-sk commented Aug 26, 2016

QGIS Enhancement 69: Improved Node Tool

Date 2016/08/26

Author Martin Dobias (@wonder-sk)

Contact wonder dot sk at gmail dot com

Maintainer @wonder-sk

Version QGIS 3.0

Summary

Node tool is an important map tool for editing of geometries. There are however various shortcomings
in the existing tool:

  • it is not possible to use advanced digitizing dock for precise moving of nodes
  • old snapping classes are used, accounting for slower performance and preventing removal of the old code
  • features need to be explicitly selected before editing of nodes is possible
  • editing of features from multiple layers requires switching between active layers
  • extension of linestrings is not possible
  • there is no feedback on mouse over

Proposed Solution

The plan is to replace the existing node tool implementation with a new one that addresses the above issues.

Implementation of a possible replacement has been developed as a QGIS python plugin which is available here:
https://github.com/wonder-sk/CadNodeTool

The existing python plugin would be ported to C++ and further extended where it still lacks full support
(e.g. for circular geometries)

Using Node Tool

A brief introduction on how the node tool works:

  1. Moving the mouse around will highlight features/nodes that may be moved (from any layer that is editable)

    nodetool - step 1- highlight

  2. Clicking a highlighted node will start moving it (any editable layer may be used). Nodes that are at the same position will be moved if topological editing is enabled.

    nodetool - step 2 - moving

  3. Nodes can be added by hovering over a segment and clicking the marker that appears in the middle.

    nodetool - step 3 - addition

  4. Another way to add vertex is to double-click on a segment (away from the mid-point)

  5. Segments can be moved by single click on a segment.

  6. Linestrings can be expanded by clicking marker that appears near the endpoints of linestring features.

    nodetool - expand

  7. Node coordinates may be edited using advanced digitizing dock.

    nodetool - advanced digitizing tools

  8. Nodes can be removed by pressing Del key while a node is being moved. Also, nodes can get selected by dragging a selection rectangle and pressing Del afterwards. Whenever a node is selected, next node from the same feature is pre-selected, allowing for quick removal of several nodes in a row.

  9. Topological editing is respected, so if it is enabled, nodes of different features at the same position
    are moved together. The features may be even coming from different layers, they are moved together as long as the layers are in editing mode.

    nodetool - topo editing

  10. Ctrl+click to highlight vertex without going to dragging mode (for deletion and for node editor integration)

Performance Implications

The node tool should become faster thanks to the use of new snapping classes.

Further Considerations/Improvements

Press/Release vs Click/Click

To move nodes with the existing node tool implementation:

  1. user presses the left mouse button on a node,
  2. drags the node (with mouse button still being pressed),
  3. releases the button to place the node.

The new node tool would change this into slightly different pattern:

  1. user clicks mouse button on a node,
  2. drags the node (mouse button is released all the time),
  3. clicks again to place the node (left click to accept, right click to cancel the change)

This change is necessary to allow the use of advanced digitizing dock in order to enter values. After little bit of testing, this approach feels very natural and has further advantages compared to the existing behavior:

  1. it is easier to precisely place nodes (not having to apply force to the mouse button all the time)
  2. one does not move nodes inadvertently
  3. it is possible to cancel the operation
  4. it allows to pan the map by pressing space bar while the node is being moved

Node Editor

As the new node tool does not have a concept of selected features, it is questionable whether it makes sense to keep the node editor dock widget tied to node tool. Numeric editing of X/Y coordinates is more easily done with advanced digitizing dock, but Z/M coordinates not covered. It is suggested that node editor would be available from identify tool, possibly also still having it integrated with new node tool, showing coordinates of the most recently used feature. The suggestion is that the node editor dock is hidden by default.

Backwards Compatibility

No problem at the code level - the existing node tool has lived within app source code, so there is not problem with backward compatibility.

Votes

TODO

@NathanW2

This comment has been minimized.

Copy link
Member

NathanW2 commented Aug 26, 2016

+1 Nice

On Fri, Aug 26, 2016 at 6:55 PM, Martin Dobias notifications@github.com
wrote:

QGIS Enhancement: Improved Node Tool

Date 2016/08/26

Author Martin Dobias (@wonder-sk https://github.com/wonder-sk)

Contact wonder dot sk at gmail dot com

Maintainer @wonder-sk https://github.com/wonder-sk

Version QGIS 3.0
Summary

Node tool is an important map tool for editing of geometries. There are
however various shortcomings
in the existing tool:

  • it is not possible to use advanced digitizing dock for precise
    moving of nodes
  • old snapping classes are used, accounting for slower performance and
    preventing removal of the old code
  • features need to be explicitly selected before editing of nodes is
    possible
  • editing of features from multiple layers requires switching between
    active layers
  • extension of linestrings is not possible
  • there is no feedback on mouse over

Proposed Solution

The plan is to replace the existing node tool implementation with a new
one that addresses the above issues.

Implementation of a possible replacement has been developed as a QGIS
python plugin which is available here:
https://github.com/wonder-sk/CadNodeTool

The existing python plugin would be ported to C++ and further extended
where it still lacks full support
(e.g. for circular geometries)
Using Node Tool

A brief introduction on how the node tool works:

Moving the mouse around will highlight features/nodes that may be
moved (from any layer that is editable)

[image: nodetool - step 1- highlight]
https://cloud.githubusercontent.com/assets/193367/17999737/2bddba2c-6bad-11e6-901c-5d260fb1dde2.gif
2.

Clicking a highlighted node will start moving it (any editable layer
may be used). Nodes that are at the same position will be moved if
topological editing is enabled.

[image: nodetool - step 2 - moving]
https://cloud.githubusercontent.com/assets/193367/17999746/3541fe20-6bad-11e6-8d20-11944a06cade.gif
3.

Nodes can be added by hovering over a segment and clicking the marker
that appears in the middle.

[image: nodetool - step 3 - addition]
https://cloud.githubusercontent.com/assets/193367/17999754/3d87256a-6bad-11e6-8d7f-a81781f27157.gif
4.

Linestrings can be expanded by clicking marker that appears near the
endpoints of linestring features.

[image: nodetool - expand]
https://cloud.githubusercontent.com/assets/193367/17999762/47af7f42-6bad-11e6-8b81-b97ff5ed63a5.gif
5.

Node coordinates may be edited using advanced digitizing dock.

[image: nodetool - advanced digitizing tools]
https://cloud.githubusercontent.com/assets/193367/17999766/4cb4a8a0-6bad-11e6-81b7-81503c31af5a.gif
6.

Nodes can be removed by pressing Del key while a node is being moved.
Also, nodes can get selected by dragging a selection rectangle and pressing
Del afterwards. Whenever a node is delected, next node from the same
feature is pre-selected, allowing for quick removal of several nodes in a
row.
7.

Topological editing is respected, so if it is enabled, nodes of
different features at the same position
are moved together.

Performance Implications

The node tool should become faster thanks to the use of new snapping
classes.
Further Considerations/Improvements Press/Release vs Click/Click

To move nodes with the existing node tool implementation:

  1. user presses the left mouse button on a node,
  2. drags the node (with mouse button still being pressed),
  3. releases the button to place the node.

The new node tool would change this into slightly different pattern:

  1. user clicks mouse button on a node,
  2. drags the node (mouse button is released all the time),
  3. clicks again to place the node (left click to accept, right click
    to cancel the change)

This change is necessary to allow the use of advanced digitizing dock in
order to enter values. After little bit of testing, this approach feels
very natural and has further advantages compared to the existing behavior:

  1. it is easier to precisely place nodes (not having to apply force to
    the mouse button all the time)
  2. one does not move nodes inadvertently
  3. it is possible to cancel the operation
  4. it allows to pan the map by pressing space bar while the node is
    being moved

Node Editor

As the new node tool does not have a concept of selected features, it is
questionable whether it makes sense to keep the node editor dock widget
tied to node tool. Numeric editing of X/Y coordinates is more easily done
with advanced digitizing dock, but Z/M coordinates not covered. It is
suggested that node editor would be available from identify tool, possibly
also still having it integrated with new node tool, showing coordinates of
the most recently used feature. The suggestion is that the node editor dock
is hidden by default.
Backwards Compatibility

No problem at the code level - the existing node tool has lived within app
source code, so there is not problem with backward compatibility.
Votes

TODO


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#69, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAXS3LWN_4mxmr6dX-dL6r06UDkiYo8Qks5qjqntgaJpZM4Jt349
.

@sbrunner

This comment has been minimized.

Copy link

sbrunner commented Aug 26, 2016

+1 looks really good :-)

@NathanW2

This comment has been minimized.

Copy link
Member

NathanW2 commented Aug 26, 2016

The Click-Click style editing though could trip up users however as this is
for 3.0 I think we can expect that kind of change.

On Fri, Aug 26, 2016 at 6:59 PM, Nathan Woodrow madmanwoo@gmail.com wrote:

+1 Nice

On Fri, Aug 26, 2016 at 6:55 PM, Martin Dobias notifications@github.com
wrote:

QGIS Enhancement: Improved Node Tool

Date 2016/08/26

Author Martin Dobias (@wonder-sk https://github.com/wonder-sk)

Contact wonder dot sk at gmail dot com

Maintainer @wonder-sk https://github.com/wonder-sk

Version QGIS 3.0
Summary

Node tool is an important map tool for editing of geometries. There are
however various shortcomings
in the existing tool:

  • it is not possible to use advanced digitizing dock for precise
    moving of nodes
  • old snapping classes are used, accounting for slower performance
    and preventing removal of the old code
  • features need to be explicitly selected before editing of nodes is
    possible
  • editing of features from multiple layers requires switching between
    active layers
  • extension of linestrings is not possible
  • there is no feedback on mouse over

Proposed Solution

The plan is to replace the existing node tool implementation with a new
one that addresses the above issues.

Implementation of a possible replacement has been developed as a QGIS
python plugin which is available here:
https://github.com/wonder-sk/CadNodeTool

The existing python plugin would be ported to C++ and further extended
where it still lacks full support
(e.g. for circular geometries)
Using Node Tool

A brief introduction on how the node tool works:

Moving the mouse around will highlight features/nodes that may be
moved (from any layer that is editable)

[image: nodetool - step 1- highlight]
https://cloud.githubusercontent.com/assets/193367/17999737/2bddba2c-6bad-11e6-901c-5d260fb1dde2.gif
2.

Clicking a highlighted node will start moving it (any editable layer
may be used). Nodes that are at the same position will be moved if
topological editing is enabled.

[image: nodetool - step 2 - moving]
https://cloud.githubusercontent.com/assets/193367/17999746/3541fe20-6bad-11e6-8d20-11944a06cade.gif
3.

Nodes can be added by hovering over a segment and clicking the marker
that appears in the middle.

[image: nodetool - step 3 - addition]
https://cloud.githubusercontent.com/assets/193367/17999754/3d87256a-6bad-11e6-8d7f-a81781f27157.gif
4.

Linestrings can be expanded by clicking marker that appears near the
endpoints of linestring features.

[image: nodetool - expand]
https://cloud.githubusercontent.com/assets/193367/17999762/47af7f42-6bad-11e6-8b81-b97ff5ed63a5.gif
5.

Node coordinates may be edited using advanced digitizing dock.

[image: nodetool - advanced digitizing tools]
https://cloud.githubusercontent.com/assets/193367/17999766/4cb4a8a0-6bad-11e6-81b7-81503c31af5a.gif
6.

Nodes can be removed by pressing Del key while a node is being moved.
Also, nodes can get selected by dragging a selection rectangle and pressing
Del afterwards. Whenever a node is delected, next node from the same
feature is pre-selected, allowing for quick removal of several nodes in a
row.
7.

Topological editing is respected, so if it is enabled, nodes of
different features at the same position
are moved together.

Performance Implications

The node tool should become faster thanks to the use of new snapping
classes.
Further Considerations/Improvements Press/Release vs Click/Click

To move nodes with the existing node tool implementation:

  1. user presses the left mouse button on a node,
  2. drags the node (with mouse button still being pressed),
  3. releases the button to place the node.

The new node tool would change this into slightly different pattern:

  1. user clicks mouse button on a node,
  2. drags the node (mouse button is released all the time),
  3. clicks again to place the node (left click to accept, right click
    to cancel the change)

This change is necessary to allow the use of advanced digitizing dock in
order to enter values. After little bit of testing, this approach feels
very natural and has further advantages compared to the existing behavior:

  1. it is easier to precisely place nodes (not having to apply force
    to the mouse button all the time)
  2. one does not move nodes inadvertently
  3. it is possible to cancel the operation
  4. it allows to pan the map by pressing space bar while the node is
    being moved

Node Editor

As the new node tool does not have a concept of selected features, it is
questionable whether it makes sense to keep the node editor dock widget
tied to node tool. Numeric editing of X/Y coordinates is more easily done
with advanced digitizing dock, but Z/M coordinates not covered. It is
suggested that node editor would be available from identify tool, possibly
also still having it integrated with new node tool, showing coordinates of
the most recently used feature. The suggestion is that the node editor dock
is hidden by default.
Backwards Compatibility

No problem at the code level - the existing node tool has lived within
app source code, so there is not problem with backward compatibility.
Votes

TODO


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#69, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAXS3LWN_4mxmr6dX-dL6r06UDkiYo8Qks5qjqntgaJpZM4Jt349
.

@nirvn

This comment has been minimized.

Copy link

nirvn commented Aug 26, 2016

Number 4 and number 7 are of upmost excitement 😄

@3nids

This comment has been minimized.

Copy link
Member

3nids commented Aug 26, 2016

this is an excellent job @wonder-sk

I have been testing the plugin and it works like a charm.

@andreasneumann

This comment has been minimized.

Copy link
Member

andreasneumann commented Aug 26, 2016

Very nice - looking forward to having this in QGIS core!

@nyalldawson

This comment has been minimized.

Copy link

nyalldawson commented Aug 26, 2016

What about moving segments? That's possible using the current tool but doesn't seem included here.

Otherwise big +1

@nyalldawson

This comment has been minimized.

Copy link

nyalldawson commented Aug 26, 2016

Another question: there's no mention here of selecting multiple nodes and moving as a group. I'm very much against losing that capability (I use it frequently).

@nyalldawson

This comment has been minimized.

Copy link

nyalldawson commented Aug 26, 2016

The suggestion is that the node editor dock is hidden by default.

I think we need this part sorted out before moving forward here too. Currently the node editor dock is the easiest (only?) way to precisely create a point at an exact x/y coordinate.

@wonder-sk

This comment has been minimized.

Copy link
Member Author

wonder-sk commented Aug 26, 2016

What about moving segments? That's possible using the current tool but doesn't seem included here.

Another question: there's no mention here of selecting multiple nodes and moving as a group. I'm very much against losing that capability (I use it frequently).

I have a plan for moving of multiple nodes (using the selection just like when removing nodes). For moving of segments, I am unsure if this functionality is really necessary - and it can be done by selecting nodes and moving them afterwards. There is a ticket about it wonder-sk/CadNodeTool#5. But I do not have a strong opinion about it. Moving of segments just does not seem to be that frequent operation (e.g. in inkscape one also needs to select nodes by rectangle to move the whole segment).

Currently the node editor dock is the easiest (only?) way to precisely create a point at an exact x/y coordinate.

It is possible to use advanced digitizing dock for exact x/y coordinate addition/editing...

@nyalldawson

This comment has been minimized.

Copy link

nyalldawson commented Aug 26, 2016

I have a plan for moving of multiple nodes (using the selection just like when removing nodes).

Good to hear :)

For moving of segments, I am unsure if this functionality is really necessary - and it can be done by selecting nodes and moving them afterwards. There is a ticket about it wonder-sk/CadNodeTool#5. But I do not have a strong opinion about it. Moving of segments just does not seem to be that frequent operation

I'd like to see this feature survive in some form (like I said.. I use it a lot, and regressions like this were one of the reasons I was so strongly against the previous click-click implementation for the node tool). Couldn't we make it that clicking a segment when the mouse ISN'T over the phantom central new node point switch to moving that segment? Ie - hover over a segment, both the segment is highlighted and the add new node point appears, and depending on whether the click is on this central point it's either add a new node or move the segment.

(e.g. in inkscape one also needs to select nodes by rectangle to move the whole segment).

Let's not base ANY ux decisions on how Inkscape does stuff. IMO Inkscape's workflow is very unnatural, and needs to be "learnt" (rather than being intuitive).

Hope this doesn't sound negative... I'm very much in favour of these improvements, I just want to make sure we end up with the most powerful friendly tool possible.

@nyalldawson

This comment has been minimized.

Copy link

nyalldawson commented Aug 26, 2016

It is possible to use advanced digitizing dock for exact x/y coordinate addition/editing...

True, but it's not the easiest approach. Should we just make the node editor its own tool?

@3nids

This comment has been minimized.

Copy link
Member

3nids commented Aug 26, 2016

I'd like to see this feature survive in some form (like I said.. I use it a lot, and regressions like this were one of the reasons I was so strongly against the previous click-click implementation for the node tool). Couldn't we make it that clicking a segment when the mouse ISN'T over the phantom central new node point switch to moving that segment? Ie - hover over a segment, both the segment is highlighted and the add new node point appears, and depending on whether the click is on this central point it's either add a new node or move the segment.

What about a key modifier to move segments? It might get too complex if it could be used for both new vertices and moving segment.
I thought this was not broadly used, and that for once in a while, selecting two nodes and moving them would be sufficient.

True, but it's not the easiest approach. Should we just make the node editor it's own tool?

Setting the coordinate is pretty easy: select node, press x (or click in line edit), enter coordinate, repeat for y.

@tomchadwin

This comment has been minimized.

Copy link

tomchadwin commented Aug 26, 2016

This looks brilliant. One question: is click-click implemented in any other GIS, CAD, or vector graphics software? I totally accept your argument, especially about more accurate mouse movement without mousedown, but I'd feel more comfortable if this editing method was something users might have experienced before.

@giohappy

This comment has been minimized.

Copy link

giohappy commented Aug 26, 2016

As a webgis developer I can say that this approach of selecting/adding
nodes, very similar to OpenLayers (which is the library I use more), is
well understood and appreciated by many users. Yet, in my experience,
click-click modify would be something quite unique. I like it, but
everything that involves breaking estabilished UX is risky...

giovanni

Il 26/ago/2016 11:05 PM, "Tom Chadwin" notifications@github.com ha
scritto:

This looks brilliant. One question: is click-click implemented in any
other GIS, CAD, or vector graphics software? I totally accept your
argument, especially about more accurate mouse movement without mousedown,
but I'd feel more comfortable if this editing method was something users
might have experienced before.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#69 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAi2-eSdFUVFcxJNVUqppQIXQTG55tQcks5qj1UNgaJpZM4Jt349
.

@wonder-sk

This comment has been minimized.

Copy link
Member Author

wonder-sk commented Aug 29, 2016

One question: is click-click implemented in any other GIS, CAD, or vector graphics software? I totally accept your argument, especially about more accurate mouse movement without mousedown, but I'd feel more comfortable if this editing method was something users might have experienced before.

I do not have a good overview of editing in other pieces of software - but users can experience the click-click behavior in the referenced plugin to see how it behaves...

@3nids

This comment has been minimized.

Copy link
Member

3nids commented Aug 29, 2016

Click-click is implemented in the few CAD softwares I know: Autocad, Microstation, Archicad.
I suppose it is widely used in CAD for the main reason that it allows to use keyboard to enter any input while the point is in movement.

When going to QGIS 2.0, we changed the add feature tool: right-click was not adding a new point but was just finishing the operation. People were a bit lost at first, but it became quickly very natural.

People might be indeed a bit lost at first, but the gain in production is huge. What's going to happen: someone will click on the point and drag it away: it will be freed. Then, he will either click left or right: ithe node will be either moved or reset. It shouldn't take long to understand how it works.

We can still show a message whenever the user try to click and drag. It's quite easy to detect and might be helpful for the migration.

As @wonder-sk suggested, the best thing to do is to try the plugin.

@andreasneumann

This comment has been minimized.

Copy link
Member

andreasneumann commented Aug 29, 2016

Yes - most CAD software behaves uses the Click-Click approach. I also think that people would quickly get used to it.

@gioman

This comment has been minimized.

Copy link

gioman commented Aug 29, 2016

@wonder-sk Hi Martin, very nice QEP. I gave a try to the tool and I must say that from a user point of view I would suggest NOT to lose the possibility to add nodes wherever is double clicked (so not only on the middle point) on a segment. This is a very handy functionality that as far as I know is very appreciated in QGIS. Moreover it seems to me that in this prototype implementation the user must move the new (middle) node after having added it otherwise it is not saved(?). Cheers!

@DelazJ

This comment has been minimized.

Copy link

DelazJ commented Aug 29, 2016

@nyalldawson wrote:

Currently the node editor dock is the easiest (only?) way to precisely create a point at an exact x/y coordinate.

And I think the only(?) way to set Z/M coordinate dimension (and Rayon for curved features)...

@haubourg

This comment has been minimized.

Copy link

haubourg commented Sep 9, 2016

agreed with @gioman, double clic anywhere on the segment to create a new vertex is mandatory. Sometimes, you worked zoomed in enough so that you wont see middle point in your canvas.

@wonder-sk Will the old click and drag behaviour be still there via an option or will it be removed entirely? (I won't miss it, just to be clear on that).

about risky change in UX, I think QGIS users are prone to accept changes, but they don't like them when they are unexpected. What about some kind of tooltip displaying on first use of concerned tools. The gif's are just perfect to explain the new behaviour, we should find a way to raise them in the workflow, not only in the docs or startup tooltips.

@3nids

This comment has been minimized.

Copy link
Member

3nids commented Sep 9, 2016

about double-click on segment, I don't really understand. With the new behavior, one click adds the vertex, the next clicks places it precisely. We could change the appearance of the "new" vertex, so that you could add one almost anywhere (instead of just one in the middle). Anyway, I don't think enabling the double click is a big deal, I am just not sure wether it's aligned with the new behavior.

Regarding the node editor, I think it will be re-enabled, but not necessarily always visible. It should be optional.

@haubourg

This comment has been minimized.

Copy link

haubourg commented Sep 9, 2016

2016-09-09 15:40 GMT+02:00 Denis Rouzaud notifications@github.com:

about double-click on segment, I don't really understand. With the new
behavior, one click adds the vertex, the next clicks places it precisely.

yes, but using the middle point only, (according to description and plugin
prototype). I didn't manage to add a vertex otherwise.

We could change the appearance of the "new" vertex, so that you could add
one almost anywhere (instead of just one in the middle). Anyway, I don't
think enabling the double click is a big deal, I am just not sure wether
it's aligned with the new behavior.

Yep, me neither, I only referred to double click because it's how it works
currently. Maybe simple click will be used by "move segment" that Nyall
would like to keep.

@haubourg

This comment has been minimized.

Copy link

haubourg commented Sep 9, 2016

2016-09-09 15:40 GMT+02:00 Denis Rouzaud notifications@github.com:
about double-click on segment, I don't really understand. With the new behavior, one click adds the vertex, the next clicks places it precisely.

yes, but using the middle point only, (according to description and plugin prototype). I didn't manage to add a vertex otherwise.

We could change the appearance of the "new" vertex, so that you could add one almost anywhere (instead of just one in the middle).
good point, maybe on the middle of the displayed part of the segment ?

Anyway, I don't think enabling the double click is a big deal, I am just not sure wether it's aligned with the new behavior.

Yep, me neither, I referred to double click because it's how it works currently. Also simple click will be used by "move segment" that Nyall would like to keep. Simple click anywhere might generate to much false vertex creations for untrained users.

@gioman

This comment has been minimized.

Copy link

gioman commented Sep 12, 2016

about double-click on segment, I don't really understand. With the new behavior, one click adds the vertex, the next clicks places it precisely.

note: I haven't tested this proposal extensively, but it seemed to me that once added a new node, to make it stick, it has to be positioned manually with another click. There are many good reasons a user just want to add a node by double clicking on a segment and no more actions required as it is now in QGIS. Loosing this functionality would be seen as a huge regressions by many users.

@3nids

This comment has been minimized.

Copy link
Member

3nids commented Sep 13, 2016

@wonder-sk would it be possible to allow double-click to add node?
and also to propose a new vertex candidate closer than the middle of the segment?

@jjk0giap

This comment has been minimized.

Copy link

jjk0giap commented Sep 26, 2016

+1 looks promising.
Best option is multi layer edit.
Click-click behaviour is very natural and more precise than old one. As heavy QGIS digitiser I have some suggestions:

  • double-click on segment for new vertex should stay (middle segment candidate is hard to find or even over a screen for long long segments).
  • double-click on vertex for delete vertex? I like mouse only digitising option.
  • different snap marker for vertex and segment snap.
@haubourg

This comment has been minimized.

Copy link

haubourg commented Oct 10, 2016

@wonder-sk Hi, do you think we can achieve a consensus and go for a vote ?

@nyalldawson

This comment has been minimized.

Copy link

nyalldawson commented Oct 18, 2016

@wonder-sk @3nids

In the interest of moving this work forward, here's my suggestions:

  • double click on a segment adds a vertex at that position
  • make the hover 'new vertex' node appear at the midpoint of the segment intersected with the current canvas extent (so it's always visible)
  • when hovering over a segment (not at the 'new vertex' node) highlight the segment, and allow click-click drag of segments
  • allow right click on existing nodes to select them without entering move mode. Then the node table will still be usable.

I think this should address all the concerns raised so far.

@nyalldawson

This comment has been minimized.

Copy link

nyalldawson commented Oct 18, 2016

If we allow direct move of segment, I would stick to click-click mode to avoid confusion and keep coherence. I wouldn't say CAD does not make sense (due to no defined starting point). You can still define precise (and complex) translations with this approach.

That's what I originally meant - still use click click for moving segments.

It could be allowed to move a segment by simple click on it (click would be at least XXX pixels away from "adding vertex" location and the two ending vertices.

Same with this - this is what I had in mind. But with the addition that the segment is highlighted when hovering over it before the first click and move begins.

@3nids

This comment has been minimized.

Copy link
Member

3nids commented Oct 18, 2016

Same with this - this is what I had in mind. But with the addition that the segment is highlighted when hovering over it before the first click and move begins.

yes +1

@wonder-sk

This comment has been minimized.

Copy link
Member Author

wonder-sk commented Oct 18, 2016

OK OK I give up, you can have moving of segments :-)

For CAD editing when moving segments, I did not mean that it does not make sense at all, just that it is currently not supported. Even when supported, some constraints should be disabled and perhaps some new ones added (e.g. move segment by distance X to the left or right)

@3nids

This comment has been minimized.

Copy link
Member

3nids commented Oct 18, 2016

I don't think we need new ones...we should just be able to define an inital orientation to the cad so we would have soft constraint at 90°. Does it sounds possible?

@NathanW2 NathanW2 modified the milestone: 3.0 Oct 26, 2016

@NathanW2 NathanW2 added Draft Type/Software and removed Draft labels Oct 26, 2016

@3nids

This comment has been minimized.

Copy link
Member

3nids commented Nov 2, 2016

shall this go on vote now?

@saberraz

This comment has been minimized.

Copy link

saberraz commented Nov 2, 2016

+1 from me (if it counts)
Have been using the tools and apart from double click to add a vertex the rest is very intuitive.

@wonder-sk

This comment has been minimized.

Copy link
Member Author

wonder-sk commented Nov 14, 2016

In the testing python node tool plugin I have done a couple of bug fixes and implemented suggestions that came up from the discussion as summarized by Nyall:

  • it is possible to add vertex by double clicking edges
  • it is possible to move edges by clicking them (when not at edge's mid-point)
  • edge mid-point is shown even if the true mid-point is outside of the current map view
  • ctrl+click to highlight vertex without going to dragging mode (for deletion and later for node editor integration)

Hopefully this should satisfy the concerns raised earlier.

I would suggest to wait for few days to allow people test the tool and if there are no objections I will update the QEP and we can proceed with voting.

@NathanW2 NathanW2 changed the title Improved Node Tool QEP 69: Improved Node Tool Jan 29, 2017

@DelazJ

This comment has been minimized.

Copy link

DelazJ commented Feb 28, 2017

@wonder-sk

edge mid-point is shown even if the true mid-point is outside of the current map view

Sorry if I'm a bit late on this but I wonder what could be the interest/use case of this option. why would someone want to place a vertex at a false mid position of a segment? It sounds to me like just placing a vertex anywhere on the segment (depending on the canvas extent). And Wouldn't that make users mistakenly place vertex (thinking that they are at the middle of the segment, e.g. during an intensive digitizing session) ?

@wonder-sk

This comment has been minimized.

Copy link
Member Author

wonder-sk commented Apr 3, 2017

Sorry if I'm a bit late on this but I wonder what could be the interest/use case of this option. why would someone want to place a vertex at a false mid position of a segment? It sounds to me like just placing a vertex anywhere on the segment (depending on the canvas extent). And Wouldn't that make users mistakenly place vertex (thinking that they are at the middle of the segment, e.g. during an intensive digitizing session) ?

A false mid point position of a segment would be used only if the segment is not fully visible in the map view - to allow users use the functionality without having to move away from the current map view to find the indicator. In practice it is very convenient - I would suggest you to try it out - it does not feel like it would be adding any confusion...

@popovs

This comment has been minimized.

Copy link

popovs commented Mar 12, 2018

According to the QGIS 3.0 release site,

If there is a need to constrain selection of vertices to just specific feature(s), it is possible to select the features with selection tool first - the vertex tool will only work with vertices from selected feature(s) in such cases.

I have about 100 features in my current project, only one of which needs node edits. Selecting this feature does not constrain the node tool to that one feature - perhaps this is a bug? It's impossible to select nodes from only the single feature I need to edit at the moment.

As an aside, for my particular purposes click-to-click has slowed down workflow immensely. It would be nice if there was an option of being able to switch between click-drag and click-click within the settings - for some jobs I prefer the drag, for others I prefer click-click.

Apologies if this isn't the correct place to post this - this is where the link on the QGIS 3.0 changelog for this feature leads to.

Thanks for the immense amount of work that has gone into the otherwise excellent QGIS 3.0 improvements!

@wonder-sk

This comment has been minimized.

Copy link
Member Author

wonder-sk commented Mar 13, 2018

hi @popovs it is best to use the bug tracker at issues.qgis.org to file any problems - what you describe sounds like a bug. If you could create a small screencast and/or a sample project that would be very useful (and attach them to the ticket).

@haubourg

This comment has been minimized.

Copy link

haubourg commented Mar 13, 2018

@popovs I second @wonder-sk proposal.
Did you try to select the feature you want to edit. Martin adressed that issues in the latest moment before the release but we may have issues again.

@popovs

This comment has been minimized.

Copy link

popovs commented Mar 13, 2018

@wonder-sk @haubourg thanks. I've filed a bug report here.

@gioman

This comment has been minimized.

Copy link

gioman commented Sep 3, 2018

@wonder-sk @DelazJ Hi al. Looking at the new node tool on 3.2/master and I was wondering if we could expect to have some bug fixed in time for the next LTR like https://issues.qgis.org/issues/18192 and https://issues.qgis.org/issues/18046 Also I have started receiving complains about the new way to add new nodes: now the user can only add a new node in the middle of a segment, while before it was possible where the user wanted to. This is seen (also by me) as a functionality regression. Moreover now when a new node is added the tool drags it immediately when moving the mouse, while before this was not the case. This is also source of complains among users who digitize a lot. Opinions? Cheers!

@DelazJ

This comment has been minimized.

Copy link

DelazJ commented Sep 3, 2018

Reading the thread, it appears that there was an agreement to keep the "double-click adds a new point". See #69 (comment) and #69 (comment)
Generally speaking i find the click-click is a real improvement though i not yet fully understand how the vertex tool selects the different nodes (through layers) to snap to and it might need time to get used to it. But i really miss the ability to simply add a vertex (now that i do long digitizing sessions) and can't find any workaround.

@yjacolin

This comment has been minimized.

Copy link
Member

yjacolin commented Sep 4, 2018

@DelazJ adding new vertex is much simpler than before: when you place your cursor on a segment, an intermediate vertex appears temporary; click on it and move it where you want to locate it. That's it.

@DelazJ

This comment has been minimized.

Copy link

DelazJ commented Sep 4, 2018

when you place your cursor on a segment, an intermediate vertex appears temporary; click on it and move it where you want to locate it. That's it.

That's the issue: i don't want to move it and i don't want the point at the middle of the segment but place it eg at 25% of the segment. Imagine, instead of drawing a line of 20m, you drew one of 25m, following the right azimuth. How would you place the vertex at 20m?
Or suppose that you want to add a vertex to a segment S1 so that another segment S2 snaps to it on the vertex. How would you place the vertex on S1 and guarantee that the three points are aligned, that you really keep the feature S1 straight-lined ?
IOW, with the current implementation, I fail to see how I can draw three points aligned without using the CAD panel

@gioman

This comment has been minimized.

Copy link

gioman commented Sep 4, 2018

That's the issue: i don't want to move it and i don't want the point at the middle of the segment but place it eg at 25% of the segment.

or place a new node at an arbitrary position in a segment, as it is possible on qgis 2.* (and I agree, even if arguable, that by default we do not want to move new nodes).

@Antoviscomi

This comment has been minimized.

Copy link

Antoviscomi commented Oct 18, 2018

Hi all,

sorry if I was tooblate in this discussion but I wanted to test the new vertex editor for a few days.

globally the editor works but there are some details that make me think ...

I try to sum up what is not in my opinion:

1 - the highlighting of the nodes is not particularly functional;
  (I work on a 28 "FHD monitor and despite this I find it difficult to identify the selected vertex);

2 - it is no longer possible to delete the vertex from the vertex panel;

3 - just touch (without clicking) the border of a polygon or a line to move it without wanting (potentially devastating months of work spent to building the polygons);

4 - when you insert a new vertex it is not visible in the map (it is not well highlighted):

5 - adding a point on polygon boundary (editing with "topological editing active") "vertex Editor" it doesn't works as expected (the point is added on only one polygon instead of both polygons);

6 - at certain zoom levels (1:50 - 1:100) vertex editor don't hook the polygon boundary (then you need to zoom to layer extension, try to hooks a polygon boundary randomly then going to the previous zoom to be able to hook the previous choosed polygon boundary);

Finally I propose:
1 - for move segments it would be better to use right click on te mouse (if it's simple to develop).;
2 - for vertex selection and vertex highlight it would be better to go back to the graphical version of QGIS 2.x;

Greetings

Antonio

@andywicht

This comment has been minimized.

Copy link

andywicht commented Oct 18, 2018

I also strongly agree to the fact that a user should be able to create a new vertex anywhere on the segment (and to my issue that a vertex should also be created in the adjacent polygon to maintain topology).

Furthermore I want to throw this fresh issue into the discussion:
https://issues.qgis.org/issues/20158

This also depicts a great discrepancy in what a user expects to happen vs. what actually is the outcome while digitizing.

@Antoviscomi

This comment has been minimized.

Copy link

Antoviscomi commented Oct 20, 2018

I noticed another issues... If there are some topological errors, and I edit the feature to solve them, in some polygon with self intersection, adding a new vertex on polygon ignore snap settings adding the new vertex anywhere in the shapefile and snapping this vertex to any polygon very far to the poligon I need to edit.
Then this point cause a hole that goes through the entire areal extension of map.
I've just open a ticket for this

http://issues.qgis.org/issues/20172

Regards

Antonio

@Antoviscomi

This comment has been minimized.

Copy link

Antoviscomi commented Oct 24, 2018

Hi,
vertex editor don't hook the polygon boundary

I attach 3 screencast that show this issues:

  • the first (vertex_1) show how is difficult (sometime impossible) to hook right a polygon you want to edit;
  • I need to edit polygon 65592 but it is impossible to hook it without move a vertex of 65600;
  • once the 65600 vertex has been moved it is possible to hook 65592. but 65600 it becomes unchallengeable (as shown in vertex_2);

the 3th one screencast show how easy it is to perform the same selection using QGIS 2

Screencasts.zip

I just opened an Issues

https://issues.qgis.org/issues/20206

It's possible to re-enable the vertex selection simply by clicking anywhere on polygon?

Regards

@Antoviscomi

This comment has been minimized.

Copy link

Antoviscomi commented Oct 26, 2018

Please Add a zoom to vertex option in editor vertex panel

Hi all,

when a user select a vertex or some vertices from vertex panel he often needs to see where these vertices are (at all zoom scales, not just when the vertices or feature is out of the map)

then I ask for an option that makes the user able to zoom to the selected vertex or vertices

many thanks in advance

Antonio

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.