- mkgmap-dev - The mkgmap lists

House numbers supported?
by Hendrik Oesterlin 24 Dec '09

24 Dec '09

Hello, I tried to put some house numbers in OSM in order to be searchable on my Garmin device. See http://www.openstreetmap.org/?lat=-22.275439&lon=166.45965&zoom=18&layers=B… and http://www.openstreetmap.org/?lat=-22.15022&lon=166.48473&zoom=17&layers=B0… for the two test locations. I was unable to find this house numbers on my Nüvi755. (using the 20091216_gmapsupp.zip available at my site http://www.oesterlin.ile.nc/gps/ ) Is this feature supported by mkgmap? Or do I make some mistake somewhere? Thank you for your advice! Kind regards Hendrik Oesterlin New Caledonia ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

4 6

Commit: r1439: not equal filter. This allows you to make a symbol undefined if it is equal to another one.
by svn commit 23 Dec '09

23 Dec '09

Version 1439 was commited by steve on 2009-12-23 18:03:18 +0000 (Wed, 23 Dec 2009) not equal filter. This allows you to make a symbol undefined if it is equal to another one. - Clinton Gladstone

1 0

[PATCH] apply_local action (variable substitution in relation members)
by Marko Mäkelä 23 Dec '09

23 Dec '09

On the Finnish forum, the senior mapper alv pointed out that the left:*, right:* names for boundary=administrative ways are being made obsolete by boundary relations. I agree with him that boundary relations are the better option, especially with regards to localization. mkgmap can replace name with some other tag, such as name:sv for Swedish, but it would be difficult to have it replace a family of left:*, right:* tags with left:*:sv, right:*:sv. So, I tried to define a relations rule that would generate a space-separated list of names for a boundary line. For example, the boundary=administrative line http://www.openstreetmap.org/browse/way/38589207 that belongs to the relations of the city borders Vantaa and Helsinki and to the Helsinki suburban borders Tapulikaupunki and Suutarila should get all these names, "Vantaa/Helsinki/Tapulikaupunki/Suutarila", in some order. What happens is that it will get just one of the names, "Suutarila" in my test run: In the relations file, I had this, trying to append each relation name to the mkgmap:boundary_name attribute of each relation member: (type=boundary | type=multipolygon) & boundary=administrative & name=* { echo '${name}'; apply { set mkgmap:boundary_name='${mkgmap:boundary_name}/${name}' | '${name}'; echo '${mkgmap:boundary_name}' } } The problem is that within apply{}, the variable substitutions on the right-hand-side of the "set" and "add" action always refer to the tags of the relation, not to the relation member. Thus, mkgmap:boundary_name will always be empty, and only one relation name will be copied to it. One possible solution is to have a special form of apply{} where SubAction.performOnSubElements(Relation rel) does not invoke addTagAction.setValueTags(rel). A patch that introduces the action apply_local{} is attached. An alternative solution would be to have a special form of variable substitution that refers to the tags of the element itself. One simple way of implementing that could be to introduce the keywords set_local and add_local and add another boolean parameter to AddTagAction that would imply valueTags == null. Yet another solution would be to have a special syntax of variable substitution that would bypass the valueTags, say, $(var) instead of ${var}: (type=boundary | type=multipolygon) & boundary=administrative & name=* { apply { set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}'; } } Best regards, Marko

5 18

Commit: r1438: Reduce minimum dimension of area that can be split to 10 (was 100).
by svn commit 22 Dec '09

22 Dec '09

Version 1438 was commited by markb on 2009-12-22 21:06:34 +0000 (Tue, 22 Dec 2009) Reduce minimum dimension of area that can be split to 10 (was 100). If an area contains too much stuff, it will be split into 2 as long as the area doesn't become too small. This change reduces the limit so that it tries harder to accommodate the map objects before giving up.

1 0

problem seeing OSM maps on nuvi 255w
by Ben Konrath 22 Dec '09

22 Dec '09

