Maybe I’m just to stupid but I was always annoyed with the selection of objects.
Especially when mapping public transport routes. After selecting multiple ways for a relation one accidental click would reset the whole selection and I had to start over.
If there was a way to store selections I didn’t find it, so I finally got so fed up with it all that I developed the ExtendedClipboard plugin. It can contain up to 10 independent clipboards to store objects for later selection.
So storing the ways for a public transport route in one of the clipboards will get rid of accidentally losing the selection since it can easily be restored again.
To further support creating public transport routes the order of the objects of a clipboard can easily be reversed which is often useful for correcting existing routes.
It might be also useful to collect objects for later editing them together.
I create and maintain a lot of routes, and I used to lose the control-click selections often enough. But I can simply store them in the opened route relation, just as easily as a I can store them in a clipboard, and reversing the order of the selection is one click in the relation editor.
I can also select a way and immediately store it at the right place in the route relation. I can sort the complete route or a selection of the members
Maybe I am missing something, but I can’t quite see the advantage of the clipboards for this purpose!
Good for you if it works for you but for me it’s much more convenient to have multiple clipboards to store objects in, especially when editing a wrongly mapped route.
Before judging the usefulness of the extended clipboard maybe just try it. If you add the way directly into the relation you need to keep the relation window open, select a way then click on the button in the relation window to add it. Using a clipboard you selected the way, press D on the keyboard and the way is stored. This will be very quick and the order of the ways is also easy to achieve, just add the ways to the clipboard in the order that is needed. Once all ways are stored select them with double click on the clipboard and you can add them at once into the relation. Alternatively automatically sort the PT relation with PT assistant if they are not in correct order.
I’m sorry if my words came across as judgeing. I do recognize the problem. I installed and tried the plugin and used it for a hiking route, to compare. But I did not know about hitting D to add to the clipboard, which makes the extended clipboard much more usable, so thanks for that!
PS1
Just for fun ((yes, you can make fun of me, like I do myself), I’ll tell you why I lost many selections when creating routes. Of course, click click click while holding control down works, and it’s faster than other methods becaused it has no extra click or key, but I kept losing selections. Turned out it wasn’t my faut; this just happens after a series of clicks with control down: the control just stops working. Then I got used to using control-click-release_control for every selected way. Now I never lose a selection any more.
PS2
When I saw the topic, I thought it solved my other wish: to store a selection of objects I often use together, such as a bridge, a tree, a tree_row, a give_way forward and a give_way backward, a zebra crossing, a guard stone. Most of the time, I copy paste these things from an existing one, but this requires searching one all the time, and I can only keep one at a time for the control V. So I thought of a kind of clipboard holding a group of objects to choose from, eliminating the search for examples. Programming is not one of my abilities, but I mimicked it by creating a separate JOSM session which never uploads, and copied about 20 objects to it that I often use, then store the session. Now, when I start updating landuse, naturals, bridges, roads and roundabouts, I open this special session, so I have this selection available for control-C control-V all the time. It works and saves time, but if it were a “clipboard” within JOSM it would be less clumsy.
Reading the change log entry (V3), think I can use this, at least I can store for instance a streetlamp with a particular configuration being a solar panel on top We have many here and growing where getting the regular electricity to is problematic so these get placed on isolated crossings in the pitch dark country side, driveways entrances of farms. Quickly picking the object, copy, use 8 to return to the last position where I was and place a copy.
v.v "Save the name of the clipboard. A saved clipboard name will be restored at startup (without the previous objects). ", The 64,000 U$ question: Can these be stored cross-session and recalled when restarting JOSM? That would open up an avenue of lots of specialized tagged object storing on the extended clipboard (EC) since the toolbar buttons bar has a finite number of custom buttons (Sort of doing what Peter Elderson describes above as present working method).
Yes without a direct keyboard shortcut it wouldn’t be as useful.
It seems I wasn’t the only one that was unaware of the selection history. It eliminates the risk of losing selections by mistake, when you just can restore the selection right away. But now that I know I used the concept of the arrow button to support finer selection of objects of a clipboard.
You’re use case for a “real” clipboard sounds interesting, but what you really need would be some kind of node preset list in which you can create presets for creation of a node with certain tags. A new node then would be created by selecting the preset in the list and pressing Ctrl+C or in a more fancy way by dragging the preset to the map (which would be a lot more complicated to program).
Again this would be a different plugin. But it sounds interesting enough to think about it. It doesn’t sound so hard to get this running, especially if it doesn’t have it’s own configuration but would only store node presets from existing nodes.
So select an existing node click on a button in the plugins dialog, the node would be read to get the tags, and then would be added to the list. A double click on a list entry would then create a new node with the same tags and store it in the JOSM clipboard for pasting it.
Well I did say that it would be for another plugin but I couldn’t be bothered to set up a completely new plugin for a function that is kind of in the scope of EC. I’ve simply added a new dialog to the plugin called “Node template list”, it works just as I had described it above. Select nodes in the map view and click on the + button of the node template list. For each node that has at least one tag a template will be created. The name will be a string of all the key value pairs or the name if the name key is present. The name of a template can later be changed. To copy a new node from that template to the JOSM clipboard just double click on the template in the list or select the template and click the copy button.
Those templates will be stored for use in consequent JOSM sessions. So were do I get my $ 64,000?
I do not intent to support storing more complex objects like ways.
I’ve finally reached the point where I think I’ve added enough for now.
The newest version can paste the new node directly into the map view with tripple click and paste button. Node templates can now be imported from presets via the context menu of the node template list. Node templates imported from presets will show an icon if the preset had an icon. The node template list can be sorted alphabetically via the context menu.
Got round to digging in, oddly had to add the ExtendedClipboard name in Advanced Preferences to the plugin list manually first as no matter what plugin list refreshing the EC would not show. Now got instant and disposable presets that can be named to boot. Since this added 2 more panels of the many I use constantly and minimizing/expanding is excruciating slow, made them floaters.
Yes JOSM doesn’t value vertical screen real estate, for about every 4 panels with buttons you lose the height of an aditional panel. That’s the reason why I use my own fork of JOSM that can place the buttons on the right side of a panel since there is regularly plenty of horizontal screen real estate. A screen with a pivot function would help with the height limitation.
When I look at your screenshot it also would be a good idea to allow a user to place panels at the bottom of the window without the need to detach it from the window.
Likely I misunderstand what you wrote, but JIC not already known, you can set the buttons of the dialog panel frames to hide and only show on hover of that frame which recoups a lot of vertical screen to allow more frames on the panel. The option is on the display preferences, bottom item of the ScreenSnip. “Dynamic buttons in side menus”.
Yes I know that option but it’s not for me. It bugs me when the buttons show and hide every time I hover over a panel. Just too jittery. This is how it looks with my version of JOSM.
It also has this little lock button for each panel that locks the size of the panel. So it will be always the same hight. Or let’s say most of the time. It doesn’t work in all situations but for me it’s good enough and a lot better than the default JOSM that gives every panel the same height (as I remember).
Was ticketed with JOSM to remember the panel heights as manually set but it just forgets, so each morning it’s the first thing to do, setting the frame heights… e.g. don’t need 6 lines on the Change Sets list. Only interested to see the output in Carta S of last few, to see if any booboos were made w/ help of Better-OSM-Org. Else can scroll, can’t we. No it does not disturb me, other than if the frame is too small the buttons overlay the top lines too.
You could make the JOSM proggers aware of your home brew features… certainlly like the buttons to the right and folding out if the frame is not high enough. Got enough horizontal to pp
