New JOSM plugin KindaHackedInUtils

[tvbrene]

I’ve long contemplated if I should even release this plugin since it’s kind of hacky. But it’s very useful for me, so maybe for others too.

First the hacky functions:

• creating a new point under the mouse pointer with pressing B on the keyboard
• splitting a way under the mouse pointer with pressing I
• option to get JOSM to foreground (make it the active window) when the mouse enters the map view
• getting the direction for a node (for instance for a traffic sign) from the mouse position relative to the node and ways the mouse points to or not, more about it below

The B and I functions just simulate activating the draw/split mode and then clicking with the mouse at the desired position.

Additionally there is one non hacky action to detach nodes of a closed way from a way and move them away from the existing nodes.

So for example look at this situation:

The areas are ending with the way, not where they really end. The function to detach the nodes is triggered with pressing Z or selecting the action from the more tools menu and will result in the following:

In this example 2 new nodes were created and they move inwards the area. The nodes are detached from the selected way for all closed ways that share the node. It’s also possible to select the closed way and press Z, it will result in detaching only the nodes of the selected closed way from not closed ways they share, nodes only shared with other closed ways will not be detached.

Further explanation of the direction function, first look at this situation:

The traffic sign city limit has a direction set to forward. But does this identify the ways that are outside/inside the city? It clearly doesn’t. It could either mean the street that goes to the upper left or the one that goes to the upper right. A possible solution would be to add more than one city limit traffic sign to the ways affected, another to map the city limit exactly where it is placed besides the street with a separate node or just use the degrees value for the node in the middle. It will make clear which parts of the streets are outside the city and which are inside. And this is where the direction function comes in handy. Instead of using the draw mode to get the degree value and then manually add it to the node just select the node and point the mouse behind the traffic sign in the direction it’s placed and press H on the keyboard and the direction value will be the correct degree value taking into account that it is mapped with the opposite direction.

So the values forward and backward for a traffic sign should only be used when they are unambiguous, which means when they are inside a way, not at the end or start and no other way is intersecting the node.

The H action will check this for you, whenever forward/backward can be used, it will be used (if you don’t disable this function in the settings). For 2 ways that share the last and the first node the direction is automatically set to a degree value even if you use forward/backward as long as it unambiguous in the situation. If it’s not you will be see a popup menu for selecting the possible directions for that node. For more complicated intersections it might not be working and you will need to add the degree value like described above with pointing the mouse and pressing H.

For example this speed limit sign is inside the way because it is only a reminder, so forward/backward works:

The same sign at the start of the speed limit can be ambiguous in some situations like this:

Here forward will not work because both affected ways fit that value. Using the degree value get’s around that problem, especially in situations in which the direction of the ways itself cannot or should not be changed.

[daganzdaanda]

Hi, thanks for releasing this plugin!

The “Z” function has great time saving potential I’ve just tested it and it seems to work very well. The separated landuse area can be quickly finetuned with the improve line accuracy “W” tool. It is great that areas stay connected, while ways are “untangled”.

The “H” function is cool, too, I can see me starting to map the orientation of lots of things if it’s so quick and easy.

Maybe I am misunderstanding something, but it seems that the behaviour is not consistent depending on the kind of sign/tag on the node:

The single OSM way goes W->E here. The nodes from left to right are hw=give_way, hw=stop, hw=traffic_signals, traffic_sign=DE:250, traffic_sign=DE:274[60].
Select a node and move the mouse left (W) and press H. For the give_way and stop, I get direction=W. This seems right to me, the sign points in the direction where I moved the mouse.
But for the other nodes, the result will be traffic_signals:direction=backward and direction=backward. This would mean the traffic light and the other signs are valid for cars coming from the opposite direction of the OSM way, meaning from the east.
I would expect the direction to be “forward”, to be consistent with the stop / give_way.

Also, hw=stop|giveway could maybe be getting simple “forward/backward” directions in the example, too?

Key:direction#Relative_to_OSM_way states

