[patch/plugin] Help with drawing parallel ways

[anonymous]

Help with drawing two-lane highways so that the two lanes are parallel.

[johan.huysmans@…]

I asked the OSM mailinglist yesterday if there was an easy way to accomplish this. I also suggested to make the improvement in JOSM.

As is didn't know this ticket it seems this is a feature that will be used a lot and improve the quality of the maps.

I hope it will be implemented in a reasonable time.

[imi]

see #199

[anonymous]

See #516 and #586 also.

[Richard]

Potlatch now has this feature if you want to "borrow" the code (look at OSMWay.prototype.offsetWay, or something like that, in way.as).

[xeen]

I wonder if this still needs fixing – it's not a very common operation and duplicating and reversing the single lane highway is virtually no effort and achieves the same. Apart from "do want" is there any other reason why this can't be closed?

[Richard]

No, it doesn't achieve the same - see ​http://lists.openstreetmap.org/pipermail/newbies/2009-February/002600.html .

[xeen]

Yeah, I know. I've already had some thought about the UI implementation. While I like Potlatch's presets it's kind of unintuitive to draw a way and then add the "real" ways and delete the self-drawn one. I imagine it to be annoying if you have only the GPX track of one direction. But it makes adding interpolation house numbers really easy.

Merkaartor's implementation is much better, allowing to see directly how wide it will be and it draws the correct ways as you go. Especially nice is that you can change the desired distance in between and it will connect the highways automatically for you. Adding house numbers automatically doesn't work this way, though (maybe there's an additional tool? I've only used Merkaartor for like 10 minutes, so I've really no idea).

Using the Merkaartor solution would make it a map mode tool, although it would be over-represented this way in JOSM. Also, there'd be no space to add the controls. A right hand side dialog could work, though. If you have any ideas for the actual implementation, please post them.

[Richard]

"it's kind of unintuitive to draw a way and then add the "real" ways and delete the self-drawn one"

How so? You draw one carriageway and it puts the other one in for you.

[xeen]

It puts two ways on each side when I press P.

[Richard]

Yes, because putting two sides in, and asking the user to delete the unused one, is a more immediate UI than "please specify an arbitrary negative/positive offset relative to the direction of the way, then try again because you've got the wrong side". (Illustrator's 'Add arrowheads' command effectively does this and it annoys me no end.)

If AVM1 was fast enough I'd let the user drag it on either side and redraw in real time... but it isn't. Maybe when we move to AVM2.

[xeen]

What's "AVM"? But yeah, Potlatch's solution is better than what you described but that doesn't mean it's optimal – Merkaartor does this better as it lets you draw both ways at the same time for example.

[Richard]

AVM is Adobe Virtual Machine. No point in coding the coolest thing in the world if Flash Player is too slow to run it.

I'm not sure that "drawing as you go" is necessarily helpful. 95% of the time I find I'm adding a parallel path to an existing way - e.g. a towpath onto an already-drawn canal.

But hey, each to their own.

[xeen]

I presume you're the same person that wrote Potlatch? I'm not criticizing your implementation, I just wanted to try out different solutions and see what's good/bad about them and brainstorm a bit on way to combine both advantages. Even if such a thing exists it's not said that it's reasonable to actually code it. I haven't started coding yet, as I work on other things, but my current idea is roughly like follows:

It's a new mode tool that when clicking a way will select the way for "parallelization". Moving the mouse draws parallel ways, distance is controlled by mouse (parallels will be placed under cursor). Click way again to cancel (or hitting esc). Default snaps to pre-defined widths. CTRL disabled snapping (like in normal drawing). ALT adds ways on both sides in equal distance (like used in graphic apps for resize around center). I thought of shift as "live draw" tool ("start new way" like in draw mode), like Merkaartor does, but as you pointed out it's much less common. It's probably to go with the basics for some time and implement it later if there's demand.

[xeen]

I looked at Potlatch's sources but I don't quite understand what the code actually does and there are no comments. Due to JOSM's and Potlatch's different implementation I'm afraid it's not just copy and paste – while I got something working it only works sometimes and I don't know why. Can anyone point me to a tutorial where the underlying algorithm is explain, I don't find the right words so that Google would ouput something useful. Thanks.

[anonymous]

If you search the Usenet group comp.graphics.algorithms (e.g. via groups.google.com) for "offset polyline" you'll find something. :)

[Richard]

(sorry, shouldn't have posted that anonymously)

[anonymous]

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

[anonymous]

Hey guys, I'd just like to mention I'm about sick of fixing split roads people have lazily drawn with one line. Without this feature it's a real pain to clean these up! Also this ticket is ~4700 ahead in the queue! PLEASE!

[stoecker]

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

[anonymous]

Hi,

I entered #4962, not realising that a requirement/suggestion had been made. Please read the description of #4962. I think it would be extremely easy to implement, and extremely useful despite being such a basic tool. It doesn't automate the solution (which would be extremely *hard* to implement) but I would use this tool immediately.

Thank you.

[stoecker]

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

[anonymous]

Hi,

The fact that there is another duplicate for this ticket indicates that people still want this feature (I do- in Korea many roads have been upgraded to dual-carriageway, so they all have to be drawn).

I will repeat my suggestion here, since I believe it would be an adequate solution and easy to implement.

My suggestion is to make a circle appear around the cursor when dragging a node. The radius of the circle is the desired distance between the two ways. There should be a simple way to set the radius of the circle.

If the roads are 10 metres apart, for example, we set the radius to 10 metres, then we can drag a node on the screen and easily see when it is 10 metres away from a line (or another node) because the edge of the circle will touch it. The actual size of the circle on-screen will change according to the zoom level of course.

For bonus points the circle could be slightly 'sticky' and will 'stick' to a way or a node that touches the circumference, but this is not strictly necessary as anything would be an improvement on my current way of drawing parallel ways by hand.

Thank you.

[anonymous]

Four years on...

Please please please!!

[olejorgenb]

Rough initial patch

[olejorgenb]

Icon file. Put in 'images/mapmode'

[olejorgenb]

Added a rough initial patch.

Operation is about the same as P2. Activate the mode (Shift-P) and drag a way to make a parallel copy. The offset distance is displayed in the status line. Works for closed ways too.

It needs work though.

TODO:

1. Make it possible to operate on multiple ways. Most intuitively is probably to preselect the ways, switch mode, and drag the selected ways.
   1. Should the new way be split in the same way as the source ways?
   2. Maybe it should be possible to select ways directly from the mode?
2. Should be possible to enter exact offset
3. Should be possible to change the offset for existing ways. Select both ways. Dragging one of them should change the offset from the other.
   1. What to do if the ways are not parallel?
4. Should be possible to make existing ways parallel. (similar to Orthogonalize) (Depending on how fancy interaction is needed, this could be a separate action)
5. What do do with tags?
6. Probably very inefficient/naive algorithm, but given that most ways are fairly short it seems to work.
7. All calculations are done in EastNorth coordinates. Is that a problem if used on very long ways? (probably rare though)
8. Should it be a plugin instead?

[bastiK]

Replying to olejorgenb:

Added a rough initial patch.

Operation is about the same as P2. Activate the mode (Shift-P) and drag a way to make a parallel copy. The offset distance is displayed in the status line. Works for closed ways too.

It needs work though.

TODO:

1. Make it possible to operate on multiple ways. Most intuitively is probably to preselect the ways, switch mode, and drag the selected ways.
   1. Should the new way be split in the same way as the source ways?
   2. Maybe it should be possible to select ways directly from the mode?

Voting for 1.2: Could be like select mode, just when a way is dragged, it isn't moved, but a parallel way is created. The mouse cursor could reflect the current state (e.g. with a special icon when hovering over a selected way, similar to draw mode).

2. Should be possible to enter exact offset

Could be done by snapping, also see this comment: ​http://josm.openstreetmap.de/ticket/67?replyto=27#comment:15

3. Should be possible to change the offset for existing ways. Select both ways. Dragging one of them should change the offset from the other.
   1. What to do if the ways are not parallel?
4. Should be possible to make existing ways parallel. (similar to Orthogonalize) (Depending on how fancy interaction is needed, this could be a separate action)
5. What do do with tags?
6. Probably very inefficient/naive algorithm, but given that most ways are fairly short it seems to work.
7. All calculations are done in EastNorth coordinates. Is that a problem if used on very long ways? (probably rare though)

Sound reasonable. There are problems with strange projections, but with Q and O tool it is the same.

8. Should it be a plugin instead?

Depends. In the current form, it will already be useful to a lot of people, so it is a good way to make the feature available while implementing some things from the TODO list. (In that case, you should get an account for svn.openstreetmap.org if you don't already have one.) On the other hand, I think it isn't that far from being ready for JOSM core. You are on your way for infinite fame. :)

[olejorgenb]

Voting for 1.2: Could be like select mode, just when a way is dragged, it isn't moved, but a parallel way is created. The mouse cursor could reflect the current state (e.g. with a special icon when hovering over a selected way, similar to draw mode).

Agreed. Seems kinda messy to reuse the SelectAction code (rectangle selection is probably not that interesting?). Some refactoring could be done of course, but not sure if it's wanted, or if I'm up to the task. I'll do something simple for now.

Could be done by snapping, also see this comment: ​http://josm.openstreetmap.de/ticket/67?replyto=27#comment:15

Still would be nice to enter an exact number, but it can wait for later. The main problem is that it seemingly is a bit awkward to get parameters from the user. Kinda off topic, but I think than an mode-specific toolbar should be available to the mapmodes.

I think it isn't that far from being ready for JOSM core.

Alright, whether it was wanted in core was what I really wanted to know. Depending on how fast the progress becomes, I might pull out a temporary plugin in it's current form.

[stoecker]

It is an often wanted feature, so I vote for core inclusion, when quality is good.

[olejorgenb]

Select ways from mode, simple snap, copy tags, works on multiple (simple connected) ways

[olejorgenb]

Update. Code still a bit rough. The mouse mess should be cleaned up.

[skyper]

Thanks a lot, this funtion is really needed.

I think a well proofed way is, to first have a new function as plugin and if it is finished, tested and used by many users it will make in sooner or later into core, like recently imagery, remote control and validator did.

Editing in Japan for example, I found many dual-carriager ways not mapped as two ways. These ways were often quite long (200+ segments, length=20-40km), so please, do not only espect short ways.

[olejorgenb]

I think a well proofed way is, to first have a new function as plugin and if it is finished, tested and used by many users it will make in sooner or later into core, like recently imagery, remote control and validator did.

Seems like it's really easy to move between plugin and core so I guess I'll package it up as a plugin this weekend.

Editing in Japan for example, I found many dual-carriager ways not mapped as two ways. These ways were often quite long (200+ segments, length=20-40km), so please, do not only espect short ways.

Well, this tool won't fix intersections, exit roads and so on. I imagine significant post-work is needed for such cleanups, making it more suitable to do in multiple sessions?

Not that is should be that hard to handle larger paths though, assuming the projection doesn't cause problems. Possible it'll work ok on faster hardware in it's current form too. It's a bit sluggish on my hardware, but so is simply moving a short way, so I'm not sure :)

[olejorgenb]

New cursor modifier. Put in images/cursor/modifier

[olejorgenb]

New cursor modifier. Put in images/cursor/modifier

[olejorgenb]

Initial cursor support, error message on invalid selection, code cleanup, more customization preferences

[olejorgenb]

Tiny bug fix, removed changes to eclipse preferences from the patch

[olejorgenb]

Converted to plugin + some improvements: ​https://github.com/olejorgenb/josm-parallel-way-plugin

[stoecker]

Why don't you add your plugin(s) to the plugin page, so users can test them?

[olejorgenb]

I have, sort of :) I put them under the "construction section" at the bottom. (https://josm.openstreetmap.de/wiki/Plugins). I can add direct links to the jar files though.

How stable and well-tested should a plugin be before it's added to SVN/the download list?

Btw, following the trail from the developers guide to get a OSM-SVN account leads you to ​http://wiki.openstreetmap.org/wiki/User_talk:TomH and

Please do not post requests for svn accounts here - email me instead.

with no email supplied :)

I think I'll like to keep them just under git for a while though. (pain for everyone to deal with multiple sources. Guess git-svn integration is supposed to be pretty good, but I haven't used it before)

[olejorgenb]

Hm, guess it wont kill anyone if there are some bugs :) Added it to the actual list.

