March 2009 - mkgmap-dev - The mkgmap lists

[PATCH] alpha patch for simplifying ways and reducing img size
by Johann Gail 27 May '09

27 May '09

Find attached an patch (usable on R915), which reduces the point density of ways and roads to reduce the filesize of the resulting img file. It does it by using the douglas peucker algorithm. With this algorithm it is possible to set a max error distance and the resulting line will have filtered out all points without any points outside this distance band. For an exact explanation consult wikipedia. I tried it with an error distance of 10m. Higher distances don't gain much more. The saving is in some areas with bad osm data (useless high point density) up to 25%. In general it saves only 5% in file size. Consider this patch as an alpha release, which should only show the possibilities. For the release it will need at least an option at the commandline for setting the error distance. Also I'm not sure, if the StyledConverter.java is the correct file for this patch. I've seen there is some filter infrastructure in the mkgmap project, but I've no idea how to use it.

5 14

Splitting the UK
by Stuart Poulton 17 May '09

17 May '09

Hi All, I currently use the following to download and split the UK from a planet file using osmosis. In order to get routable maps, should I now be using the mkgmap splitter on an extract of the UK from the planet ? Does osmosis allow mkgmap routing across tiles ? Regards Stuart get -O - http://planet.openstreetmap.org/planet-080730.osm.gz| gunzip -c | ../Software/osmosis-0.24/bin/osmosis --rx /dev/stdin enableDateParsing="no" \ --log-progress \ --buffer bufferCapacity=1000 \ --tee 15 \ --bounding-box top="60.855" bottom="58.695" left="-3.505" right="-0.745" \ --bounding-box top="58.705" bottom="55.495" left="-8.005" right="-4.995" \ --bounding-box top="58.705" bottom="55.495" left="-5.005" right="-1.495" \ --bounding-box top="55.505" bottom="52.995" left="-2.005" right="0.405" \ --bounding-box top="55.505" bottom="52.995" left="-5.005" right="-1.995" \ --bounding-box top="55.505" bottom="52.995" left="-8.005" right="-4.995" \ --bounding-box top="55.505" bottom="52.995" left="-10.655" right="-7.995" \ --bounding-box top="53.005" bottom="49.845" left="-8.005" right="-4.995" \ --bounding-box top="53.005" bottom="51.295" left="-10.655" right="-7.995" \ --bounding-box top="53.005" bottom="50.095" left="-5.005" right="-1.995" \ --bounding-box top="53.005" bottom="50.495" left="-2.005" right="-0.495" \ --bounding-box top="53.005" bottom="50.645" left="-0.505" right="1.005" \ --bounding-box top="53.005" bottom="50.895" left="0.995" right="2.005" \ --bounding-box top="50.105" bottom="48.995" left="-2.755" right="-1.995" \ --bounding-box top="52.750" bottom="52.250" left="-2.450" right="-1.250" \ --write-xml file="B-Grid0.osm" \ --write-xml file="B-Grid1.osm" \ --write-xml file="B-Grid2.osm" \ --write-xml file="B-Grid3.osm" \ --write-xml file="B-Grid4.osm" \ --write-xml file="B-Grid5.osm" \ --write-xml file="B-Grid6.osm" \ --write-xml file="B-Grid7.osm" \ --write-xml file="B-Grid8.osm" \ --write-xml file="B-Grid9.osm" \ --write-xml file="B-Grid10.osm" \ --write-xml file="B-Grid11.osm" \ --write-xml file="B-Grid12.osm" \ --write-xml file="B-Grid13.osm" \ --write-xml file="Midland.osm"

3 4

Abbreviated text in mobileXT
by nyem 06 May '09

06 May '09

Hello, I wonder if anyone has tried mkgmap-generated map on Garmin mobileXT (symbian). Text labels (POI and streetnames) are all abbreviated. Burger King appears as B K, but KFC is OK. A spell search on 'Burger' correctly returns 'B K'. Setting all labels as uppercase doesn't work though. I've tried different options (latin1, lower-case in mkgmap and upcase, codepage in osm2mp) but still the same problem. No such problem viewing the map in mapsource. I use osm2mp.pl to generate the mp file and the same mp file works OK when compiled at mapcenter2. Attached are screenshots of mkgmap and mapcenter2 generated maps for comparison. best regards, nyem

5 8

[PATCH] route recalculation sensitivity
by Bernhard Heibler 30 Apr '09

30 Apr '09

Hi, I think I found the required bits. Seams to be the flag at 0x43 in the TRE header. Patch is attached. Seams to work fine in simulation mode on the nuvi 360. Lets see how it works tomorrow morning on the road ... Please let me know if this also works for you guys. Thanks Berni. Index: src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java =================================================================== --- src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java (revision 314) +++ src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java (working copy) @@ -167,8 +167,8 @@ writer.put(getPoiDisplayFlags()); writer.put3(displayPriority); - writer.putInt(0xd0401); - + writer.putInt(0x110301); // Was 0xd0401 before. 31.03.2009 Changed to 0x110301 to increase route recalculation speed + writer.putChar((char) 1); writer.put((byte) 0);