Do not use the simple direction tag for highway=traffic_signals and traffic_sign=* that are part of a way, instead use traffic_signals:direction=forward/backward and traffic_sign:direction=forward/backward . Unfortunately a lot of road-bound traffic signs have still the key direction still set.

I didn’t know that up to now… The wiki for traffic_sign:direction is a bit more relaxed about it. EDIT I just noticed you made an option for this in the settings. Nice!

---

The “B” shortcut is already used for the building tool in my JOSM. Now when I press B, a new node is created (but ~100px south of the mouse pointer), and JOSM switches to building-drawing mode.
ETA: now after playing around longer, pressing B will get me a new node at the mouse pointer. That’s weird.

---

The “I” shortcut is taken for “select crossing lines” in my JOSM. Now when I press “I”, I get an reproducible error.

---

That’s it for my quick test report of your nice new plugin. I think just for the “Z” mode, it’s worth keeping! The direction helper is already good and potentially great. With “B”, I guess it could speed things up a bit after getting used to it, but it behaved buggy when I first tried. Same with “I”, but couldn’t test it at all.

[tvbrene]

The Z function is a result of my frustration with regions in which I had to unglue the areas from the ways. It’s extremely time consuming to do. But with Z I can use it as an advantage, for example this curve:

It has areas attached to the nodes of the highways and doesn’t look so nice. Before I would select the nodes and unglue them and then draw new nodes for the areas and the highways. Now I just can make the highways look nice without unglueing any node and then press Z and will get:

The movement is based on the typical width of a German primary highway and the result doesn’t need any further tuning and with a lot less work.

The direction does depends on the existing tags of a node. The key traffic_sign and the setting highway=traffic_lights will trigger the different handling but maybe I should add highway=stop/give_way to that list but I’m not aware that they even have a direction that can be set or is used by anyone. I’ve always map them with the additional German traffic_sign for stop and give way, so the traffic sign handling will automatically kick in.

I’ve had to come up with a solution for the direction since a traffic signs can be placed in both directions of a way, so it needs a distinction between forward/backward depending on where the mouse is relative to the node, the way sections pointed to and the direction of the way.

How this works:

The node in the middle should get a direction. If the node is just a node it will get the direction you can see in the draw mode in the status bar for the compass when a line is drawn from that node as a starting point with the slightly change that each number that matches a cardinal direction (and it’s sub directions) is swapped with it.

If the node has a traffic_light, the key traffic_signal:direction will be used and the forward/backward areas come into place. The forward area is always a 180° angle around the node in forward direction of the way. So as long as the mouse is in the forward area the direction will be forward, if it is in the backward area it will get backward. The exception from that rule is triggered by the way itself. so if the mouse is pointing on the way (the way is highlighted) it depends if the way section A or B is pointed to. If the mouse hovers over A it’s forward, if the mouse hovers over B it’s backward.

If the key traffic_sign is present it will get even more convoluted. As long as the node is inside a way it will work just like described for the traffic signal. If the node is a start/end node of a way it will use the degree value like for any other node without the special keys. But here it gets complicated because of the way the degree direction for traffic signs is mapped. In the draw mode for example you would see a degree value of 210, the value for the traffic sign will be 30 because traffic signs are mapped depending on the front side of the sign (so the side with the printing on). Here the value will be a 90° angle pointing away from the front side of the sign. The H mode will take that into account so the user doesn’t have to (if natural direction is enabled), you would point to the way section that is affected by the sign (for example the speed limit is 30 for a 30 sign) and press H, to get the correct degree value (so the opposite of the value any other node direction would get). So the results you’ve got are consistent with the way it is intended to work.

Personally I think using the degree value is the best to map the direction since it’s always unambiguous, nothing will break the direction. A direction of forward/backward can easily be made wrong if someone changes the direction of a way with an editor that doesn’t warns the user or if the user just ignores the warning, But traffic_sign:direction only allows forward/backward values, so I prefer using direction for traffic signs on start/end nodes and the H mode will use the keydirection for start/end nodes regardless of the setting and it will also nudge the user to use or even force that key if it notices a forward/backward value on such a node if the key traffic_sign is present and the tags of that node are changed in any way. It’s just as I explained above with the intersecting oneways that mark the start of a urban area. With SHIFT+ALT+H the direction will always be a degree value regardless of the setting.

