August 2011 - mkgmap-dev - The mkgmap lists

Strange roundabout errors
by Marko Mäkelä 09 Sep '11

09 Sep '11

Hi, I have been getting strange roundabout errors. I do not see anything wrong in the data. Today's run was with mkgmap r2001, because the locator branch merge in r2008 broke the address search on the Edge 705 when not using --index and MapSource. I have seen these with a newer mkgmap as well: 2011/08/18 11:15:12 WARNING (StyledConverter): 63240002.osm.pbf: Roundabout segment 125418517 direction looks wrong (see http://www.openstreetmap.org/?mlat=60.20986&mlon=25.07535&zoom=17) Last time I checked, all roundabout segments were counter-clockwise, which corresponds to drive-on-right. 2011/08/18 11:15:56 WARNING (RouteNode): 63240002.osm.pbf: Incoming roundabout flare road (Hietasaarenkuja, http://www.openstreetmap.org/browse/way/22821480) points in wrong direction? http://www.openstreetmap.org/?mlat=60.15502&mlon=24.92128&zoom=17 This is an outgoing flare road. Only the roundabout that is connected to the road has been tagged as junction=roundabout. (Sometimes I have seen flare roads or other non-roundabout roads incorrectly tagged as roundabouts.) Best regards, Marko

1 2

problems with rendering of long riverbank (multipolygons)
by Minko 07 Sep '11

07 Sep '11

Recently someone noticed flooding on the openmtbmap in Belgium south of Maastricht: http://forum.gps.nl/viewtopic.php?f=109&t=34597&p=277200#p277200 I have noticed related issues with floodings west of Maastricht on Lambertus' maps and on my own Openfietsmap parts of the same Albertcanal are "dry". Main cause seems a very long multipolygon relation of the Albertcanal: http://www.openstreetmap.org/browse/relation/1424029 On places where the tile borders are crossing this multipolygon mkgmap has problems with rendering (because the ends of the multipolgygon are way outside the tiles). Splitting up the multipolygon in smaller parts in osm seems not the way to solve these rendering problems because I think it's a bug in mkgmap that should be solved here instead of on osm. Any ideas?

6 18

Commit: r2020: Cleanup builtin-tag-list to reduce number of tags loaded by sparse styles
by svn commit 30 Aug '11

30 Aug '11

Version 2020 was commited by wanmil on 2011-08-29 20:46:37 +0100 (Mon, 29 Aug 2011) Cleanup builtin-tag-list to reduce number of tags loaded by sparse styles There are three categories of changes: 1. Address tags are now assigned dynamically by the style file. This enhances flexibility to assign the address fields. addr:housename addr:housenumber addr:street phone is_in 2. Remove tags that are used only if the route option is set. These tags are now added dynamically by the new RoutingHook class. access bicycle carpool delivery emergency except exception foot goods hgv motorcar motorcycle psv restriction route taxi toll 3. Remove unused tags: osm:id (only used internally by mkgmap) addr:phone openGeoDB:postal_codes

3 3

[PATCH] Splitter area rounding seems wrong
by Bartosz Fabianowski 30 Aug '11

30 Aug '11

Hi list I am debugging a coastline/sea generation issue and in the process of this, discovered what I believe to be a splitter bug. There is a method in RoundingUtils.java that rounds the boundaries of an area to multiples of Garmin units. The minimum and maximum longitude are both rounded down while the minimum and maximum latitude are both rounded up. The resulting rounded area is therefore shifted relative to the original area and does not necessarily bound all the data. This looks like a bug to me. The attached patch rounds the minimum longitude/latitude down and the maximum longitude/latitude up, making sure that the rounded area always fully contains the original area. - Bartosz

3 4

Mkgmap dropping data: Area too small to split at...
by NopMap 29 Aug '11

29 Aug '11

