- mkgmap-dev - The mkgmap lists

Commit: r3638: fix two small problems in the unit tests:
by svn commit 31 Aug '15

31 Aug '15

Version mkgmap-r3638 was committed by gerd on Mon, 31 Aug 2015 fix two small problems in the unit tests: 1) an osmmap.img was remaining 2) a file args was not closed and produced this error message: [junit] Running uk.me.parabola.mkgmap.CommandArgsTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0,071 sec [junit] Exception in thread "Thread-1" java.lang.AssertionError: delete existing file: args [junit] at org.junit.Assert.fail(Assert.java:88) [junit] at org.junit.Assert.assertTrue(Assert.java:41) [junit] at func.lib.TestUtils.deleteOutputFiles(TestUtils.java:75) [junit] at func.lib.TestUtils$1.run(TestUtils.java:59) [junit] at java.lang.Thread.run(Thread.java:745)

1 0

[Patch v1] unit tests
by Gerd Petermann 31 Aug '15

31 Aug '15

Hi Steve, please review the attached patch. It fixes two small problems in the unit tests: 1) an osmmap.img was remaining 2) a file args was not closed and produced this error message: [junit] Running uk.me.parabola.mkgmap.CommandArgsTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0,071 sec [junit] Exception in thread "Thread-1" java.lang.AssertionError: delete existing file: args [junit] at org.junit.Assert.fail(Assert.java:88) [junit] at org.junit.Assert.assertTrue(Assert.java:41) [junit] at func.lib.TestUtils.deleteOutputFiles(TestUtils.java:75) [junit] at func.lib.TestUtils$1.run(TestUtils.java:59) [junit] at java.lang.Thread.run(Thread.java:745) Gerd

2 1

Commit: r3637: improve checks for raddr:interpolation ways
by svn commit 30 Aug '15

30 Aug '15

Version mkgmap-r3637 was committed by gerd on Sun, 30 Aug 2015 improve checks for raddr:interpolation ways - log a warning message when city or zip code is different, no effect on output - ignore duplicate addresses produced by interpolated houses when the distance is < 100 (was < 40) - don't ignore duplicate addresses produced by interpolated houses when the distance is > 150 (this check was added by mistake with r3635) - improve logging: report more details about the elements that cause a conflict - only ignore addr:interpolation ways with equal street and start and end numbers when they are in the same city, if so, report both ways in the "found additional addr:interpolation way with same meaning ... " message

1 0

Commit: r3636: remove dead code
by svn commit 30 Aug '15

30 Aug '15

Version mkgmap-r3636 was committed by gerd on Sun, 30 Aug 2015 remove dead code

1 0

Commit: r3635: corrections to addr:interpolation way checks
by svn commit 29 Aug '15

29 Aug '15

Version mkgmap-r3635 was committed by gerd on Fri, 28 Aug 2015 corrections to addr:interpolation way checks - The checks did not notice when a "duplicated number" belongs to a different cityInfo - The checks allowed only 5m distance between an existing address and the interpolated one, this is changed to 40m - some improvements in logging

3 3

[Patch v1] mkgmap ignores addr:interpolation ways
by Gerd Petermann 28 Aug '15

28 Aug '15

Hi all, see this thread : http://gis.19327.n5.nabble.com/Commit-r3632-fix-possible-message-internal-e… I think Anor Carlos pointed out that mkgmap should not ignore a more or less valid addr:interpolation way. This can happen when someone adds a POI with addr:housenumber and addr:street and doesn't connect the POI node to the addr:interpolation way. Or when someone adds the way without recognizing that the POI has a valid address. Up to now mkgmap prefers to ignore the complete addr:interpolation way when such a node is too far from the interpolated position and "too far" means 5 m, which is probably too restrictive. I guess this is likely to happen and I've changed the code to add a message to the log with r3634. Attached is a patch that changes the tolerated distance to 40 m and further improves logging. If I hear no complains I'll commit this patch on monday. @Anor: Please try the binary at http://files.mkgmap.org.uk/download/279/mkgmap.jar with enabled logging, e.g. uk.me.parabola.mkgmap.osmstyle.housenumber.level=INFO Gerd

