- mkgmap-dev - The mkgmap lists

administrative boundaries for Slovakia
by Marek Greško 19 Jul '14

19 Jul '14

Hello, could you, please include following into the inc/address file of the default style. For Slovakia I am almost sure it is correct and for Greece I have high level of belief. Thanks Marek # Slovakia mkgmap:country=SVK & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country=SVK & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=SVK & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } # Greece mkgmap:country=GRE & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country=GRE & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }

2 1

Commit: r3315: Filter some objects that are not buildings.
by svn commit 19 Jul '14

19 Jul '14

Version mkgmap-r3315 was committed by steve on Sat, 19 Jul 2014 Filter some objects that are not buildings. Tourism and graveyards are not building, neither are groyne and reinforced slope. They are removed from the catch all building rule. - Minko

1 0

building catch all
by chris66 19 Jul '14

19 Jul '14

Hi, at the end of polygons we have some catch all rule: (building=* | amenity=*) & area!=no [0x13 resolution 24] tourism=* & area!=no & waterway!=* [0x13 resolution 24] # man_made can be used on areas or lines man_made=* & area!=no & (man_made!=door & man_made!=embankment & man_made!=breakwater & man_made!=cable_line & man_made!=cutline & man_made!=cutting & man_made!=levee & man_made!=trench) [0x13 resolution 24] man_made=* & area=yes [0x13 resolution 24] This causes that following osm elements are mapped to building (0x13): tourism=camp_site (should be mapped to 0x17 or 0x19) amenity=grave_yard (should be mapped to 0x1a) So I think we should have more specific rules here instead a catch-all. Chris

4 8

Address nodes and Style Processing
by Colin Smale 16 Jul '14

16 Jul '14

Hi! Is it possible that pure address nodes (i.e. not POIs with address information) somehow don't go through the style processing with the "points" file? I have been adding a few debug statements and things are not working as I expected... Regards, Colin

2 1

small discovery - polyline priority
by Michał Rogala 16 Jul '14

16 Jul '14

Hello! Maybe this is obvious for some people, but that was problem I was fighting for a long time. On my maps residential roads had higher rendering priority than tertiary roads - and road junctions looked really ugly. Today i discovered that roads with 'border' option in TYP file have higher rendering priority than roads without border :) before: http://imgur.com/GsKdEp9 after: http://imgur.com/QluXX08 best regards Michal Rogala

2 2

Re: [mkgmap-dev] small discovery - polyline priority
by RheinSkipper 16 Jul '14

16 Jul '14

Marine maps do not have TYP files. So they must have another functionality to control polygon draw order. I never found out how it works. E.g. 0x10105 (bridge polygon) is ALWAYS drawn on top. Some extended types for restricted areas have also very high priority. Until now it was difficult to get predictable results for marine charts. Try and error was the only way to go. Von Samsung Mobile gesendet -------- Ursprüngliche Nachricht -------- polygons - and only polygons - have their own draworder block in a TYP file but in the absence of a typ file the same observation might apply.

1 0

Re: [mkgmap-dev] small discovery - polyline priority
by RheinSkipper 16 Jul '14

16 Jul '14

Very interesting. Is this also true for polygons? Von Samsung Mobile gesendet -------- Ursprüngliche Nachricht -------- The latest NT imgs attach at least 4 additional as yet unknown properties to type numbers, one of which might refer to draworder.

2 1

File name format for style include
by Roger Calvert 15 Jul '14

15 Jul '14

What is the format for an absolute file address for the style file 'include' directive under Windows? The form "C:\Users\Roger\Documents\maps\styles\includes\roger_lines" fails, as does "C:/Users/Roger/Documents/maps/styles/includes/roger_lines". I have no problem with relative addresses - "../includes/roger_lines" works as expected. Many thanks, Roger -- ------------------------------------------------------------------------ Roger Calvert http://www.rogercalvert.me.uk ------------------------------------------------------------------------

1 0

mkgmap does not compile with Java 8
by Michael Prinzinger 13 Jul '14

13 Jul '14