The B function translates the mouse location of the screen to the mouse location of the map view, maybe there is a problem on multi screens otherwise I’ve no idea why the node would appear at a different location.

The problem with the key being used for other actions is one of the things I ment with hacky. I’ve scanned the used keys side for JOSM to find the direct keys that were still free and since the keys are hardcoded in a way that JOSM will not know those keys it cannot be changed in the keyboard settings. But because of your post I just had an idea how that might be accomplished.

[daganzdaanda]

@tvbrene

So as long as the mouse is in the forward area the direction will be forward, if it is in the backward area it will get backward.

Yes, and I think this is inconsistent with the way it works on signs.
With signs, the direction I move the mouse in will be the direction that sign is facing. With traffic lights, it will be the other way round right now.

I think the sign handling makes perfect sense, and the traffic lights should be using the same logic: When you move the mouse in one direction, make this the direction the lights will point to. So if you move into the forward side “A”, that means the lights are pointing into the “A” side, the direction tagged on the light will need to be “backward” because the cars coming from A are travelling against the OSM way’s direction.

See also Tag:highway=traffic_signals - OpenStreetMap Wiki

traffic_signals:direction – Indicates the traffic signals signal only the traffic moving in the same direction as the OSM (highway) way upon which the they are placed: forward; or in the reverse direction: backward.

[tvbrene]

I think you misunderstand how the direction for traffic signs and traffic signals work. When forward/backward is used it’s based on the movement of the traffic. So if you drive on the road from B to A over the point in the middle the direction is forward for every traffic sign or traffic light you see the front side of. If you drive from B to A over the point in the middle and see the front side of a traffic sign or traffic light, the direction for them is backward.

Pointing the mouse in the forward area or at A results in forward. Pointing the mouse in the backward area or at B results in backward. This is consistent for traffic signs and traffic signals.

Only for traffic signs that are at the start/end node (or are on a separate node) this will differ such as that the direction is the opposite of the traffic travelling on a road.

It’s just like the wiki description for traffic_signals:direction explains.

traffic_signals:direction=forward Only traffic which passes in the same direction as the way is affected.

https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction

@daganzdaanda

With signs, the direction I move the mouse in will be the direction that sign is facing.

For forward/backward this is never true. You have to point the mouse in the forward area which means the side that is on the back of the traffic sign (the direction the traffic is travelling to for signs that affect the traffic that travels on the road in the direction of the way) if you want to get forward as a result. For the degree value it’s also not true if natural direction is enabled in the settings. Which means the degree value will be calculated the same way it would be if forward/backward would be used. So pointing behind the sign in travelling direction will give you the degree the sign is facing, which is how traffic signs are mapped. If you disable natural direction the user has to know that traffic signs are mapped different and has to point away from the front side which is confusing because it would be exactly the opposite of the mouse position a user has to point for forward/backward directions.

If you don’t get the same result for the direction of a node inside a way with highway=traffic_signals or traffic_sign=* I’ve no idea why. For me this works just like I want it to.

I find this really hard to explain but pointing on the part of the way affected by the sign should be the easiest way to grasp. Especially for speed limits this is intuitive, you have a road sign that causes a speed limit on the part of a road behind the sign. Pointing on the part that has the speed limit and pressing H seems to be the easiest to grasp. Everything else follows from this one decision I’ve made.

This principle is good to see if you put a traffic sign on an end/start node inside a road or a junction (at which all ways end or start). The plugin will show a popup menu for all possible degree values for that node and when you hover over a menu entry with a degree value it will highlight the part of the road that is affected by the sign, so in the speed limit example it would be the part of the street with the speed limit.

