December 2013 - mkgmap-dev - The mkgmap lists

Commit: r2913: Improve error message if a style file contains a second finalize section
by svn commit 27 Dec '13

27 Dec '13

Version mkgmap-r2913 was committed by wanmil on Fri, 27 Dec 2013 Improve error message if a style file contains a second finalize section

1 0

Re: [mkgmap-dev] A bug?
by Ataro A 26 Dec '13

26 Dec '13

Same error that i've. If mkgmap are'nt able to merge the two finalize section of the derived style and base style this is a BUG. Are needed to modify or the deriving mechanism or finalize one. The deriving by include are not working, but the old method by keyword base-style= into the info file (obsolete?) seems working. Il Giovedì 26 Dicembre 2013 9:41, Gerd Petermann <gpetermann_muenchen(a)hotmail.com> ha scritto: Hi, I tried to reproduce that with r2912. I've created a style ataro (see attachment) and used java -jar dist\mkgmap.jar --style-file=c:\mystyles\ataro --check-styles Result: Time started: Thu Dec 26 09:38:28 CET 2013 Found one style in c:\mystyles\ataro Error in style: Error: (lines:6): Invalid arguments to LT: FUNCTION ($from) and GT (($default>;)) could not open style ataro finished check-styles Time finished: Thu Dec 26 09:38:29 CET 2013 Total time taken: 928ms I think the problem is that your lines file contains two <finalize> sections (the one in default/lines and your own), which is probably not allowed. @WanMil: The error message is very confusing. Is it possible to print a better one? Gerd ________________________________ Date: Tue, 24 Dec 2013 16:20:48 +0000 From: ataromail2000(a)yahoo.it To: mkgmap-dev(a)lists.mkgmap.org.uk Subject: [mkgmap-dev] A bug? If i use default as base style, i've a error. Is a bug or my error? # Base styles include 'lines' from default; <finalize> # Compatibility include file include 'inc/compat_lines' from default; _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

2 1

Address search confused by place=* with name,ref
by Marko Mäkelä 25 Dec '13

25 Dec '13

I had not tested the map on my Garmin Edge 705 for a long time, so I do not know how long ago this got changed. Now I tested with a recent mkgmap trunk. It could be the revision right before the mergeroads branch was merged. After the merge, I got some strange error and no *.img files. In the address search, I have 3 regions to choose from: Finland, Åland islands, or Russian Federation. When I select Finland, I see 3 places at the top of the list: "10 Tykkimäki", "611 Pornainen" and "732 Salla". To see where these come from, I loaded the output of the following to JOSM: osmosis --rb finland.osm.pbf --tf reject-relations --tf reject-ways \ --tf accept-nodes 'place=*' --wx finland-place.osm It turns out that there are a few more place=* nodes with name&ref set, but the rest seem to use Roman numerals or be outside of my map tiles (near the country border). Searching for "X" finds "Xi:xii Kyttälä, FIN", which is ref="XI;XII". Searching for "I" finds a few more suburbs in Tampere. The real issue is that searching for "Tykkimäki" or any prefix for it will not find the "10 Tykkimäki". How could this be fixed (index the entry with both "$ref $name" and "$name")? Could the ref=* of a place be omitted from the address search? I suppose that I would get slightly different results, for ref=* in boundary=administrative relations, if I used something else than --location-autofill=nearest. I think that many boundary=administrative relations would carry the ref= of the municipality or suburb. These ref numbers are really nerdy stuff, you can at most find them on some government forms, never in street signs. Best regards, Marko

3 8

Typo in compat_lines or really correct?
by Thorsten Kukuk 25 Dec '13

25 Dec '13

Hi, is this line in compat_lines really correct? highway=* & mkgmap:label:1!=* & mkgmap:street!=* { add mkgmap:street='${mkgmap:label:1}' } We check that mkgmap:street and mkgmap:label:1 are not set and then assign mkgmap:label:1 to mkgmap:street? Or do I misunderstand this rule? Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

2 1

Commit: r2912: Fix assignment of mkgmap:street in compat_lines --Thorsten Kukuk
by svn commit 25 Dec '13

25 Dec '13

Version mkgmap-r2912 was committed by wanmil on Wed, 25 Dec 2013 Fix assignment of mkgmap:street in compat_lines --Thorsten Kukuk

1 0

Commit: r2911: enhance --check-styles:
by svn commit 24 Dec '13

24 Dec '13

Version mkgmap-r2911 was committed by gerd on Tue, 24 Dec 2013 enhance --check-styles: - don't print routing warning message for ways that are ignored - print warning message for objects that have a max. resolution which is lower than that of the highest configured level, which means they are ignored

1 0

little bug in default style
by Bernd Weigelt 24 Dec '13

24 Dec '13

i got this messages, when i try to build a map with the default style Found it, because i have disabled the overview map in default/options Found one style in /home/bernd/map_build/mystyles/defaultmap_style Warning: routable type 0x01 is used for non-routable line with level 0. This may break routing. Style file lines, line 118 Warning: routable type 0x02 is used for non-routable line with level 0. This may break routing. Style file lines, line 123 Bernd -- amarok2 now playing: artist: Eric Clapton title: County Jail Blues album: Blues

2 1

barrier=gate
by Gerd Petermann 23 Dec '13

23 Dec '13

Hi, the default style points file contains barrier=gate { addaccess no; set mkgmap:road-speed=1; } I think this should be changed to allow pedestrians and bicycles, else this would be treated like a closed door when --link-pois-to-ways is used. Gerd

3 6

Commit: r2910: render barrier=gate with 0x660f
by svn commit 23 Dec '13

23 Dec '13

Version mkgmap-r2910 was committed by gerd on Mon, 23 Dec 2013 render barrier=gate with 0x660f

1 0

Commit: r2908: Merge three tests from the mergeroads branch that got lost in the main merge
by svn commit 23 Dec '13

23 Dec '13

Version mkgmap-r2908 was committed by wanmil on Mon, 23 Dec 2013 Merge three tests from the mergeroads branch that got lost in the main merge

1 0