June 2010 - mkgmap-dev - The mkgmap lists

road-name-pois
by Du Plessis, Bennie 22 Jun '10

22 Jun '10

More info: I now got --road-name-pois to work again, by removing --generate-sea:extend-sea-sectors from my options Does it make sense that --generate-sea:extend-sea-sectors could influence --road-name-pois? What else can I do to try and narrow down to the origin of the problem. Maybe I can work around it, or live without a sea, but I'm sure you developers would like to catch this bug. I am aware that road-name-pois will become redundant as address search becomes available for all devices, but until then the users with Nuvi's and mobile XT are very much dependant on road-name-pois. (that's me) (twice) BennieD ##################################################################################### Scanned by MailMarshal - Marshal's comprehensive email content security solution. Download a free evaluation of MailMarshal at www.marshal.com #####################################################################################

1 0

error with overlays stylefile
by aighes 22 Jun '10

22 Jun '10

Hello, I have a problem with overlays style file. I want to show an overlay for raods with cobblestones. In lines file I wrote: highway=primary & surface=cobblestone [0x104 road_class=1 road_speed=1 resolution 16] highway=secondary & surface=cobblestone [0x105 road_class=1 road_speed=1 resolution 18] highway=tertiary & surface=cobblestone [0x106 road_class=1 road_speed=1 resolution 18] highway=unclassified & surface=cobblestone [0x107 road_class=2 road_speed=4 resolution 19] highway=minor & surface=cobblestone [0x107 road_class=2 road_speed=4 resolution 22] highway=residential & surface=cobblestone [0x108 road_class=2 road_speed=4 resolution 20] highway=living_street & surface=cobblestone [0x108 road_class=2 road_speed=4 resolution 22] and in the overlays file: 0x104: 0x04, 0x1A 0x105: 0x05, 0x1A 0x106: 0x06, 0x1A 0x107: 0x07, 0x1A 0x108: 0x08, 0x1A On 0x1A is the symbol, which should be show as an overlay and on 0x04 - 0x08 are the symbols of the normal roads. mkgmap throws out the Error: "List of numbers expected" in overlays file. Could someone tell me what I am doig wrong? Greets, aighes -- View this message in context: http://gis.638310.n2.nabble.com/error-with-overlays-stylefile-tp5201811p520… Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 5

[PATCH] better used tags handling in rules
by Elrond 21 Jun '10

21 Jun '10

Hi everybody, I intend to commit this sometime soon (in a week, maybe earlier), so I'm looking for some comments or even testing. Issue: If you have a style A that has a base style B, only the main tags from A are considered. This means, that many rules from B are not used. I haven't tracked down exactly why and where it happens, but I assume, that some code cleans up the osm data straight after/while reading it and removes any "useless" tags. To save memory. Anyway, I found a solution: Update the "usedTags" of the RuleSet after merging in the base-RuleSet. The patch is simple, I think. Elrond

2 1

[PATCH v5] - Code around highway shield crap when sorting labels
by Mark Burton 21 Jun '10

21 Jun '10

v5 - now understands the 0x1b prefix code that introduces a lower case letter (and also is used to prefix a couple of separators (0x1b and 0x1c). I thought great, now I can prefix my road names with ^\ (aka 0x1c) and they won't show up so readily when zoomed out. That worked as expected but, unfortunately, it broke the address search stuff so the bottom line is that you can't use the separators as a prefix (sob). Also, for those of you wondering why the display names and other refs are not showing up in the mapsource address search - it's because the MDR building code only reads the first label for a road and ignores any others. Shame that. I don't think there's a good reason why it couldn't read the other labels, it's just doesn't do that at the moment. BTW - the basic address search on the etrex and Nuvi still sees those alternative road labels. So, those people who are tracking this patch series, please test and if it doesn't bite your arse, I will commit it soonish -------- v4 - found the motorways (and a load of other roads too!) -------- v3 - now works harder to clean up road names for use in MDR file - not sure if this will have a beneficial effect but it could possibly fix the issue recently reported by Felix. Motorways are still not showing up. ------- v2 - remove more duplicate labels that only differ in letter case - remove leading spaces from labels even if they start with a Garmin code. Still something wrong with motorway names because on the UK map, only the M74 appears in the mapsource road names - all other motorways are missing - very odd. ------- This patch codes around the problems introduced by highway shields with regard to the sorted roads: 1 - the sort order should now be much improved 2 - no duplicate symbols (shield version + non-shield version) It also includes a fix to the label reading code so that labels with a highway shield prefix are read in correctly when generating the MDR file. For me, in mapsource, road search for roads with highway shields now works apart from motorways which don't seem to searchable - perhaps that's deliberate on Garmin's part? All feedback appreciated. Mark

9 19

Display problem with Mapsource 6.16.1
by Peter Hendricks 21 Jun '10

21 Jun '10

Hi, Sorry if this has been discussed before, but I did search the list and couldn't find any reference. I'm using maps from OSM, downloaded from here: http://garmin.na1400.info/routable.php Ever since I upgraded Mapsource to the latest I'm getting the screen corrupted when zooming in. Details are currently discussed here: http://forum.openstreetmap.org/viewtopic.php?pid=83694#p83694 I would have thought that the developers would be aware of this problem, but can't find any reference to it. Cheers, Peter.

3 3

Splitter density map - pretty pictures
by Chris Miller 20 Jun '10

20 Jun '10

Something I've been meaning to try for a while now is to dump out the splitter's node density map as an image, just to see what it looks like. Here are the results which looked quite neat so I thought I'd share: http://redyeti.net/OSM/

1 0

What does this error mean?
by dom 18 Jun '10

18 Jun '10

Hi, I'm currently building my maps and for some tiles I get the following error messages. The the english speaking (Schwerwiegend = Severe) Is this a mkgmap bug, or I the osm data corrupt? How can I solve this problem? SCHWERWIEGEND (Polyline): 72240288.osm.gz: Problem writing line (class uk.me.parabola.imgfmt.app.trergn.Polyline) of type 0x15 containing 28 points and starting at http://www.openstreetmap.org/?mlat=74.99963&mlon=-18.87219&zoom=17 SCHWERWIEGEND (Polyline): 72240288.osm.gz: Subdivision shift is 0 and its centre is at http://www.openstreetmap.org/?mlat=74.62738&mlon=-18.14049&zoom=17 SCHWERWIEGEND (Polyline): 72240288.osm.gz: deltaLong = -34100 Thanks Marco

1 0

Warning references bad object ID
by Dermot McNally 14 Jun '10

14 Jun '10

Hi folks, I periodically generate a map of Ireland from the Geofabrik ireland.osm extract. With warnings enabled, I get the following: 2010/06/13 20:39:27 WARNING (MultiPolygonRelation): ireland.osm: Multipolygon http://www.openstreetmap.org/browse/relation/4611686018427389788 contains errors. 2010/06/13 20:39:27 WARNING (MultiPolygonRelation): ireland.osm: Polygon 4611686018427393761(6P)(4611686018427392539[6P]) carries role inner but lies inside an inner polygon. Potentially its role should be outer. Clearly there is no such object ID. Can anybody identify where this is going wrong? Thanks, Dermot -- -------------------------------------- Iren sind menschlich

4 7

[PATCH v1] Worker threads stop too early
by WanMil 13 Jun '10

13 Jun '10

Attached patch fixes a bug introduced with r115. Bug description: Each worker thread stops when it retrieves the last element for one area. This means that only (max-threads-1) areas are really written until the last element. For the other areas some elements are remaining in the working queues. The patch ensures that a worker thread is finished only if there is no more unfinished area. WanMil

2 1

Increasing the performance of whole-planet splits.
by Scott Crosby 12 Jun '10

12 Jun '10

Hello! I would like to submit the first of a set of performance optimizations to the splitter that improve the performance and reduce memory usage. The end result is that a core 2 duo can split the entire planet in 3.5 hours with -Xmx1700m and without using any temporary space. (67 minutes on a 8gb core i7) Everything is up on github. I'm sending the first set of patches now. Perhaps the biggest change is that I've made the splitter accept my binary OSM format. I created a binary OSM format that is 30-50% smaller than the bzipped planet (about 5.3gb without metadata) and 5x-10x faster to parse than the gzipped planet. As that format is substantially smaller than the splitter's cache, and to simplify my patch, I removed the cache before refactoring the splitter. My original announcement is at http://lists.openstreetmap.org/pipermail/dev/2010-April/019370.html Since that post I have fixed the issue of unwanted extra precision. I want your thoughts on the binary format before submitting it. Please have a look and tell me what you think. In this email I am submitting some other optimizations and patches. The performance numbers I quote assume that I was using the binary format; I am unsure what benefit they have on trunk. In IntIntMap, the current offset value for rehashing is way to low, given the dense nature of OSM nodeID values and a sequential insertion order. This problem is most obvious on a whole-planet split. It results in huge numbers of collisions; requiring 30+ probes on average. Note when benchmarking that the collision rate is irregular throughout the planet file; with a --max-nodes=4000000 whole planet split, there's virtually no performance differences on the first 90M nodes, yet by 120M nodes, using a random 31-bit prime number is over 3x faster. My multithread changes reduced the real and user CPU time by 30-50% on a uk extract. Other tests, e.g., a whole planet, show almost no effect. I think this is because a lot of my changes increase the efficiency of code that is parallelized, which paradoxically ends up reducing the relative benefits of parellelization. The single biggest remaining slowdown is that for each point, the splitter sends each Node to each area (represented by an OSMWriter), which writes it in the output file if it is in the bounds of the region (with overlap), or does nothing otherwise. On a whole planet, with 840 areas and 550M nodes, that is over 5 trillion bounds-checks that are not run in parallel. An index that can can map a node to the regions that may contain it could avoid 99% of these checks. Scott

3 10