May 2014 - mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] splitter r386 - version number
by Gerd Petermann 25 May '14

25 May '14

Hi Jeremy, thanks for the feedback. I was not sure if you build from svn source or use the binary in the package or if you build from the source in the package. The 3rd variant doesn't work, if I got that right Steve tries to fix that. Gerd > Date: Fri, 23 May 2014 14:40:33 -0400 > Subject: Re: [mkgmap-dev] splitter r386 - version number > From: ichimonji10(a)gmail.com > To: gpetermann_muenchen(a)hotmail.com > > Gerd, > > I can confirm that the --help and --version options work correctly in > r389. Thank you for fixing this. No worries on the (very short) delay. > > — Jeremy "Ichimonji10" Audet

3 5

subst function and literal dots in regular expressions
by Colin Smale 25 May '14

25 May '14

Hi, I am trying to normalise street names by removing any dots. So far I have been unable to get the subst function to do what I want. The problem seems to be getting the dot to be taken literally in the subst parameters. I have tried: a) set newname='${name|subst:. +=> }' b) set newname='${name|subst:. +=> }' c) set newname='${name|subst:[.] +=> }' All of the above seem to have no effect, i.e. newname ends up the same as name. I am thinking of doing it in two stages: firstly replacing ". " (dot followed by space) with a space, and then replacing any other dots with a space so "A.B. Street" ends up as "A B Street". I could also do it by replacing any dots by spaces and then compressing multiple spaces. But in both cases I need subst to match a literal dot. My current style rules look like this: highway=* & name ~ '.*[.].*' {set newname='${name|subst:. +=> }'} newname=* {echo "dots changed from ${name} to ${newname} (1)"; set name='${newname}'} highway=* & name ~ '.*[.].*' {set newname='${name|subst:[.]=> }'} newname=* {echo "dots changed from ${name} to ${newname} (2)"; set name='${newname}'} Can anyone help please? Colin

2 2

splitter r392
by Gerd Petermann 25 May '14

25 May '14

Hi all, I think this is a big step forward. The split algo is now able to find better splits for both normal input like a single country as well as for europe or planet. See also http://www.mkgmap.org.uk/websvn/listing.php?repname=splitter&rev=390&peg=391 Gerd

1 0

how to replace false tracktype keys in style file?
by Minko 24 May '14

24 May '14

I've noticed there are a lot of tagging mistakes have been made on OSM regarding tracktype={number} instead of tracktype=grade{number} Is there a simple formula (with regedit?) to replace this, like tracktype=1-5 > tracktype=grade(1-5) in the styles? At the moment I ignore those false keys but I would like to use this information instead of deleting it.

2 2

evaluating viewpoint direction
by nwillink 23 May '14

23 May '14

I wonder if anyone has a solution for the following: tourism=viewpoint direction=180-300 I have 9 different types for my viewpoints in my TYP file, each clearly showing the direction of the viewpoint. at present I'm using direction= (North, South, East, West, NE,NW,SW and SE) I presume that if direction tag is not given the viewpoint is 360 degrees. This works fine for most of the viewpoints and the maps now seem to be much clearer to the hiker However, I can't see how I can evaluate direction:[number] -[ number] The problems seems to be the '-' meaning 'between' . It would be great if I could say: if direction => 270 and direction <315 then [ 0xNNNN ] I have to admit it is extremely rare where the user has tagged direction using degrees - only 3 in the UK. -- View this message in context: http://gis.19327.n5.nabble.com/evaluating-viewpoint-direction-tp5807100.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

splitter r386 - version number
by Jeremy Audet 22 May '14

22 May '14

Hi, I maintain the Arch Linux splitter package. [1] The most recent release of splitter, r386, fails to output a version number. To wit: [ichimonji10@hardhack:splitter]$ splitter --version splitter unknown compiled unknown Executing `splitter --help` indicates that the "version" number no longer exists. Is this intentional? The previous release, r381, does not exhibit this behaviour. If it helps, the executable has shrunk down from 2.1 MB to 1.6 MB. Please CC me when replying, as I am not subscribed to the mailing list. (I believe this is necessary?) — Jeremy "Ichimonji10" Audet [1] https://aur.archlinux.org/packages/splitter/

4 8

building not equalling yes
by nwillink 22 May '14

22 May '14

Hi I checked it using echotags and it seems that mkgmap declares 'building' as Boolean. Unfortunately, this means it can't parse building=chapel which is an accepted osm tag. ie I have amenity=place_of_worship & building=chapel [0x2c0b resolution 16] this gets completely ignored. I reckon the same applies to building=garage . Perhaps we should just ignore such tags, including building=roof (!) Any ideas? -- View this message in context: http://gis.19327.n5.nabble.com/building-not-equalling-yes-tp5807020.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 4

logging.properities
by Bernd Weigelt 22 May '14

22 May '14

Hi I'm searching for a good logging.properities file ? In the best case with descriptions or comments, but a ready to use file is good enough Bernd

2 2

errors with marine style
by Michał Rogala 21 May '14

21 May '14

Hi! When compiling map using rules from marine style, I get following errors. I don't think it's a big deal as mkgmap finishes its work properly but you may probably want to take a look at it. best regards Michal Rogala 2014/05/21 21:03:37 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 2264946354 (java.lang.NumberFormatException: empty String) 2014/05/21 21:03:37 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980466 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:37 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980468 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:37 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980477 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:37 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980479 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:37 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980482 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:37 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980484 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:37 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980490 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:37 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980492 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:37 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 1653367564 (java.lang.NumberFormatException: empty String) 2014/05/21 21:03:39 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 2264946354 (java.lang.NumberFormatException: empty String) 2014/05/21 21:03:39 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980466 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:39 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980468 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:39 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980477 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:39 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980479 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:39 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980482 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:39 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980484 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:39 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980490 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:39 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 480980492 (java.lang.NumberFormatException: For input string: "(1.5)s") 2014/05/21 21:03:39 SEVERE (ExtTypeAttributes): 66006009.osm.pbf: OSM id 1653367564 (java.lang.NumberFormatException: empty String) 2014/05/21 21:03:53 SEVERE (ExtTypeAttributes): 66006011.osm.pbf: OSM id 2183575575 (java.lang.NumberFormatException: empty String) 2014/05/21 21:03:54 SEVERE (ExtTypeAttributes): 66006011.osm.pbf: OSM id 2183575575 (java.lang.NumberFormatException: empty String) 2014/05/21 21:04:34 SEVERE (ExtTypeAttributes): 66006030.osm.pbf: OSM id 463475800 (java.lang.NumberFormatException: For input string: "(2") 2014/05/21 21:04:34 SEVERE (ExtTypeAttributes): 66006030.osm.pbf: OSM id 463475800 (java.lang.NumberFormatException: For input string: "(2") 2014/05/21 21:04:35 SEVERE (ExtTypeAttributes): 66006030.osm.pbf: OSM id 463475800 (java.lang.NumberFormatException: For input string: "(2")

2 1

splitter r387
by GerdP 20 May '14

20 May '14

Hi all, right after the merge to trunk I noticed that the split algo is not fully predictable (and it never was). It is possible that a file is split very well with a max-nodes=x and much worser with max-nodes=x-1000 or max-nodes=x+1000 This also means that the new --num-tiles option may not work with e.g. --num-tiles=1000 for Europe. I may also disable the support for polygons in combination with --num-tiles. I think nobody needs this and the calculation time can be extreme. I try to find a better algo, in the meantime you may try to increase or decrease max-nodes a little bit if splitter doesn't find a good split. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r387-tp5806869.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 2