Regardless of all that I’ve released an update which switches the key I with the key K, which should not be used by JOSM by default. All other keys are the same but all now can be changed in the keyboard settings of JOSM. If 2 or more plugins use the same key JOSM will switch them out with an unused keyboard shortcut for one of them. So B or K might be something completely different depending on which other plugins are installed that use those keys also.

[daganzdaanda]

Thanks for the update, now the behaviour is consistent between hw=give_way/stop, hw=traffic_signals and traffic_sign=* in the middle of a single way. That’s good!

But it’s still not perfect IMHO

In this image, there are hw=give_way hw=stop, hw=traffic_signals and traffic_sign=* nodes in row 1 and 3. In row 2 the same are part of a continuous way going left to right (W->E). The white arrows are from a drawing style “Ausrichtung / Direction” by Hanikatu.

For all of the nodes, I moved the mouse to the left and pressed “H”.

The first row gave me what I think are perfect results: The direction arrow points left, indicating from which direction the sign / light can be seen and also for which direction it is relevant.

The second row resulted in all the nodes getting a “backward” direction, meaning the signs and light are now relevant for traffic coming from the right. This is opposite to what happened with the single nodes. Don’t you agree?

The last row shows what happens when the “natural direction” setting is activated. It only takes effect on the traffic_sign=* node. (It also does not affect any nodes on a way.)

IMHO, the behaviour with nodes on a single way should be exactly the opposite, to be in line with the very sensible default.
Maybe, to give people a choice, you could call the “natural direction” setting something like “switch behaviour around” and make it affect all possible situations.

[daganzdaanda]

@tvbrene

but pointing on the part of the way affected by the sign should be the easiest way to grasp. Especially for speed limits this is intuitive, you have a road sign that causes a speed limit on the part of a road behind the sign. Pointing on the part that has the speed limit and pressing H seems to be the easiest to grasp. Everything else follows from this one decision I’ve made.

Hm, I can see what you mean, but I don’t think it’s the most intuitive way. The speed limit will need to be tagged on the part of road behind the sign. But the sign is visible from the road before it. A traffic light will not affect the road behind it, because it is only visible from one side.

[daganzdaanda]

Just a quick note: I also get the exeption / crash with the new “K” key. I don’t have time to investigate now, but I opened an Github issue with the report for the old version

[tvbrene]

Thanks for testing.

If you get the results your screenshot is showing you must have disabled natural direction in the settings. This is exactly what I mean when forward/backward is used it’s the opposite rule to a degree value, which is why I think it’s best to handle it the same way with natural direction. To change the backward/forward areas and way pointing would be much more confusing. You would point in the forward direction of the sign and would get backward as direction. You obviously know how to map, so you see it opposite because for you the front side of the sign is the thing to look at. For those who know exactly what they are doing I’ve added the option to disable natural direction to so you are able to do it knowing that you have to point to the other direction, but for ways it’s still based on the rule of the travelling traffic.

I would suggest to get used to the natural option, in the end it’s a lot easier that way because you just have to take the direction of the travelling traffic into account. Previously I’ve mapped it the other way around but it needed a lot of concentration to get it right every time, when mapping a huge data set. Now I just need to point to the affected part of the way and it will be right and with the popup menu I get a visual hint which part of a way will be affected by the sign I’m mapping.

I see it different for traffic signals also. The signal will always regulate the traffic behind the signal not before. The traffic is coming to a halt before the signal, but that is not the reason why the signal is there, it is there to regulate the traffic at the intersection. It’s the same like a STOP sign. It will cause the traffic to stop at the sign, but it regulates the intersection behind it.

Typically no traffic sign will regulate anything before the sign. There are some special cases like the German VZ 240 with the additional sign VZ 1000-30 which are sometimes placed in a 90° angle of a shared foot and bicycle way, so this combination regulates left and right before the sign. But some things are just impossible to handle automatically. At the end the user will have to know what to do.