[bastiK]

Replying to olejorgenb:

I have, sort of :) I put them under the "construction section" at the bottom. (https://josm.openstreetmap.de/wiki/Plugins). I can add direct links to the jar files though.

How stable and well-tested should a plugin be before it's added to SVN/the download list?

Btw, following the trail from the developers guide to get a OSM-SVN account leads you to ​http://wiki.openstreetmap.org/wiki/User_talk:TomH and

Please do not post requests for svn accounts here - email me instead.

with no email supplied :)

He can be found on mailing lists and IRC.

I think I'll like to keep them just under git for a while though. (pain for everyone to deal with multiple sources. Guess git-svn integration is supposed to be pretty good, but I haven't used it before)

I'd like to add it to JOSM core, are you Ok with that? Be prepared to get a couple of bug reports and feature requests! ;)

[olejorgenb]

I'd like to add it to JOSM core, are you Ok with that? Be prepared to get a couple of bug reports and feature requests! ;)

Sure :) I'll try to get some more work done the next ~week.

At least:

1. Respect the modeless setting.
2. Change the main cursor. (confusing with the same as the selection mode) A new cursor would be best probably.

[bastiK]

In [4134/josm]:

see #67 - new parallel way drawing mode (patch by Ole Jørgen Brønner)

[bastiK]

