[patch] Shortcut for selecting adjacent nodes

[akks]

It would be useful to have "expand selection"-like tool.

Why?

It is inconvenient to select adjacent nodes manually when part of the way should be moved or aligned.

Proposed behaviour:

1) Node of some way is selected. Some key (E? )is pressed => two adjacent nodes are added to selection. [ after this action nodes can be aligned or moved ]

2) Multiple nodes are selected - E pressed => all adjacent nodes (connected by all way segments to selected).

3) Node and its way are selected - E pressed - adjacent nodes of selected way are added to selection.

Can implement it myself, commit or send a patch if this proposal is approved (familiar with JAVA and SVN, successfully patched JOSM for myself, but does not know organizing structure of JOSM project and conventions).

[bastiK]

Ticket #6167 has been marked as a duplicate of this ticket.

[bastiK]

May I ask, what this is good for?

A somewhat similar patch is in #5694 (first part). It selects adjacent ways, which is useful when dealing with terraced buildings.

[akks]

For example, if you move one point on the street manually, you can easily return this node on straight line between its neighbours (L does not support it, if you do not select neighbour nodes manually). (scenarious 1 and 3).

Scenario 2 is not such obvious. It can be modified. The main goal - to be able select NEXT nodes on the way without picking them.
Is there any other way to select big part of the way with keyboard only?

Thank you for showing #5694 ticket. Yes, the functionality is similar, and the functionality can be merged (key1 = select NEAREST nodes connected to selection, key2 = select ALL nodes, connected to selection, key3=select ALL nodes and ways connected to selection).

The main goal of this enchancement is to reduce number of boring mouse-clicks. Select tool really lacks some additional functionality)

Maybe modifying click behaviour is too revolutionary. Shortcut will be enough). Should I write a plugin or someone will patch the main version?

[bastiK]

Replying to akks:

For example, if you move one point on the street manually, you can easily return this node on straight line between its neighbours (L does not support it, if you do not select neighbour nodes manually). (scenarious 1 and 3).

OK, this is still rather special - we could even add an exception to "L" that makes it work this way for one node selected.

Scenario 2 is not such obvious. It can be modified. The main goal - to be able select NEXT nodes on the way without picking them.
Is there any other way to select big part of the way with keyboard only?

What do you mean by "NEXT", in the direction of the way, only? Why do you need to select parts of a large way? I would rectangle-select the part of the way and then search for "selected & child (type:way id:12345)" to clean up selection.

Thank you for showing #5694 ticket. Yes, the functionality is similar, and the functionality can be merged (key1 = select NEAREST nodes connected to selection, key2 = select ALL nodes, connected to selection, key3=select ALL nodes and ways connected to selection).

If you can help to integrate #5694 (i.e. make proper patch with good shortcut), this would be appreciated.

The main goal of this enchancement is to reduce number of boring mouse-clicks. Select tool really lacks some additional functionality)

Maybe modifying click behaviour is too revolutionary.

Exactly. And I don't want this to be a shortcut-only feature. There should be a menu item (including icon) for this.

Shortcut will be enough). Should I write a plugin or someone will patch the main version?

You can add it to UtilsPlugin2, this is no problem. As for the main version, I'm not sure yet. If there was more of this, a new top level menu "Selection" would make sense.

[akks]

Thank you for your advice. I will try to add these features to UtilsPlugin2 (it already have 'Select all nodes of the way')

OK, this is still rather special - we could even add an exception to "L" that makes it work this way for one node selected.

This would be very good) Actually, I made it in my source code, but it was rather ugly and untested.

If you can help to integrate #5694 (i.e. make proper patch with good shortcut), this would be appreciated.

I will try to understand and carefully reimplement its functionality, using shortcut and menu.

What do you mean by "NEXT", in the direction of the way, only? Why do you need to select parts of a large way? I would rectangle-select the part of the way and then search for "selected & child (type:way id:12345)" to clean up selection.

Can propose: key1 = select 2 neighbours by way, shift-key1=select next only,crtl-key1(near key1 on keyboard)=select previous only.
key3 = select ALL coonected nodes, ctrl-key3 = select ALL connected polygons. If some ways are selected, only their edges will be active for search.