With the newest version you will get the popup menu for each node of a way that has a traffic sign and the direction is missing or is ambiguous. The easiest to test is with two ways and a traffic sign at the intersection. The ways don’t have to be separated anymore to see which way part is affected by the sign. The way segment will be highlighted for each degree value that is hovered over with the mouse.

I’ve been using a highly altered version of JOSM which is based on an older version, so there might be some changes that cause the error. I will look into it.

[tvbrene]

I’ve found the bug, the split mode should work now. Additionally I’ve added a secret option to revert the forward/backward handling. You have to set a forward/backward direction first with H for the option to show up in the Advanced Preferences or you have to create it there as a simple preference.

The preference kindahackedinutils.oppositeSimpleDirection then has to be set to true. This will work in combination with the natural direction preference. Only when natural direction is disabled the forward/backward areas will be switched if the hidden preference is set to true. So when you point in the direction of the way behind the sign it will get backward instead of forward.

[daganzdaanda]

@tvbrene

preference kindahackedinutils.oppositeSimpleDirection

Thank you, it works well! Now I can configure the tool to fit my logic better

[daganzdaanda]

@tvbrene

With the newest version you will get the popup menu for each node of a way that has a traffic sign and the direction is missing or is ambiguous.

This looks very fine, too. I just think in real life I would always remove a traffic sign that is mapped at a junction point, and move it to the way where its meaning will be clear. If necessary, the physical sign could be mapped with a separate node at the true position next to the way.

[daganzdaanda]

@tvbrene

the split mode should work now

Well, right now with my JOSM, I don’t get an error anymore, but also nothing else happens The shortcut “K” is showing up in the keyboard preferences, so it looks like it’s registered correctly.

[tvbrene]

I’ve looked into it, it just needed to be a bit more hacky to work. The location of the mouse is now directly read from the map view, so it should be correct in any configuration.

I prefer traffic signs to be on a node of a way, so it will be present when the way is. Especially for speed limits and city limit signs that always are at a node that separates two ways when the speed limit starts at that node and then the degree value will be used.

[daganzdaanda]

Great, it’s working as advertised now Thanks for the quick updates!
I think this plugin is really very useful, hope many people find it.

[dieterdreist (Martin Koppenhöfer)]

Especially for speed limits and city limit signs that always are at a node that separates two ways when the speed limit starts at that node and then the degree value will be used.

when the sign node is at the side the direction is implicit and degree values are not required. I always regarded these traffic sign objects more relevant for other mapper to understand the situation rather than software which uses the properties on the objects (effects of the sign, already extracted by a mapper and put on the interested parts where they apply to)

[daganzdaanda]

I’m still amazed at the “Z” functionality!
I usually hated when I came across a road/track stuck to landuse, because it was such a chore to clean up. Now I think I’ll actively be looking for such things, because it will be fun to deal with

But the “kinda hacked” name is not completely wrong either I found another bug, copy and paste throws an exception.

[tvbrene]

If having bugs would be any kind of basis for the name of a software than all would have such a name. The name is more about the “hijacking” of other functions and the trial and error approach to the Z function. It sometimes will move the nodes in the wrong direction if the trial and error fails because it just tries if a certain location is inside the area or outside and for some angles the test is successful even though it’s the direction opposite to the area.

[daganzdaanda]

Thanks for explaining the motivation behind the name. Interesting!
No software will probably ever be without a bug, only TEX comes close

The latest version hasn’t fixed it for me, I added more info at the GitHub issue.

[tvbrene]

Thanks for the good explanation how to get the error. It’s way easier to find if to know how to reproduce it.

As a gimmick you might be interested in my alteration of the alteration of the improve way function. My version of the ImproveWay plugin has all the helper visualizations enabled, a way under the mouse can be selected with pressing W again and when the mouse is moved in the direction of a node of another way and the distance between that node the mouse position relative to the current node is shorter the way is selected automatically. So it’s a lot quicker to improve adjacent ways.
https://tvbrowser.org/downloads/ImproveWay.jar

To use it with W just disable the shortcut for the build in shortcut.