1 1

Commit: r3632: fix possible message "internal error: via way is updated again" followed by "internal error: via way doesn't contain points in expected position"
by svn commit 27 Aug '15

27 Aug '15

Version mkgmap-r3632 was committed by gerd on Sun, 23 Aug 2015 fix possible message "internal error: via way is updated again" followed by "internal error: via way doesn't contain points in expected position" The error message is sometimes produced when a style creates multiple routable ways for one OSM way and that way is used as a via way in a restriction relation. The old code ignored the (valid) restriction, now it is considered.

3 6

Commit: r3634: print warning when a addr:interpolation way is ignored because it produces duplicates
by svn commit 27 Aug '15

27 Aug '15

Version mkgmap-r3634 was committed by gerd on Thu, 27 Aug 2015 print warning when a addr:interpolation way is ignored because it produces duplicates

1 0

some results regarding sharp angels
by Gerd Petermann 27 Aug '15

27 Aug '15

Hi all, testing the effects of angles on routing is quite difficult. I've disabled all road type avoidances and feature type avoidances to make sure that possible detours are not discarded. I have created a few routes which (in the best case for cycling), would just visit the node with the sharp angle, but instead showed detours using car as vehicle. I've then created the map again and again with different road_speed values and different values for the headings at the junction and tested the effects (this process is very error prone, one has to press Ctrl+G two times to make sure that the new map is read from disk again, and one has to make sure that all options are the same). I tried Basecamp and MapSource, they are not always showing the same results. Since MapSource is no longer maintained I think I should ignore it here. My findings so far: - the settings "Faster Time" and "Shorter Distance" don't have the expected effect. Sometimes a detour disappears when changing between the two options, but the calculated time/distance values don't explain the result. Sometimes the shorter route is only selected when "Faster Time" is enabled. - The Garmin routing algo seems to ignore the angle completely when the route follows the same road. To be precise: The same MapRoad instance. Without road merging this typically also means "one OSM way". If I got it right, RoadMerger will not merge roads that build sharp angles, and it prefers to merge those roads which build a straight line at the merge point. - As expected, a left turn (in a drive-on=right area) gets a higher time penalty than a right turn, I did not yet analyse if this also depends on other arcs at the node. - The time penalty depends on the angle and on the road speed: + road_speed=3 or 4 seems to require > 67.5° + road_speed=5 to 7 seems to require > 90° which not really a sharp angle ;-) If the angle is smaller, the turn is avoided. - technical info: The threshold values for the angles are probably explained by the way how the initial heading is stored in the img file: the so called "compacted format" uses only 4 bits, so the value is heavily rounded. It is used when the rounded initial headings of the arcs at a node are all different. Modifying the initial heading values can be a solution in some cases, but not in all. Conclusion: A road_speed>=5 should be avoided in cycling maps. Even a road_speed >= 3 is problematic, angles with < 67.5° appear very often, esp. in towns where cycle ways are sometimes drawn besides the road and then joined with the road later without caring much about angles. The effect: Two junctions are connected with 3 or more arcs, one for the road, two for the cycle ways, sometimes even more when the style creates additional arcs for the same OSM way. I think about an alternative optimisation that tries to detect this case and somehow combines the arcs, but that seems to be even more complex. Still working on sharp-angles-v2.patch ... Gerd

1 0

question with poi
by Steve Sgalowski 27 Aug '15

27 Aug '15

is there a way guys , that poi's can be loaded on to highway or all types of roads ? (highway=motorway_link | highway=trunk_link) & mkgmap:exit_hint=true & mkgmap:dest_hint=true { name '${destination:ref|subst: =>} ${destination|subst:;=> |subst:/=> }' | '${ref|subst: =>} ${destination|subst:;=> |subst:/=> }' | '${destination|subst:;=> |subst:/=> }' | 'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_name}' | 'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_exit_to}' | 'Exit ${mkgmap:exit_hint_exit_to}' | 'Exit ${mkgmap:exit_hint_name}' | 'Exit ${mkgmap:exit_hint_ref}' } done in the same setup , when this is done , or setup a new one for poi's with say distance from you to the point ? Stephen

1 0