@Ole: Added a new cursor. You have the honour to close this ticket as you see fit. :)

[rickmastfan67]

To be honest, I don't know how this got missed, but I just noticed there is an internal shortcut conflict with this and another part of JOSM.

The "Parallel Way Drawing Mode" is trying to highjack the "P" shortcut from "Split Way", but is prevented from doing so. Noticed this in the CL:

Silent shortcut conflict: 'mapmode:parellel' moved by 'tools:splitobject' to 'Alt+Shift+P'.

The "Split Way" has had the "P" shortcut ever since I started editing in JOSM, so it should keep it and the "Parallel Way Drawing Mode" should be giving a new shortcut by default. It seems that it was suppose to be "Shift+P" per comment:27, but got "P" by mistake.

The location of where the shortcut is mentioned is here:
​http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/actions/mapmode/ParallelWayAction.java
Line 129

Thought I would let you guys know about this so you can fix the shortcut for it so there is no conflict with another internal shortcut.

[olejorgenb]

I thought/assumed the "Shortcut.SHIFT_DEFAULT" make a "shifted" shortcut. Shift-P works in latest (without any plugins) for me. Maybe you have some plugins installed? This thread (​http://lists.openstreetmap.org/pipermail/josm-dev/2011-June/005592.html) mention the pdf print plugin having a conflict.

More thought should probably been put into the shortcut choice. When I first created the patch I just selected something temporarily without considering other plugins :)

