- mkgmap-dev - The mkgmap lists

[PATCH v6] - Code around highway shield crap when sorting labels
by Mark Burton 22 Mar '10

22 Mar '10

v6 - don't trash first ref if it is the same as the name (sans shield) and more refs follow --------- 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

2 4

typfile: Drawing order
by Daniela Duerbeck 22 Mar '10

22 Mar '10

Hi! Which drawing order are you using for woods and lakes? I found a situation: http://www.openstreetmap.org/?lat=47.9066&lon=11.5221&zoom=14&layers=B000FTF where a lake is inside a wood and with drawing order 5 for both I just see the wood. TIA, Dani

3 3

process same input data with mkgmap with different styles at the same time
by Christoph Wagner 22 Mar '10

22 Mar '10

Hello list, I try to make Garmin maps with different layers. http://wiki.openstreetmap.org/wiki/All_in_one_Garmin_Map The idea is, that you can enable or disable some transparent maps that you won't see. For this reason I use mkgmap with different options and stylefiles multiple times on the same input data: java -ea -jar mkgmap.jar [options1] --style-file=style1 input_data java -ea -jar mkgmap.jar [options2] --style-file=style2 input_data java -ea -jar mkgmap.jar [options3] --style-file=style3 input_data ... This works good, but is not with so good performance as it could be. The input data are gzipped osm-tiles of europe and everytime mkgmap runs it has to decompress and parse the same stuff. The cleverst solution I could imagine is to start mkgmap once and give it different options at the same time for different threads for example: java -ea -jar mkgmap.jar [options1] --style-file=style1 --outputdir=dir1 [options2] --style-file=style2 --outputdir=dir2 [options3] --style-file=style3 --outputdir=dir3 input_data The question is: How difficult is it to implement in mkgmap? I looked at the source code but didn't understand enough to implement it. In germany we would say I looked at the code like a pig at a clockwork. ;) I think a problem is that at the moment the order of commandline args doesn't matter but then it would be important which option belongs to which thread. Maybe another solution could be to build a cache - like the tilesplittercache, where mkgmap can store the parsed input_data. Another mkgmap instance could use this cache instead of the input data. Maybe this solution would be more easy to implement or am I wrong? So something like: java -ea -jar mkgmap.jar [options1] --style-file=style1 --write-cache=cachdir input_data java -ea -jar mkgmap.jar [options2] --style-file=style2 --read-cache=cachdir java -ea -jar mkgmap.jar [options3] --style-file=style3 --read-cache=cachdir What do you think about that ideas? Btw: Can I specify an output directory for mkgmap or is it everytime the actual directory? Thanks! Christoph

2 1

Commit: r1609: Use road_class 3 for route=ferry.
by svn commit 22 Mar '10

22 Mar '10

Version 1609 was commited by marko on 2010-03-22 10:43:13 +0000 (Mon, 22 Mar 2010) Use road_class 3 for route=ferry. Mark Burton says that this is needed for reliable routing.

2 1

Gmapibuilder: Searching for new site to host source code
by Patrick Steiner 22 Mar '10

22 Mar '10

Hi all, is there already a new host for the source code? Or could someone point me to the python file? thanks patrick

2 2

Commit: r1608: Berteun Damman's gmapi-builder script that converts from the MapSource
by svn commit 22 Mar '10

22 Mar '10

Version 1608 was commited by steve on 2010-03-22 09:55:42 +0000 (Mon, 22 Mar 2010) Berteun Damman's gmapi-builder script that converts from the MapSource format to directory structure that is used by RoadTrip on OS X. The original script was also modified by Clinton Gladstone.

1 0

splitter patch for enabling uncompressed tile outputs
by Christoph Wagner 22 Mar '10

22 Mar '10

Hello list, I wanted to test some performance issues with splitter and so I needed to switch of the gzip compression of the output tiles. Based on a patch that Thilo Hannemann wrote in may last year I made a new patch for the latest splitter version now. Please can somebody submit this patch to the splitter svn? Maybe other people need this, too. You can give a commandline switch like splitter.jar --uncompressed or splitter.jar --uncompressed=true to switch of the compression for the output tiles. Default is to compress. Thanks! Christoph

2 1

setting display_name to "name "
by Felix Hartmann 21 Mar '10

21 Mar '10

It seems that dipslay_name internally in mkgmap is not allowed to be set to "name". If identical it will not be set at all. Or is this really a Garmin limitation? To me it seems to be rather an mkgmap bug. If I set: {name '${ref|highway-symbol:hbox:6:4} ${name}' | '${ref|highway-symbol:hbox:6:4}' | '${name}'; set display_name='${ref}_${name}'} Both name and display_name are set correctly. If I change this to: {name '${ref|highway-symbol:hbox:6:4} ${name}' | '${ref|highway-symbol:hbox:6:4}' | '${name}'; set display_name='${ref} ${name}'} then display_name is not set (hence only ref will show up in routing instructions). Also splitting up the command into two lines, and setting dipsplay_name='${name}' after name in a second line it will not be set.

3 13

map detects barriers like gate as passable by motor vehicle when it is only restricted to pedestrians
by maning sambale 21 Mar '10

21 Mar '10

Hi, Just want to share a report from one of the gps map users. In this example, the gate blocks any motor vehicle from going to grasshopper street and spider intersection, and to crispina. This gate is only passable by pedestrian. If the destination is somewhere crispina, the correct route should be through caterpillar avenue and then left on spider street. Here is a sample route with gate as barrier: http://www.openstreetmap.org/?lat=14.44558&lon=120.985888&zoom=18&layers=B0… The calculated route in roadtrip is here: http://farm5.static.flickr.com/4059/4441971869_397ce8bd84_o.jpg I'm inclined to think that this is a data problem (the gate should explicitly define that is only usefule for pedestrians). I can't find the correct tagging for this one at the moment. If such tag exist, is it supported by mkgmap? -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

4 6

More on Address Searching
by Paul 21 Mar '10

21 Mar '10

I know address searching is a work in progress but I thought I'd share the following as it seems wrong to me On my 605 I was using the address search to search for Deansgate in Manchester but couldn't find it. As I knew where it was anyway I navigated to it on screen and hovered the pointer over it at which point I got a tool tip which said "A56 Deansgate". I then used the address search to find "A56 Deansgate" and it was found straight away. Deansgate has the tags highway:primary, name:Deansgate and ref:A56 and and it seems the ref and name are being added together when forming the name in the search list. This seems to be the wrong behaviour to me as I had no idea that Deansgate was part of the A56 and it is known simply as Deansgate Other than a couple of tweaks to the lines file I'm using the default style and was wondering if this behaviour can be changed and if so how Cheers Paul

1 0