QEP 69: Improved Node Tool about qgis-enhancement-proposals HOT 55 CLOSED

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

from qgis-enhancement-proposals.

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.

from qgis-enhancement-proposals.

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...

from qgis-enhancement-proposals.

@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!

from qgis-enhancement-proposals.

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.

from qgis-enhancement-proposals.

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!

from qgis-enhancement-proposals.

@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!

from qgis-enhancement-proposals.

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.

from qgis-enhancement-proposals.

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).

from qgis-enhancement-proposals.

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.

from qgis-enhancement-proposals.

+1 Nice

On Fri, Aug 26, 2016 at 6:55 PM, Martin Dobias [email protected]
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
.

from qgis-enhancement-proposals.

+1 looks really good :-)

from qgis-enhancement-proposals.

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 [email protected] wrote:

+1 Nice

On Fri, Aug 26, 2016 at 6:55 PM, Martin Dobias [email protected]
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
.

from qgis-enhancement-proposals.

Number 4 and number 7 are of upmost excitement 😄

from qgis-enhancement-proposals.

this is an excellent job @wonder-sk

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

from qgis-enhancement-proposals.

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

from qgis-enhancement-proposals.

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

Otherwise big +1

from qgis-enhancement-proposals.

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).

from qgis-enhancement-proposals.

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.

from qgis-enhancement-proposals.

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?

from qgis-enhancement-proposals.

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.

from qgis-enhancement-proposals.

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.

from qgis-enhancement-proposals.

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" [email protected] 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
.

from qgis-enhancement-proposals.

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...

from qgis-enhancement-proposals.

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.

from qgis-enhancement-proposals.

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

from qgis-enhancement-proposals.

@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)...

from qgis-enhancement-proposals.

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.

from qgis-enhancement-proposals.

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.

from qgis-enhancement-proposals.

2016-09-09 15:40 GMT+02:00 Denis Rouzaud [email protected]:

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.

from qgis-enhancement-proposals.

2016-09-09 15:40 GMT+02:00 Denis Rouzaud [email protected]:
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.

from qgis-enhancement-proposals.

@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?

from qgis-enhancement-proposals.

+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.

from qgis-enhancement-proposals.

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

from qgis-enhancement-proposals.

@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.

from qgis-enhancement-proposals.

Hi @nyalldawson - thanks for the suggestions! I agree with them, the only bit I am not sure about is dragging of segments:

• snapping behavior is undefined when moving segments. CAD editing also does not support that. We would need to choose one vertex (endpoint? midpoint?) and do snapping based on that vertex. Looking at how current node tool does it, the segment tends to jump suddenly when one endpoint is snapped, resulting in quite strange behavior.
• the operation IMHO does not seem to be that important. Moreover, it can be replicated by selecting multiple nodes and moving them at once (with well-defined snapping)
• failing to click correctly on segment's mid-point would trigger moving of segment rather than addition of a node (a minor thing)

from qgis-enhancement-proposals.

@wonder-sk My rebuttal ;)

snapping behavior is undefined when moving segments. CAD editing also does not support that. We would need to choose one vertex (endpoint? midpoint?) and do snapping based on that vertex. Looking at how current node tool does it, the segment tends to jump suddenly when one endpoint is snapped, resulting in quite strange behavior.

I'd say snapping+CAD should be disabled when moving a segment. The only behaviour which would make sense would be to snap using both start/end vertex, but that's more complicated and could also get annoying. So I'd say move segment = no snapping/cad.

the operation IMHO does not seem to be that important. Moreover, it can be replicated by selecting multiple nodes and moving them at once (with well-defined snapping)

I'm not sure why my digitising workflow is so unusual. I've tried (since this discussion started) to practice and get used to the select-both-nodes-and-drag method but it's just so much slower (two extra clicks + a ctrl key press if you can't get away with a drag selection, or a click+drag extra if you can) that I just hated it...

from qgis-enhancement-proposals.

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.

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.

from qgis-enhancement-proposals.

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.

from qgis-enhancement-proposals.

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

from qgis-enhancement-proposals.

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)

from qgis-enhancement-proposals.

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?

from qgis-enhancement-proposals.

shall this go on vote now?

from qgis-enhancement-proposals.

+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.

from qgis-enhancement-proposals.

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.

from qgis-enhancement-proposals.

@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) ?

from qgis-enhancement-proposals.

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...

from qgis-enhancement-proposals.

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).

from qgis-enhancement-proposals.

@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.

from qgis-enhancement-proposals.

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

from qgis-enhancement-proposals.

@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.

from qgis-enhancement-proposals.

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

from qgis-enhancement-proposals.

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

from qgis-enhancement-proposals.

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

from qgis-enhancement-proposals.

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

from qgis-enhancement-proposals.