[rickmastfan67]

Replying to olejorgenb:

I thought/assumed the "Shortcut.SHIFT_DEFAULT" make a "shifted" shortcut. Shift-P works in latest (without any plugins) for me. Maybe you have some plugins installed? This thread (​http://lists.openstreetmap.org/pipermail/josm-dev/2011-June/005592.html) mention the pdf print plugin having a conflict.

More thought should probably been put into the shortcut choice. When I first created the patch I just selected something temporarily without considering other plugins :)

Hmmm, I'll go checking my installed plugins one by one to see which is the one that has the conflict. But I know it's not the pdf one on my end since I didn't have it installed. I'll post another reply once I've found the conflicting plugin. ;)

But I have to admit, it's just weird that whatever the conflicting plugin is forces it to try to attempt to take over the internal shortcut for "Split Way".

[olejorgenb]

But I have to admit, it's just weird that whatever the conflicting plugin is forces it to try to attempt to take over the internal shortcut for "Split Way".

Agreed. I'm not familiar with the conflict resolution code, but I guess somehow it decides that when shift-p is taken, parallel mode should get p, but can't due to split way. A bit strange that only split way is cited as the conflict though.

Greping through the svn plugins I find these using shift-p:
czechaddress, utilsplugin2 (ouch!), pdfimport

[rickmastfan67]

Found the conflicting plugin that I use.

It's "utilsplugin2" <version 26174>.

The conflict shows up when only this plugin is installed. In fact, utilsplugin2 seems to move a lot of other internal shortcuts as well. I reported some of them in #6245 awhile ago. Maybe I need to also update that ticket with just the base conflicts that happen when you only have utilsplugin2 installed and no other plugins. Anyways, here's all the conflicts (I'll copy and paste it into #6245 as well since only 1 deals with this ticket):

loading plugin 'utilsplugin2' <version 26174>
<< Downloaded some data from OSM here >>
Silent shortcut conflict: 'mapmode:parallel' moved by 'tools:splitobject' to 'Alt+Shift+P'.
Silent shortcut conflict: 'subwindow:properties' moved by 'mapmode:parallel' to 'Alt+B'.
Silent shortcut conflict: 'properties:add' moved by 'subwindow"properties' to 'Alt+C'.
Silent shortcut conflict: 'subwindow:conflict' moved by 'properties:add' to 'Alt+Shift+C'.

This was all tested with r4177 since I don't think anything major between that and r4181 happened.

[akks]

No conflict in 4186?

[rickmastfan67]

The conflict(s) is(are) still there in r4186. It only shows up once you download some data from the OSM servers or open a previously saved *.osm file.

[akks]

I have modified Utilsplugin2 - now "split objects" is bound to Ctrl-P and there are no conflicts.