Hello, I hope this is not a FAQ, but I couldn't find an answer anywhere. When I am trying to compile mkgmap with java version "1.8.0_05" Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) running on Windows 7 64 Bit, I get the following errors: compile: [javac] Compiling 480 source files to F:\mkgmap\trunk\build\classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.7 [javac] F:\mkgmap\trunk\src\uk\me\parabola\util\MultiHashMap.java:57: error: name clash: remove(K,V) in MultiHashMap and remove(Object,Object) in HashMap have the same erasure, yet neither overrides the other [javac] public V remove(K key, V value ) [javac] ^ [javac] where K,V are type-variables: [javac] K extends Object declared in class MultiHashMap [javac] V extends Object declared in class MultiHashMap [javac] F:\mkgmap\trunk\src\uk\me\parabola\util\MultiIdentityHashMap.java:57: error: name clash: remove(K,V) in MultiIdentityHashMap and remove(Object,Object) in Map have the same erasure, yet neither overrides the other [javac] public V remove(K key, V value ) [javac] ^ [javac] where K,V are type-variables: [javac] K extends Object declared in class MultiIdentityHashMap [javac] V extends Object declared in class MultiIdentityHashMap [javac] Note: F:\mkgmap\trunk\src\uk\me\parabola\mkgmap\reader\dem\DEM.java uses unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 2 errors [javac] 1 warning BUILD FAILED Is this a known problem? What can I do besides reverting to Java 7? Thank you, Michael

3 3

mkgmap does not compile with Java 8
by Paulo Carvalho 12 Jul '14

12 Jul '14

Michael, The error message suggests you to compile with the -source 1.7 option. With this option you tell the compiler to treat mkgmap's code with Java 7 specs. You don't need to downgrade your JDK intallation nor wait for mkgmap to upgrade. If you're using an IDE, then you have to check its docs on how to set your project source config to 1.7. cheers, Paulo 2014-07-12 8:00 GMT-03:00 <mkgmap-dev-request(a)lists.mkgmap.org.uk>: > Send mkgmap-dev mailing list submissions to > mkgmap-dev(a)lists.mkgmap.org.uk > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > or, via email, send a message with subject or body 'help' to > mkgmap-dev-request(a)lists.mkgmap.org.uk > > You can reach the person managing the list at > mkgmap-dev-owner(a)lists.mkgmap.org.uk > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mkgmap-dev digest..." > > Today's Topics: > > 1. mkgmap does not compile with Java 8 (Michael Prinzinger) > > > ---------- Mensagem encaminhada ---------- > From: Michael Prinzinger <email(a)mipri.de> > To: mkgmap-dev(a)lists.mkgmap.org.uk > Cc: > Date: Fri, 11 Jul 2014 15:48:37 +0200 > Subject: [mkgmap-dev] mkgmap does not compile with Java 8 > > Hello, > > I hope this is not a FAQ, but I couldn't find an answer anywhere. > > When I am trying to compile mkgmap with > > java version "1.8.0_05" > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) > > running on Windows 7 64 Bit, I get the following errors: > > compile: > [javac] Compiling 480 source files to F:\mkgmap\trunk\build\classes > [javac] warning: [options] bootstrap class path not set in conjunction > with -source 1.7 > [javac] F:\mkgmap\trunk\src\uk\me\parabola\util\MultiHashMap.java:57: > error: name clash: remove(K,V) in MultiHashMap and remove(Object,Object) in > HashMap have the same erasure, yet neither overrides the other > [javac] public V remove(K key, V value ) > [javac] ^ > [javac] where K,V are type-variables: > [javac] K extends Object declared in class MultiHashMap > [javac] V extends Object declared in class MultiHashMap > [javac] F:\mkgmap\trunk\src\uk\me\parabola\util\MultiIdentityHashMap.java:57: > error: name clash: remove(K,V) in MultiIdentityHashMap and > remove(Object,Object) in Map have the same erasure, yet neither overrides > the other > [javac] public V remove(K key, V value ) > [javac] ^ > [javac] where K,V are type-variables: > [javac] K extends Object declared in class MultiIdentityHashMap > [javac] V extends Object declared in class MultiIdentityHashMap > [javac] Note: F:\mkgmap\trunk\src\uk\me\parabola\mkgmap\reader\dem\DEM.java > uses unchecked or unsafe operations. > [javac] Note: Recompile with -Xlint:unchecked for details. > [javac] 2 errors > [javac] 1 warning > > BUILD FAILED > > Is this a known problem? What can I do besides reverting to Java 7? > > > Thank you, > > Michael > > > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

1 0