March 2013 - mkgmap-dev - The mkgmap lists

locator rules and transparent maps
by Thorsten Kukuk 01 Apr '13

01 Apr '13

Hi, I tried to create a transparent map (an additinal layer on top of my basemap) containing address informations, but this does not seem to work. If I include the locator rules (means only create mkgmap:* variables), the maps are no longer transparent, independent of what I use for options. If I remove all mkgmap:* assignements, the map is transparent again. Any idea about this? Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

4 5

Patch v3 for overview map
by GerdP 01 Apr '13

01 Apr '13

Hi List, while trying to implement a decoder for data with extended types I found two bugs in the version 2 of the patch: 1) the img format allows (normal) types 0x01 - 0x3f for lines and 0x01-0x7f for polygons, the original code made no destinction 2) the first point of a line or shape was dropped, this caused esp. many lines to be missing in the overview map. overview_v3.patch <http://gis.19327.n5.nabble.com/file/n5755292/overview_v3.patch> The compiled binary is here: http://files.mkgmap.org.uk/download/97/mkgmap.jar Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Patch-v3-for-overview-map-tp5755292.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 5

Commit: r2542: Do not set mkgmap:housenumber during house number processing.
by svn commit 31 Mar '13

31 Mar '13

Version 2542 was committed by wanmil on Sun, 31 Mar 2013 Do not set mkgmap:housenumber during house number processing. This should be performed by the style processing.

1 0

Access class specific turn restrictions
by Marko Mäkelä 31 Mar '13

31 Mar '13

Hi, today I got this warning: 2013/03/15 13:13:11 WARNING (RestrictionRelation): 63240002.osm.pbf: Turn restriction http://www.openstreetmap.org/browse/relation/2818347 (at http://www.openstreetmap.org/?mlat=60.17315&mlon=24.92289&zoom=17) lacks 'restriction' tag (e.g. no_left_turn) The wiki http://wiki.openstreetmap.org/wiki/Relation:restriction says that restriction:bus=no_right_turn is valid markup. It also lists things like restriction:motorcar and restriction:bicycle. Currently, mkgmap only supports the 'except' tag for restrictions. So, I guess that the above might be written as restriction=no_right_turn except=motorcar;bicycle I think that it is cleaner to use restriction:* for explicitly defining the restricted vehicle classes, unless it is restricted for all. (Sometimes buses can go straight while others must turn, on a lane that is primarily reserved for public transport. This one is a sharp turn to a narrow road, probably too sharp for wider vehicles. Or they want to restrict tourist bus traffic in the area.) Best regards, Marko

3 2

Routing errors only with Mapsource and pedestrian mode
by Johannes Formann 31 Mar '13

31 Mar '13

Hello, one of the users from my bicycle map reported to me a strange error: When he selects the pedestrian mode in Mapsource the routing at tile borders goes really bad. A trip line of sight about 250m is routed showing a really long detour https://bugs.launchpad.net/radkarte/+bug/1156733/+attachment/3582062/+files… https://bugs.launchpad.net/radkarte/+bug/1156733/+attachment/3601274/+files… The problem only occurs when MapSource is used (in BaseCamp everything works) and only in pedestrian mode. The type of road seems to make no difference. The submitter noticed, that the streets are drawn "disconnected" at the tile hordes (see second screenshot). Any Ideas? greetings Johannes P.S. The full bug report in german: https://bugs.launchpad.net/radkarte/+bug/1156733

2 2

Some questions regarding rule expressions
by littlehelper 31 Mar '13

31 Mar '13

Hi, I have the following questions regarding the rule expressions: 1. Is the expression key=* also matching with tags created in action blocks of previous rules? Example (nonsense, but representative): highway=residential { add test=yes; } test=* [0x06 resolution 22] <-- not working test~'.*' [0x06 resolution 22] <-- not working test=yes [0x06 resolution 22] <-- working test!=no [0x06 resolution 22] <-- not working highway=* & test=* [0x06 resolution 22] <-- working So, in general, the expression key=* is working for key highway and others keys/tags defined in the input osm file. The expression is also working as expected within the combination of highway=* and test=*, only highways with a tag test=* are matching. But if test=* is the only expression in the rule, the tag which is introduced some rules before seems to be ignored. This happens also if there is only the regex expression, which should work since r2297: Allow a style rule to consist of just a regular expression. Is this considered as expected or is this a bug? If this is correct behaviour, please add a hint to the style-manual. 2. Sometimes i have observed that if the expression key!=value is the only expression in a rule, the rule seems to be ignored by mkgmap (see example above). If i remember correctly, there were some discussions about fixing that behaviour. Is this still relevant/in progress? Please, add any hint to the style-manual. 3. Shouldn't style-manual be updated like discussed in http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/007957.html ? Thank you. Greetings -- View this message in context: http://gis.19327.n5.nabble.com/Some-questions-regarding-rule-expressions-tp… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 3

[PATCH v1] Improve destination handling by splitting ways
by WanMil 31 Mar '13

31 Mar '13

Attached is something to play with over Easter :-) The process-destination option now uses the same splitting algorithm like the process-exits option. An additional mkgmap:dest_hint=true is added to each _link with destination set. Please have a look at the changed lines file how to give appropriate names using the destination tag. The advantage is that also destinations within big motorway junctions are given at the right place. Have fun! WanMil

2 4

Commit: r2541: Documentation: Add description how to preprocess bounds
by svn commit 30 Mar '13

30 Mar '13

Version 2541 was committed by wanmil on Sat, 30 Mar 2013 Documentation: Add description how to preprocess bounds

1 0

Multiple relation names
by Geoff Sherlock 29 Mar '13

29 Mar '13

I’m sure I’ve read on this list that this is possible. For walking maps I would the way name to consist of all possible related names for that way. For instance for the relations named ‘Icknield Way’ and ‘Chiltern Way’, I would like a way that is contained in both relations to be named ‘Icknield Way Chiltern Way’. Currently I am displaying names for relations using the following in the relations style file: type=route { apply { set route_display_name='${name}'; } } Then I changed the names of tracks, bridleways, cycleways and footways in the lines file with: type=route & route_display_name=* { apply { set route_display_name='${route_display_name}' } } (highway=track | highway=bridleway | highway=cycleway | highway=footway) & route_display_name=* {set name='${route_display_name}' continue with_actions} This is working fine except for two points: 1. Where a way shares two relations only one name is shown (presumably the last alphabetically). 2. It seems that when a way is already named the way name is not changed to the name of the relation. So for 1 – is there any way of showing multiple names? And 2 – Why is the name not changed? I would appreciate any help forthcoming. Geoff.

3 12

Strange squares on Garmin GPS device
by Thomas 29 Mar '13

29 Mar '13

Since I have created maps for my Garmin GPS device some days ago something strange happens. The background of the map is loaded with small brownish squares (see attachment) instead of blank/white. I have not changed the style files as well as the TYP file. By the way, the same background drawing happens if no TYP file is used. Was there a change in mkgmap which causes the squares? Does anyone else have this problem? Sincerely, Thomas

5 13