Hi! I have been trying to build a map of portugal for a while, but it never quite works out. There is no exception, but mkgmap shows a large number of messags like this: Area too small to split at http://www.openstreetmap.org/?mlat=38.59838&mlon=-7.34522&zoom=17 (reduce the density of points, length of lines, etc.) When this happens, the data is dropped, so the map looks rather like patchwork. :-) The reason seems to be a large and highly detailed lake in the area, a multipolygon with 1600+ points. As splitting the map takes only the total number of points into account, the lake should not be a problem, but internally it appears that due to the extensive size of the polygon too much detail always ends up in the same MapArea until the MapSplitter gives up and drops the data. >From what I've seen, this should be a general problem unless the input data is somehow deliberately cut right through the large polygon - but I can't figure out how to calculate the proper place to cut it or how to force a cut there. Can you build a map for the area -8.0, 37.8, -6.7, 38.9 without any "Area too small to split" appearing? bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Mkgmap-dropping-data-Area-too-small-to-spli… Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 15

Further possible removals from builtin-tag-list
by WanMil 29 Aug '11

29 Aug '11

Hi, I want to remove a long list of tags from the builtin-tag-list by different actions. The advantage is that specialised styles that do not need these tags are faster and do consume less memory. == Tags that are no longer used == Tag: osm:id There are only two references in mkgmap source code: HighwayHook sets this tag and StyleConverter that reads this tag. I think this is not an OSM tag but a tag set internally by mkgmap. If so we should rename it to mkgmap:osmid. Any objections? Tag: openGeoDB:postal_codes I haven't found any references in the source code. openGeoDB workout have been removed with locator branch merge. == Tags that can be moved to style handling == I am thinking about moving some static coded rules (e.g. name of a POI street is taken from tag "addr:street") to the style system as it has been done with other location items: mkgmap:street!=* & addr:street=* { set mkgmap:street='${addr:street}' } This has two advantages: 1. Speed improvement for styles that don't use this information. (Marko: this should help you with your need for speed improvements for special styles) 2. More flexiblity: If someone likes to use different tags for a POI street name it is easy to configure that. Possible downside: * Little more memory requirement for styles that use address information The tags to be changed are: addr:street addr:housename addr:housenumber addr:phone (is currently not used in mkgmap) phone is_in == Tags that are used only if --route is set == I am not sure if that's correct. Can someone please confirm that? access bicycle carpool delivery emergency except exception foot goods hgv motorcar motorcycle psv restriction route taxi toll WanMil

3 4

splitter and o5m
by Chris66 29 Aug '11

29 Aug '11

Hi, is the splitter program able to read .o5m files ? Chris

3 9

Commit: r2019: Implement --ignore-builtin-relations.
by svn commit 29 Aug '11

29 Aug '11

Version 2019 was commited by marko on 2011-08-29 08:02:35 +0100 (Mon, 29 Aug 2011) Implement --ignore-builtin-relations.

1 0

[PATCH] --ignore-builtin-relations
by Marko Mäkelä 29 Aug '11

29 Aug '11

There is an option to disable the processing of turn restriction relations (--ignore-turn-restrictions), but no option to disable the processing of multipolygon relations. The attached patch introduces --ignore-builtin-relations, which disables the built-in processing of all relations (currently, type={boundary,multipolygon,restiction}). This patch reduces the processing time of my simple map layers from 2.5 minutes to 2 minutes. OK to commit this? Marko

5 22

Road name depending on the zoom level
by Qingzong TSENG 27 Aug '11

27 Aug '11

Hello all, I am a newbie to mkgmap. I am trying to modify some existing style files to have a better rendering result on my Nuvi 765. What I want to have is to display the small village name at lower zoom level. Therefore, I tried to modify the argument: place=village [0x0b00 resolution 16] However, no matter how I changed the resolution value, there was always some village not displaying at some specific zoom levels. Then I realized it could be probably masked/obscured by some very long road name. I am wondering is there a way to make it show only the road ref. ( ex. D119) at lower zoom level and the road name (ex. Avenue Aristide Briand) at higher zoom ? It is logic that at lower zoom level , we are usually looking for trip itinerary and we need the road ref number for highway, motorway. While at higher zoom level we are looking for address and we need the road/street name. Cheers, Zong

4 3