[Patch] Remove need for left-right-hand-traffic.osm

[GerdP]

In the German OSM forum a user reports a strange problem which sends JOSM into an endless loop while calculating the data for RightAndLefthandTraffic. While this error seems to be caused by either hardware or JRE problems I think there is no need to do the calculations in JoinAreasAction at all. My understanding is that JOSM always reads (and stores) the file boundaries.osm in class Territories and therefore we just have to combine the ways. The calculation is done in ~20 ms on my machine, so I see no need to store a file left-right-hand-traffic.osm in the cachhe directory, esp. when this file is not updated after a change of boundaries.osm.
The attached patch removes the corresponding code. If wanted, we may keep the code to be able to visualize the data.

"main-init-1" #24 prio=5 os_prio=15 tid=0x000000089c5e1000 nid=0x188c3 runnable [0x00007fffde4e3000]
   java.lang.Thread.State: RUNNABLE
        at org.openstreetmap.josm.actions.JoinAreasAction$WayTraverser.getAngle(JoinAreasAction.java:333)
        at org.openstreetmap.josm.actions.JoinAreasAction$WayTraverser.leftComingWay(JoinAreasAction.java:421)
        at org.openstreetmap.josm.actions.JoinAreasAction.findBoundaryPolygons(JoinAreasAction.java:1175)
        at org.openstreetmap.josm.actions.JoinAreasAction.joinAreas(JoinAreasAction.java:664)
        at org.openstreetmap.josm.tools.RightAndLefthandTraffic.computeOptimizedBoundaries(RightAndLefthandTraffic.java:121)
        at org.openstreetmap.josm.tools.RightAndLefthandTraffic.initialize(RightAndLefthandTraffic.java:72)
        - locked <0x0000000814356e38> (a java.lang.Class for org.openstreetmap.josm.tools.RightAndLefthandTraffic)
        at org.openstreetmap.josm.gui.MainInitialization$$Lambda$144/1233505227.run(Unknown Source)
        at org.openstreetmap.josm.spi.lifecycle.InitializationTask.call(InitializationTask.java:33)
        at org.openstreetmap.josm.spi.lifecycle.InitializationTask.call(InitializationTask.java:11)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

[GerdP]

Forgot the link to the forum: ​https://forum.openstreetmap.org/viewtopic.php?id=64921

[Don-vip]

Did you check to run the validator against large datasets? 20ms can be a huge performance penalty if the calculation is done per primitive. I'm sure I did it for a good reason in r11247 and doubt the removal would be without consequence.

[GerdP]

The calculation is done once during initialization of RightAndLefthandTraffic. I see no need to execute the JoinAreasAction, maybe that took long?

[GerdP]

Before I created this patch I've tested the result by converting the DefaultGeoProperty.area back to OSM format.
The shapes looked exactly like those from left-right-hand-traffic.osm. If you If you like I can post a patch which implements this.

[GerdP]

I looked at the code in r11247. At that time the areas where not combined, instead there was a loop:

        public Boolean get(LatLon ll) {
            for (Area a : leftHandTrafficPolygons) {
                if (a.contains(ll.lon(), ll.lat()))
                    return Boolean.TRUE;
            }
            return Boolean.FALSE;
        }

So, it probably was a good idea to use JoinAreasAction to reduce the number of areas in collection leftHandTrafficPolygons and to safe that result in a file. With the current code there is no need for it.

[GerdP]

@Don-vip: Do you want me to change the patch? If I hear nothing I'll commit it tomorrow.

[Don-vip]

Replying to GerdP:

With the current code there is no need for it.

OK thank you for the investigation, this was the missing piece of information I needed to be convinced. You can go on :)

[GerdP]

In 14720/josm:

fix #17224: Remove need for left-right-hand-traffic.osm