I'll test it for some time to verify usability)) (after implementing, of course).

"selected & child (type:way id:12345)" is a good solution, but not so intuitive) Sometimes it is needed to move large part of sophisticated-shaped boundary/water/wood. Оr just align more than one middle node of the road.

[akks]

Implemented it but failed to commit via Ant)) Where should I insert login and password?

[bastiK]

The ant task is just for convenience. Better do it manually, roughly like this:

cd plugins/utilsplugin2
svn st
... (check if all is ok)
svn ci
svn up
ant clean dist
svn ci ../../dist/utilsplugin2.jar

[akks]

Thank you. Trying to get openstreetmap.org SVN account - have no such one (

[akks]

Adding more functionality while waiting account - select ways connected to selected ways (if no nodes are selected).

By the way, can I take 'E' shortcut and its modifiers, please?

[akks]

схема работы

[akks]

Added all functionality:

For nodes:
E = Extend node selection step-by-step. If some ways are selected, they are used for advancing.
Shift-E = Fast extend selection: add nodes on all ways attached to selected nodes
(see example ​image )

If no nodes are selected but only ways are:
E = select attached ways step by step
Shift-E = select all ways, INTERSECTING selection (may be slow if used repeatedly for more than 1000 selected ways).

Do not know, where to ask SVN account (svn.openstreetmap.org)

[bastiK]

Replying to akks:

Added all functionality:

For nodes:
E = Extend node selection step-by-step. If some ways are selected, they are used for advancing.
Shift-E = Fast extend selection: add nodes on all ways attached to selected nodes
(see example ​image )

If no nodes are selected but only ways are:
E = select attached ways step by step
Shift-E = select all ways, INTERSECTING selection (may be slow if used repeatedly for more than 1000 selected ways).

If you want us to apply it, please append the changes as a patch in text format and the images as png files. (No zip or jar)

Do not know, where to ask SVN account (svn.openstreetmap.org)

See here: ​http://wiki.openstreetmap.org/wiki/Subversion (You have to ask TomH).

[akks]

If you want us to apply it, please append the changes as a patch in text format and the images as png files. (No zip or jar)

I attach the patch and pictures to reduce applying time)
I think I will try to commit or improve it myself later, if permission will be granted (to be able to develop more plugins).

About adding an exception to "L" (select two neighbour nodes and align them) - should I make a patch or you have some time to implement it carefully?

See here: ​http://wiki.openstreetmap.org/wiki/Subversion (You have to ask TomH).

Yes, but main problem is to find TomH contacts) He asked to email him on his OSM page, but no email is available anywhere (to stop spam, I think). Tried Facebook, but still no reply.

[bastiK]

Replying to akks:

If you want us to apply it, please append the changes as a patch in text format and the images as png files. (No zip or jar)

I attach the patch and pictures to reduce applying time)

Thanks, please do not apply your changes to build.xml this way. It seems you have an unusual setup. Normally you would check out

svn co http://svn.openstreetmap.org/applications/editors/josm josm

to get both josm and the plugins. Then the path need not be fixed.

I think I will try to commit or improve it myself later, if permission will be granted (to be able to develop more plugins).

About adding an exception to "L" (select two neighbour nodes and align them) - should I make a patch or you have some time to implement it carefully?

Please make a patch, it's your project. :)

See here: ​http://wiki.openstreetmap.org/wiki/Subversion (You have to ask TomH).

Yes, but main problem is to find TomH contacts) He asked to email him on his OSM page, but no email is available anywhere (to stop spam, I think). Tried Facebook, but still no reply.

Does ​this help?

[akks]

O, thank you) I will write... Allergic to MailLists, used to forums)

[bastiK]

Did you forget NodeWayUtils.java?

[akks]

Yes, of course... Sorry. I thought I replaced the patch, but somewhat TRAC does not replace attachment and ignore such option! [returned from work, found correct patch]

[akks]

correct patch

[akks]

patch for utilsplugin2

[akks]

