August 2015 - mkgmap-dev - The mkgmap lists

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

Exclude POIs from index
by Dave Swarthout 25 Aug '15

25 Aug '15

When I search for All POIs on my Garmin Montana I get many useless unnamed POIs, even power poles, barriers, houses, etc. Is there some way to tell mkgmap to exclude such POIs from its search results? -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

6 6

Commit: r3633: correction: don't ignore the no-u--turn restrictions that are generated by an only* route restriction
by svn commit 25 Aug '15

25 Aug '15

Version mkgmap-r3633 was committed by gerd on Tue, 25 Aug 2015 correction: don't ignore the no-u--turn restrictions that are generated by an only* route restriction

1 0

patch for omitting nearby POIs with the same name and type
by Mike Baggaley 24 Aug '15

24 Aug '15

Hi, please find attached a patch that adds two new options: --max-same-poi-distance=distance and --include-nearby-poi-types=type[,type...]. These options are used to determine whether nearby POIS are duplicates and should be omitted from the map, extending the existing check for duplicates at the exact same location. They help to reduce the problems cause by OSM data frequently having an area such as a building tagged with the same information as a point or where multiple areas are given the same name - this is most problematic if the --add-pois-to-areas option is used. It may be valid for some named POI types to be found close together hence the option to omit certain types of POI from the nearby processing. I have the distance set to 50 with bus stops and cave entrances always included and this seems to work well for me (I don't use the default style). If --max-same-poi-distance is omitted or set to 0, the check works as previously. Please try and if OK, commit. Thanks, Mike

2 2

[Patch v0] fix sharp angles to optimise bicycle routing
by Gerd Petermann 24 Aug '15

24 Aug '15

Hi all, attached is a first working version of the patch, please test it with your style. I've also uploaded a binary: http://files.mkgmap.org.uk/download/277/mkgmap.jar It implements two new options: --x-fix-sharp-angles (I plan to remove this option when the code is ready, I now think the fixing should always be enabled) Is needed to activate the new code. --x-cycle-map Should be used when the map is only usable for cycling and walking, means, all vehicles (except foot) are treated like bicycles. (like with styles from Minko or Felix) The patch also removes the code for the option --adjust-turn-headings. The important code is in a new class AngleChecker, when you want to see what it does you should enable logging on info level like this: uk.me.parabola.imgfmt.app.net.AngleChecker.level=INFO When you find a message like ... sharp angle 28° at 38.343434,-0.770673 headings 40° 68° speeds 2 2 dest nodes 311 2103 followed by ... sharp angle 28° at 38.343434,-0.770673 changing arc with heading 68° -> 85° angle is now 45° you may want to compare the routing results for that location, once with and once without the option. (In Basecamp and Mapsource you can use Ctrl+T to jump to the location printed in the msg) While testing the code I found one problem in OSM data: Sometimes roads are duplicated, means, one road (or a part of it) hides the other. I consider this as a potential error in the OSM data, so a warning like this is produced: WARN: uk.me.parabola.imgfmt.app.net.AngleChecker 63240007.o5m: sharp angle < 1° at 38.355308,-0.483420 ,maybe duplicated OSM way with bearing 359° The message doesn't contain any OSM Id because often the available Ids are missleading due to the merging of roads. I use JOSM to fix these errors: Use Ctrl+J to jump to the given position (38.355308,-0.483420) and download a small area around the point. Next, use Alt+left mouse click multiple times on the node to see the connected roads. Gerd

3 3

What's the meaning of the 'has no region' warnings?
by Carlos Dávila 24 Aug '15

24 Aug '15

What is supposed to be wrong regarding warnings of type '(MapBuilder): 55114001.o5m: Highway EX-A2 has no region (define a default region to zap this warning)'

5 9

[Patch v1] fix sharp angles to optimise bicycle routing
by Gerd Petermann 24 Aug '15

24 Aug '15

Hi all, I just noted that v0 was not complete (source for AngleChecker missing). Attached is the new patch based on r3632, no functional change, but with less noise in logging. Binary: http://files.mkgmap.org.uk/download/278/mkgmap.jar Some more remarks: - The current code considers angles <= 45 as sharp. I am not sure about this value, maybe it should depend on the combination of road class/speed values that appear in the two arcs. I am working on this. - In some cases the log will show e.g. ... sharp angle 24° at 53.152893,8.711292 don't know how to fix it I think they are good candidates for an algo that adds an arc as suggested by Felix. For the node at 53.152893,8.711292 I would want to add an arc between the nodes 3305128837 and 2902056869. Maybe I find a way to code that... Gerd

1 0