Opened 4 years ago

Closed 4 years ago

#17224 closed defect (fixed)

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

Reported by: GerdP Owned by: team
Priority: normal Milestone: 19.01
Component: Core Version:
Keywords: Cc:


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(
        at org.openstreetmap.josm.actions.JoinAreasAction$WayTraverser.leftComingWay(
        at org.openstreetmap.josm.actions.JoinAreasAction.findBoundaryPolygons(
        at org.openstreetmap.josm.actions.JoinAreasAction.joinAreas(
        - locked <0x0000000814356e38> (a java.lang.Class for
        at org.openstreetmap.josm.gui.MainInitialization$$Lambda$144/ Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(
        at java.util.concurrent.ThreadPoolExecutor$

Attachments (1)

17224.patch (6.6 KB) - added by GerdP 4 years ago.

Download all attachments as: .zip

Change History (9)

Changed 4 years ago by GerdP

Attachment: 17224.patch added

comment:2 Changed 4 years ago by 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.

comment:3 Changed 4 years ago by GerdP

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

comment:4 Changed 4 years ago by 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.

comment:5 Changed 4 years ago by 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(),
                    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.

Last edited 4 years ago by Don-vip (previous) (diff)

comment:6 Changed 4 years ago by GerdP

Milestone: 19.01

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

comment:7 in reply to:  5 Changed 4 years ago by 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 :)

comment:8 Changed 4 years ago by GerdP

Resolution: fixed
Status: newclosed

In 14720/josm:

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

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.