10 25

An Observation
by Paul 06 Apr '09

06 Apr '09

Firstly, thanks for the great work so far. Having been using my 605 for the past few weeks I've noticed something that was first mentioned a few weeks ago by someone else but was in the midst of a flurry of activity so I thought I'd bring it up again as I too have noticed this. When following a route if you go off course you seem to have to travel quite a way off course before the device re-calculates. I don't know whether this is related to Garmin, my 605, mkgmap or something else so thought it worth mentioning. http://openstreetmap.org/?lat=53.50969&lon=-2.31557&zoom=15&layers=B000FTF I was recently following a route on my 605 and travelling down Newhey Road to the A640 where I had to turn right at the A640 and come back to the roundabout. I ignored this route and turned right along Ladyhouse Lane instead. At the end I turned left and approached the roundabout from the opposite direction to the given route. At no point did the device recalculate such that when I arrived at the roundabout I was given the instruction to take the first exit which is obviously wrong. The "Pink Line" showed me that the first exit was not what I wanted and I could see my actual approach was different to the given approach on the live map screen but I would have expected a recalculation before this occurred. Cheers Paul

10 13

Restaurant+hotel not appearing in nuvi
by Carlos Dávila 03 Apr '09

03 Apr '09

Hello I have a node tagged as follows: amenity=restaurant name=some_name tourism=hotel If I search for it in my nuvi, it appears under Food, but not under Accommodation. Shouldn't it appear in both sections? Cheers Carlos

6 11

[PATCH v10] - patch to support road find by name (now thinking about putting this in trunk)
by Mark Burton 03 Apr '09

03 Apr '09

v10 - based on r987. Functionally, should be identical to last version. If no one has any problems with either v9 or this version, I would like to commit this within the next few days. So please speak up if you have any issues with it. ----------- Hi, The attached patch is for the current SVN trunk and it generates the sorted road data that is required by the gps to find roads/intersections by name. As for the number field, I haven't thought yet how that would get its data. Please test this patch and report success/failure. If it doesn't break anything for anyone, I would like to commit it fairly soon as I think that quite a few people will be happy to have street finding added to the trunk. Cheers, Mark

6 13

[PATCH] minor change to motorway exits
by Carlos Dávila 01 Apr '09

01 Apr '09

I've added colon to exits ref to separate from name, because IMHO current format may be a little confusing with some exit names. I'm not developer, just guessing, so check if it's right (works for me) and doesn't break anything. Cheers Carlos Index: resources/styles/default/points =================================================================== --- resources/styles/default/points (revisión: 991) +++ resources/styles/default/points (copia de trabajo) @@ -46,10 +46,10 @@ highway=bus_stop [0x2f08 resolution 21] -highway=motorway_junction { name '${ref} ${name}' | '${ref}' | '${name}' } +highway=motorway_junction { name '${ref}$: ${name}' | '${ref}' | '${name}' } highway=motorway_junction [0x2000 resolution 16] -highway=services { name '${ref} ${name}' | '${ref}' | '${name}' } +highway=services { name '${ref}$: ${name}' | '${ref}' | '${name}' } highway=services [0x210f resolution 16] historic=museum [0x2c02 resolution 20]

2 2

Commit: r991: All relations must be processed through the style rules even
by svn commit 31 Mar '09

31 Mar '09

Version 991 was commited by steve on 2009-03-31 22:33:24 +0100 (Tue, 31 Mar 2009) All relations must be processed through the style rules even if they don't have any other effect. Fix for rules involving relations of type=route etc.

1 0

relation rules in style
by Gleb Smirnoff 31 Mar '09

31 Mar '09

Hello, fellow openstreetmappers! I am trying to implement this rule, when making garmin maps: - if a road doesn't have a name, and is a member of "relation=route,route=road", then let its name be the ref of this route. To start with, I've made the following rule in relations file: type=route & route=road { apply { # tried both variants: the commented out one and the active # set ref='${ref}'; set ref='${route_ref}'; } } And rules in the lines file: highway=trunk { name '^B${ref}' | '${name}' } [0x02 road_class=3 road_speed=5 resolution 8] highway=trunk_link [0x08 road_class=3 road_speed=3 resolution 19] highway=primary { name '^B${ref}' | '${name}' } [0x02 road_class=3 road_speed=4 resolution 10] highway=primary_link [0x08 road_class=3 road_speed=3 resolution 19] highway=secondary { ..... And this doesn't work. Probably relations file is processed after the lines file, so new tag values are applied too late. IMHO processing relations before other style files will allow to create more advanced rules, like above. -- Totus tuus, Glebius. GLEB-RIPE

2 1