- mkgmap-dev - The mkgmap lists

Commit: r2733: cleanup dead code
by svn commit 04 Oct '13

04 Oct '13

Version 2733 was committed by gerd on Fri, 04 Oct 2013 cleanup dead code

1 0

Commit: r2731: Fix that too much ways excluded from destination handling
by svn commit 03 Oct '13

03 Oct '13

Version 2731 was committed by wanmil on Thu, 03 Oct 2013 Fix that too much ways excluded from destination handling When using the option --process-destination a way is only processed if it has no predecessor with the same destination tag. The check was wrong because it only checked if the ways were connected. Instead it must check if their start/end points are the same.

1 0

Commit: r2730: Characters not in a code page are now transliterated to ascii.
by svn commit 03 Oct '13

03 Oct '13

Version 2730 was committed by steve on Thu, 03 Oct 2013 Characters not in a code page are now transliterated to ascii. Move the transliteration step as an error handler for characters that do not exist in the target character set. This allows us to transliterate to ascii rather than displaying a question mark. This is a merge of branches/transliterate@2713

1 0

question regarding length
by GerdP 03 Oct '13

03 Oct '13

Hi Steve, in mkgmap.jar (RouteArc) we use private static int convertMeters(double l) { // XXX: really a constant factor? // this factor derived by looking at a variety // of arcs in an IMG of Berlin; 1/4 of // what used to be here double factor = 3.28 / 16; return (int) (l * factor); } In the display tool we use // length should be in units of 16 feet item.addText("length %d (%dm)", len, (int)(len * 16 / 3.25)); I guess it should always be either 3.28 or 3.25? On the other hand, if the length is somehow related to the unit foot, why do I not see something like 0.3048? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/question-regarding-length-tp5779909.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 2

higher precision instead of short-arc-removal?
by GerdP 03 Oct '13

03 Oct '13

Hi programmers, I am still working on the improved short-arc-removal routines. I found a few more special cases, and many of them are related to the fact that we are using the rounded lat/lon values (Garmin map units). Short excurse: A map unit is a 24bit integer value, means we can separate 2^24 = 16777216 different positions on the equator. By the way, the comment in Utils.toMapUnit "A map unit is an integer value that is 1/(2^24) degrees of latitude or longitue" is wrong, we store 1/(2^23) of a value that goes from -180.0 to 180.0. Means ~ 2.39m (40075 km / 16777216) near the equator. In Berlin, the value is ~ 1.45m for lon (lat is of course the same). So, the rounding error is 0.75 to 1.2m in this area. While these errors are not important when it comes to rendering a map, they might be important when it comes to routing. In some cases I find segments of ways with two points that are very close. Imagine a nearly vertical short segment. The rounding might move one point to the left, the other to the right, so that (in map units) with deltaLat = 1 and deltaLon = 1 the calculated bearing of ~ 148 is nonsense, as the real value is e.g 178. If I got this right, the Garmin routing algo uses the bearing value. We store it (heavily rounded to 8 or fewer bits), and the comments in RouteArc.encodeCurve() say that we are not sure about the img format. I think this might also explain why short arcs cause trouble, maybe it is not the short arc itself, maybe we simply write wrong data to the img when we store roads with points that are very close to each other? If that is true, we might better try to find out what we have to write to the img instead of messing around with short arcs? If only precision is the problem: Maybe we can Coord to store the lat/lon values with 30 bits precision? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/higher-precision-instead-of-short-arc-remova… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 5

mergeroads branch
by GerdP 03 Oct '13

03 Oct '13

Hi WanMil, I don't understand the changes in the OSM readers, e.g. // the type tag is required for relations - all other tags are filtered if (elem instanceof Relation == false || "type".equals(key) == false) key = keepTag(key, val); if (key != null) elem.addTag(key, val.intern()); I'd prefer to make sure that "type" is not filtered by keepTag(), because the keepTag method "inlines" the key. What was the reason for that change? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5779967.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 4

highway count not fixed yet... - merge-roads-branch
by Felix Hartmann 03 Oct '13

03 Oct '13

Just cannot find the topic on the merge-roads-branch. Is it known that the highway count error is not fully fixed yet? I still get loads of them.

5 31

Commit: r2724: Make sure that remove-short-arcs with no argument is evaluated with the default value (5.0)
by svn commit 03 Oct '13

03 Oct '13

Version 2724 was committed by gerd on Fri, 27 Sep 2013 Make sure that remove-short-arcs with no argument is evaluated with the default value (5.0)

3 4

Provincial capitals
by Bernhard Hiller 30 Sep '13

30 Sep '13

How can provincial capitals be detected by a style rule? I want to show them at low zoom level, even if their population is rather little. Example: Phangnga town (South Thailand) has a population of some 10,000 people, but it is the capital of Phangnga province (see http://www.openstreetmap.org/browse/node/984029824) There is a relation for the province boundary: http://www.openstreetmap.org/browse/relation/1908799 which has Phangnga set as its admin_centre; admin_level = 4. I tried in the points file: place=* & mkgmap:admin_level4=* & cityxx!=yes {set cityxx=yes} [0x0100 level 6 continue with_actions ] but that does not help: Phangnga city is shown at a high zoom level only, instead of at the same zoom level with Bangkok (ok, that's not useful, I do so temporarily to find out how things work). I tried place=city or place=village instead of place=*, same result. Only place=* & is_capital=province & cityxx!=yes {set cityxx=yes} [0x0100 level 6 continue with_actions ] works as expected. Fortunately, a mapper added the is_capital tag to all Thai province capitals just a few days ago... But I think using the relation is a better option. Only: how can I do that? Tried that with: mkgmap 2724, Java 7 u40 (64bit), Windows 7 (64bit) Thanks for your hints.

1 1

[PATCH v1] Merge road network
by WanMil 29 Sep '13

29 Sep '13

mkgmap has a LineMergeFilter but that does not merge the road network. Attached patch performs a merging in the OSM data just before the road network is created. This has the advantage that the source code for the merging is quite easy. Turn restrictions and through routes are considered. I tested some data in germany and got a reduction of 5% to 12% (number of roads). I did not find any improvements but also no downgrades in routing. But I did not test long distance routing (> 600km). I think the merge results can be improved if the access handling and some other parts are moved from source code to the style files. This makes it easier for the merger to say that two roads have the same attributes and can be merged without problems. But that's a task for the future... I have already uploaded a compiled version: http://files.mkgmap.org.uk/detail/148 For anyone who is interested in the code: Please check the tag list (variable flatCompareTags) in the new RoadMerger. This taglist gives all tags that must be equal so that two roads can be merged. Is this list complete? Can I remove some tags from it? Have fun! WanMil

6 14