- mkgmap-dev - The mkgmap lists

Latitude/Longitude files
by Roger Calvert 04 Sep '13

04 Sep '13

In the last few days, there have been several downloads of six copies of my latitude/longitude files for OSM (http://www.rogercalvert.me.uk/OSM/LatLong) in quick succession, using the default parameters. As this seems unlikely to be what somebody actually wants, I am wondering if there is a problem with the site causing this to happen. I cannot identify who is concerned, but if anybody affected by this could contact me, we can try to sort it out. Roger -- ------------------------------------------------------------------------ Roger Calvert http://www.rogercalvert.me.uk ------------------------------------------------------------------------

1 0

Commit: r2685: Correct rule for ref handling of e-roads
by svn commit 03 Sep '13

03 Sep '13

Version 2685 was committed by wanmil on Tue, 03 Sep 2013 Correct rule for ref handling of e-roads

1 0

More problems with "include ... from default;"
by Steve Brophy 03 Sep '13

03 Sep '13

I am getting further problems using include ... from default in style files. When compiling around 300 tiles, approx 2-3 fail to build, with mkgmap reporting the following error: Error in style: Error: (points:48): Unrecognised type command 'resolu' Could not open style custom Line 48 in my points file states: include "points" from default; The error is random, in that repeated attempts at building the tiles result in different tiles failing. I have also tried setting --max-jobs=1, but this doesn't fix it. If I copy the default style to the directory containing my custom style, and use the following instead: include "../default/points" ; then it all works as expected. Any ideas? Steve

2 1

Serious mkgmap Bug - set unconnected type not respecting continue command!
by Felix Hartmann 02 Sep '13

02 Sep '13

Well the bug is quite serious and took me about 6 hours to find out why I'm missing roads in my maps. In case you have an "unconnected" type of a road that you set up a rule for, with " set mkgmap:set_unconnected_type=none" and [continue] - all subsequent commands for the object will be lost, if the set:unconnected becomes true. Reproduce: lines file (only this content needed). highway=motorway & bridge=yes {set mkgmap:set_unconnected_type=none} [0x13 road_class=1 road_speed=0 resolution 24 continue] highway=motorway [0x10001 resolution 24 continue] Now in all places that have a bridge, the motorway will be missing. If however the example is changed to the following, the bug is not present (as the unconnected type condition is not true): highway=motorway & bridge=yes {set mkgmap:set_unconnected_type=none} [0x13 road_class=1 road_speed=0 resolution 24 continue] highway=motorway [0x01 road_class=1 road_speed=0 resolution 24 continue] I don't know if there are any other problems related to this bug. However it is really defeating the purpose of set unconnected type right now, if working with overlays for bridges, routes, and many other things! -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

2 4

Commit: r2679: With output-dir does not exist can result in error.
by svn commit 29 Aug '13

29 Aug '13

Version 2679 was committed by steve on Thu, 29 Aug 2013 With output-dir does not exist can result in error. If more than one thread then there is a race between testing the existence of the directory and creating it. Creating it results in an error if it already exists and the original code would fallback to the default directory on seeing this error. The correct logic is to attempt to create the directory and ignore errors (which is what mkdirs() does anyway), then make sure that the directory exists afterwards.

1 0

[PATCH v1] maxspeedkmh style function
by WanMil 29 Aug '13

29 Aug '13

The patch adds a new style function maxspeedkmh() that returns the maxspeed tag in km/h. Don't know if that's useful for anyone but it's also a kind of preparation to move the maxspeed handling from Java source code in StyledConverter to the style files. It might be used later on to set the roadspeed. WanMil

2 2

Strange occurence in Mapsource/Basecamp
by Geoff Sherlock 25 Aug '13

25 Aug '13

This is not a problem with mkgmap, just a curious thing with Mapsource/Basecamp. Recently I decided to increase the symbol size I used for my maps for POI from a base 16x16 to 24x24. After finding a site where I could download all the PNG files for Mapnik style OSM sysmbols from sizes 12x12 to 64x64 I got to work losing a good couple of weekends in the process; converting the PNGs to be used in my TYP file editor, and tidying up the symbols. Once done I was delighted with the results, but then scrolling around the map I found parts of it were no longer being displayed in Mapsource or Basecamp. I tried the map on my Dakota 20 and could not find the same problem there. One common thing with the missing map parts was it always seemed to be where power lines started to come together, I had changed the image for power towers from a 7x7 pixel image (TYP: 0x6417) to a 22x19 pixel image (TYP: 0x640E). Playing with the detail level in Mapsource I found that viewing on Medium detail level; where the power towers were visible, created a hole in the map where nothing in the rectangle was shown. But changing to the Low detail level when the power towers were lost the map was fine again. It does not seem to be the number of POIs either as the centre of St Albans was shown fine with many POIs. Although these were many different POIs not the same. I am at a loss why large POIs (or at least power power ones) are causing these “holes” in the map, but simply changing the power tower level from 1 to 0 in the style file has fixed the problem as far a I have seen. I have attached two JPEGs showing the difference between the two detail level settings when the power tower was still defined at level 1 in the points file. If anyone has any thoughts I would like to hear them. Regards, Geoff

2 1

possible problem if output dir doesn't exist
by GerdP 25 Aug '13

25 Aug '13

Hi programmers, I've just noted for the first time that mkgmap may fail if the output directory doesn't exist and -max-jobs is used. I saw these messages: Output directory not found. Creating directory '.\map_rrk' Output directory not found. Creating directory '.\map_rrk' and one ovm*.img file was not written to the output dir. I don't expect this to happen often, but I guess this has to be fixed with a threadlocal variable? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/possible-problem-if-output-dir-doesn-t-exist… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 2

Phone number normalisation with style functions
by Colin Smale 24 Aug '13

24 Aug '13

Hi, Following a discussion on talk-gb about ways of formatting a phone number I decided to see how far I could get with the current style functions in mkgmap. I was very pleasantly surprised! The recent additions of subst with a regex and the part function have allowed me to get an almost perfect result with the countries I have looked at. I thought I would share my experiences in case others also find it useful. The goal is to normalise all POI phone numbers to international format so starting with a + followed by the country code etc. without any punctuation or extraneous information. I put the following code in "inc/phone" and used the include function to invoke that from "inc/address", instead of the existing two lines which derive mkgmap:phone. ========== start of script # reformat phone numbers # get the number to use phone=* | contact:phone=* | addr:phone=* {set cs:phone='${phone}' | '${contact:phone}' | '${addr:phone}'} # only use the first number if there is a list cs:phone=* {set cs:phone='${cs:phone|part:}'} # country-specific rules cs:phone=* & (mkgmap:country=GBR | mkgmap:country=IMN) {set cs:phone='${cs:phone|subst:(0)=>|subst:^00~>+|subst:[()]~>|subst:^0~>+44|subst:^+440~>+44}'} cs:phone=* & mkgmap:country=LUX {set cs:phone='${cs:phone|subst:^00~>+}'} cs:phone=* & mkgmap:country=IRL {set cs:phone='${cs:phone|subst:^00~>+|subst:[- ()]~>|subst:^0~>+353|subst:^+3530~>+353}'} cs:phone=* & mkgmap:country=NLD {set cs:phone='${cs:phone|subst:^00~>+|subst:[- ()]~>|subst:^0~>+31|subst:^+310~>+31}'} cs:phone=* & mkgmap:country=BEL {set cs:phone='${cs:phone|subst:^00~>+|subst:[- ()]~>|subst:^0~>+32|subst:^+320~>+32}'} cs:phone=* & mkgmap:country=FRA {set cs:phone='${cs:phone|subst:^00~>+|subst:^0~>+33}'} cs:phone=* & mkgmap:country=DEU {set cs:phone='${cs:phone|subst:^00~>+|subst:[- ()]~>|subst:^0~>+49|subst:^+490~>+49}'} # lose all non-digits (except for +) cs:phone=* {set cs:phone='${cs:phone|subst:[^0-9+]~>}'} # wrap up cs:phone=* {echo '(${mkgmap:country}) Phone number ${phone} reformatted to ${cs:phone}' } cs:phone=* {add mkgmap:phone='${cs:phone}'; set phone='${cs:phone}'; delete contact:phone; delete addr:phone;} ========== end of script A couple of things I missed: 1) the ability to do variable substitution within the old/new parameters to subst, e.g. subst:${old}~>${new} 2) the ability to use backreferences to parts of the pattern, e.g. subst:(abc)def~>{1} to delete occurrences of "def" when they are preceded by "abc" If these functions were to exist, many of the country-specific stuff could actually be collapsed into one or two rules, with variables for the country code and the trunk prefix (usually a 0 in Europe). Best regards, Colin

3 2

Enhancement on SubstitutionFilter.java to handle regexp (filter "subst:")
by Enrico Liboni 19 Aug '13

19 Aug '13

I updated the SubstitutionFilter.java class in order to allow regexp on the subst filters by using the operator "~>" to state the first argument is a regexp. The default behavior is maintained if no operator (i.e. remove string) or "=>" is used This is convenient for mass corrections or in case we'll have some tweaks to apply on street address names to facilitate search, for example the style entry below (Carlos!) highway=* & name ~ '[Aa]venida [Dd]e [Ee]l .*' { add streettype:movend='${name|subst:Avenida De El |subst:Avenida De el |subst:Avenida de El |subst:Avenida de el |subst:avenida De El |subst:avenida De el |subst:avenida de El |subst:avenida de el }'} will become highway=* & name ~ '[Aa]venida [Dd]e [Ee]l .*' { add streettype:movedend='${name|subst:[Aa]venida [Dd]e [Ee]l ~>}'} Technically, the change is minimal, it is just checking the filter operator (=> or ~>) and using replaceAll() instead of replace() if "~>" is used. Attached the updated class - I really hope it will be included and be useful! Cheers, Enrico

5 11