Hi, I'm generating maps for Ontario and Quebec here in Canada and I'm having a problem seeing the OSM maps on my Nuvi 255w. I can see the OSM map name in Tools -> Settings -> Maps -> Map Info but when I enable the OSM map and disable the built in North American map, I still can't see the OSM maps. Here are the commands I'm using to generate the maps: java -Xmx2000m -jar mkgmap.jar --tdb --latin1 \ --region-name=Ontario --region-abbr=ON --country-name=Canada --country-abbr=CAN \ --series-name="OSM Ontario" --add-pois-to-areas --ignore-unnamed-areas --road-name-pois \ --route --remove-short-arcs --drive-on-right --check-roundabouts --family-id=3425 \ --family-name="Open Street Map Canada $FAMILY_DATE" --product-id=1 -c template.args java -Xmx2000m -jar --tdb --latin1 \ --region-name="Quebec" --region-abbr="QC" --country-name="Canada" --country-abbr="CAN" \ --series-name="OSM Quebec" --add-pois-to-areas --ignore-unnamed-areas --road-name-pois \ --route --remove-short-arcs --drive-on-right --check-roundabouts \ --family-name="Open Street Map Canada $FAMILY_DATE" --family-id=3426 --product-id=1 -c template.args java -Xmx2000m -jar mkgmap.jar --tdb --gmapsupp --latin1 \ --country-name=Canada --country-abbr=CAN --add-pois-to-areas --ignore-unnamed-areas \ --road-name-pois --drive-on-right --check-roundabouts --route \ --family-name="Open Street Map Canada $FAMILY_DATE" --description="Ontario and Quebec, Canada" \ --remove-short-arcs ontario/*.img quebec/*.img I added '--draw-priority=30' to all three commands and the resulting map is visible but the roads appear behind the roads from the Garmin North American maps even though they are turned off. I *could* just plug the GPS unit into my computer and delete the Garmin basemaps and North American maps but I thought I'd ask here first before I do that. So, does anybody know what could be wrong? My Nuvi 255w has software version 5.70 and GPS SW Version 3.70b. Thanks, Ben

3 7

frig-roundabouts
by Charlie Ferrero 22 Dec '09

22 Dec '09

Is the --frig-roundabouts option still needed/useful or has its functionality been subsumed into something else now? -- Charlie

2 1

contour map error
by Apollinaris Schoell 22 Dec '09

22 Dec '09

Hi, Got 7 of these errors for US Region_01 (161 tiles). What is the best way to resolve? img file is still created - split into tiles - split contour lines for minor, medium, major into different osm files? - ignore, can't find any obvious problems in the map at this location I use srmt1 hgt 1x1 degree tiles, gdal_contour with 25m contour lines. SEVERE (MapSplitter): Area too small to split at http://www.openstreetmap.org/?lat=43.78618&lon=-113.26460&zoom=17 (reduce the density of points, length of lines, etc.) -- Apollinaris

3 9

IMG from MP
by Markus 22 Dec '09

22 Dec '09

Hello, please can you tell me whether mkgmap can produce IMG's from MP files? Thanks, Markus

3 2

Commit: r1437: Copy boundary relation names to boundary lines.
by svn commit 22 Dec '09

22 Dec '09

Version 1437 was commited by marko on 2009-12-22 10:07:55 +0000 (Tue, 22 Dec 2009) Copy boundary relation names to boundary lines. Implement a $(var_name) variable substitution that always refers to the current map element. ${var_name} usually refers to the current map element, but inside apply{} it refers to the current relation.

1 0

POIs not visible in 3d mode
by maning sambale 21 Dec '09

21 Dec '09

Hi, I saw my garmin map (compiled with mkgmap) loaded on a Nuvi 1310 and notice that POIs are not visible in 3d mode. A while back, I also saw this behaviour in nuvi200. Other users reported that they can see POIs in 3d mode. Is this a confirmed issue with other units? -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

2 3