At home old patch was replaced successfully too - maybe it was my mistake and TRAC has no bugs...

[bastiK]

Why do you have a method addWaysIntersectingWay()? Shouldn't these operations only work on the topology? I'd say that addWaysConnectedToWay() has to be called recursively somehow.

[akks]

addWaysIntersectingWay() is used in shift-E when only ways are selected. Sample of usage - drawing buildings with several rectagles and merging them. Pressing Shift-E selects all polygons intersecting selected. Implementation is rather inefficent, I know.

The implemented idea is to extend selection step-by step: one key press = select all ways connected (intersecting) with already selected. Recursion usually gives too big selections.

Of course, fully recursive selection should also be implemented, but I need some advice on its behaviour (another shortcut? use shift-E? ctrl-E - gpx export?). Now you can simply press E (Shift-E) 2-3 times and see that all connected ways/polygons are selected.

[akks]

I have obtained SVN account. Should I commit or improve something?

I realized, recursive selection is incorrect term for current Shift-E behaviour. Maybe make shift-E real recursive, and add ctrl-E = "Fast extend selection"?

[bastiK]

Replying to akks:

I have obtained SVN account. Should I commit or improve something?

Basically it's your decision. I will only interfere if your contributions cause regression or have a negative impact on JOSM core. (E.g. we may veto the shortcut, but at the moment I don't see a problem. Note that Ctrl-E is taken by 'Export GPX...', but I will remove that menu entry anyway.)

I relized, recursive selection is incorrect term for current Shift-E behaviour. Maybe make shift-E real recursive, and add ctrl-E = "Fast extend selection"?

I'd say it would be more understandable if the actions were spread over more menu items. E.g.

Select ->
  all
  nothing
  ----
  adjacent nodes (1 step)
  adjacent nodes (all)
  connected ways (1 step)
  connected ways (all)
  overlapping ways (1 step)
  overlapping ways (all)

Then it should also give a helpful message box, if the selection is not appropriate, or action did nothing (e.g. 'adjacent nodes' on a POI).

[akks]

Will commit soon-selection menu is almost ready. Adding icons and messages..

[akks]

Added wiki and help:

​http://wiki.openstreetmap.org/wiki/JOSM/Plugins/utilsplugin2

Commiting...

[akks]

Done it at last)

[akks]

Thank you for advice, splitting the functions is really better for using and understanding. Let us see what users think about additions (started topics on JOSM forum - English and Russian).

[bastiK]

Great!

• Why do you have restrictions on the recursion level and the maximum number of found ways? If all the ways of the planet are selected, so be it, what's the problem?

• Do you need to preserve the order of elements in the selection? If not, a normal HashMap may be faster.

• It is probably not a good idea to have redundant documentation, do you want me to remove the pages in the JOSM wiki?

• The second example in "Select adjacent ways" doc looks strange; btw. MediaWiki has good svg support.

[stoecker]

Rather that removing docs from JOSM wiki you should add the remaining parts from OSM wiki here and remove it there with a link to JOSM online help. OSM wiki never can be used as online help.

[akks]

Why do you have restrictions on the recursion level and the maximum number of found ways? If all the ways of the planet are selected, so be it, what's the problem?

Problem is perfomance) If you need such big selections, you can use parameters selection.maxrecursion, selection.maxfoundways, selection.maxfoundwaysrec.

Do you need to preserve the order of elements in the selection? If not, a normal HashMap may be faster.

You mean HashSet, yes?

Of course, no. If adding/removing/selection from HashSet is faster (as I see it is, except maybe deletion from interior), I will replace it (i will check perfomance).

The second example in "Select adjacent ways" doc looks strange; btw. MediaWiki has good svg support.

Arr, forget one line! Thank you. Was drawing in Inkscape, but thought that svg on pages can cause problems for IE-users and so on.

It is probably not a good idea to have redundant documentation, do you want me to remove the pages in the JOSM wiki?

Hm, and where should I send people from forum to read about the whole plugin?

[akks]

By the way, there are some strange messages about shortcuts:

[java] Silent shortcut conflict: 'menu:Selection' moved by 'menu:History' to 'Alt+B'.
[java] Silent shortcut conflict: 'tools:intwayall' moved by 'core:information' to 'Ctrl+Shift+I'.
[java] Silent shortcut conflict: 'properties:add' moved by 'menu:Selection' to 'Alt+C'.
[java] Silent shortcut conflict: 'subwindow:conflict' moved by 'properties:add' to 'Alt+Shift+C'.

What should I write to bind ctrl-shift-I explicitly without any automatic rebinding?
I do not use VK_B and VK_C at all, but when I changed VK_S to VK_M in Selection menu construction, I see only warning about Ctrl+Shift+I.

I do not understand the shortcut system...

[akks]

Fixed wiki and help (still png). Renamed parameter selection.maxfoundwaysrec -> "selection.maxfoundways.intersection", default 500.

Changed shortcut to fixed Ctrl+Shift+I (used KeyEvent.SHIFT_DOWN_MASK|KeyEvent.CTRL_DOWN_MASK).

Changed VK_S to VK_M in Selection menu construction - do not know why)

Changed all LinkedHashSet to HashSet, however no significant performance increase (something aboout 80 to 70 ms).

Changed build.xml to accept ant runjosm correctly not only from NetBeans and from svn.osm folder structure.

[akks]

Can not commit from behind the proxy. If anything else should be patched, tell me.

[bastiK]

Replying to akks:

By the way, there are some strange messages about shortcuts:

     [java] Silent shortcut conflict: 'menu:Selection' moved by 'menu:History' to 'Alt+B'.
     [java] Silent shortcut conflict: 'tools:intwayall' moved by 'core:information' to 'Ctrl+Shift+I'.
     [java] Silent shortcut conflict: 'properties:add' moved by 'menu:Selection' to 'Alt+C'.
     [java] Silent shortcut conflict: 'subwindow:conflict' moved by 'properties:add' to 'Alt+Shift+C'.

What should I write to bind ctrl-shift-I explicitly without any automatic rebinding?
I do not use VK_B and VK_C at all, but when I changed VK_S to VK_M in Selection menu construction, I see only warning about Ctrl+Shift+I.

I do not understand the shortcut system...

Yes, it is confusing. The first means, that the history menu in Reverter Plugin has taken Alt+S, so Selection menu gets Alt+B instead. The 2nd indicates, that Ctrl+I is taken by core InfoAction. The 3rd and 4th is a cascade of key rebindings caused by the first.

[bastiK]

Replying to akks:

The second example in "Select adjacent ways" doc looks strange; btw. MediaWiki has good svg support.

Arr, forget one line! Thank you. Was drawing in Inkscape, but thought that svg on pages can cause problems for IE-users and so on.

svg images are delivered as png to the browser. You don't have to do anything, just link them as svg, see ​here for example.

It is probably not a good idea to have redundant documentation, do you want me to remove the pages in the JOSM wiki?

Hm, and where should I send people from forum to read about the whole plugin?

Link from one place to the other. I don't care if you choose OSM wiki or JOSM wiki, but if you put the information at both places, this will cause problems, both versions will diverge.

[akks]

Replying to bastiK:

Replying to akks:
svg images are delivered as png to the browser. You don't have to do anything, just link them as svg, see ​here for example.

Link from one place to the other. I don't care if you choose OSM wiki or JOSM wiki, but if you put the information at both places, this > will cause problems, both versions will diverge.

OK, I'll post SVG images later on osm wiki and make links for them in JOSM help (had no wiki experience before this).

Yes, it is confusing. The first means, that the history menu in Reverter Plugin has taken Alt+S, so Selection menu gets Alt+B instead. The 2nd >indicates, that Ctrl+I is taken by core InfoAction. The 3rd and 4th is a cascade of key rebindings caused by the first.

I'll choose VK_N (Alt-N) for selection menu then (no conflicts).

[akks]

Commited.

[akks]

I have just added "unselect nodes" feature (proposed by Martin Ždila in maillist, I found it after my commits), shortcut Alt-U.

[stoecker]

Can this be closed?

[akks]

May be closed, if no bugs in plugin are found.