August 2009 - mkgmap-dev - The mkgmap lists

Overview map: tiny patch/review series
by Elrond 12 Aug '09

12 Aug '09

Hi developers, Probably many have already noticed, that the overview map (used to contain the polygons for selecting tiles in mapsource) isn't perfect. Often the polygons are much too large, or sometimes too small. They also feel like having a bias (at least for me). I have tried to fix this. And I think I was successful. After a short talk on irc we concluded: Instead of just commiting stuff, I will post patches here on the ML for review. So that people can give comments before I commit them. This is for mainly two reasons: 1) Some thoughts are not too simple, and I want to make sure, everyone understands them and at the same time, that they're right. 2) Some parts change some internals drastically and I feel, I might have overlooked something in this cause. Elrond

7 22

patch (how to submit?)
by Valentijn Sessink 12 Aug '09

12 Aug '09

Hi Steve, hello list, Here's a patch that documents the naming options better. It mainly describes the --family-name option (previously only a TODO). Is this the best way to submit them? (I noticed that a rather trivial patch that I sent to the list, about Splitter reading hex numbers from areas.list, was not checked in so I'm wondering if there's a better way to send patches?) Best regards, Valentijn

1 0

<kein Betreff>
by Jörg Spanke 11 Aug '09

11 Aug '09

Sorry, but I just realized that the attachement where scrubed. external.properties =================== #log4j.lib= /opt/jars/jakarta-log4j-1.2.8/dist/lib #log4j.jars= log4j-1.2.8.jar #To compile GeoTiffDEM.java you'll need Java Advanced Imaging (JAI) #installed, so it is disabled by default in the build.xml. geotiffdem.build=true jai.lib=/usr/share/sun-jai-bin/lib jai.jar.codec=jai_codec.jar jai.jar.core=jai_core.jar jai.jar.mlibwrapper=mlibwrapper_jai.jar build.xml =================================================================== --- build.xml (revision 1129) +++ build.xml (working copy) @@ -46,11 +46,14 @@ You can set it in the external.properties file too. -->  <path id="main"> <pathelement location="${build.classes}" /> + <pathelement location="${jai.lib}/${jai.jar.codec}" /> + <pathelement location="${jai.lib}/${jai.jar.core}" /> + <pathelement location="${jai.lib}/${jai.jar.mlibwrapper}" /> </path> <path id="test"> @@ -72,7 +75,7 @@ <include name="**/*.java" /> <classpath refid="main"/>  - <exclude name="**/reader/dem/optional/*.java"/> + <exclude name="**/reader/dem/optional/*.java" unless="geotiffdem.build"/> </javac> </target> @@ -160,6 +163,8 @@ <include name="styles/**"/> <include name="help/**"/> </jar> + <echo>To compile GeoTiffDEM.java you'll need Java Advanced Imaging (JAI) installed, so it is disabled by default. +You can enable in in the external.properties file.</echo> <copy todir="${dist}/doc" > <fileset dir="doc" includes="*.txt, Credits, mkgmap.1"/> ________________________________________________________________ Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/

1 0

Commit: r1130: Back out change I accidentally introduced.
by svn commit 11 Aug '09

11 Aug '09

Version 1130 was commited by steve on 2009-08-11 23:30:09 +0100 (Tue, 11 Aug 2009) Back out change I accidentally introduced.

1 0

Splitting multipolygons
by Nop 11 Aug '09

11 Aug '09

Hi! I am using an alternate splitter (built into OSM Composer) to prepare tiles for processing with mkgmap. It works rather well, except when it comes to the splitting of polygons involved in multipolygon relations. A possible result of splitting is a large polygon split by a tile boundary into multiple smaller polygons all located in the same tile. These polygons all share the same id. The multipolygon relation is also contained in that tile. Mkgmap (r1067) processes these polygons in a weird way. Sometimes one of them is visible and the others are missing, sometimes the multipolygon relation seems to be inverted with the clearings being shown as wood and the wood missing. What is the expected strategy for splitting a polygon with multipoly relations into several parts within one tile? How does splitter handle this? Has there been some work around this area recently? bye Nop

2 3

[PATCH] reduce highway=service resolution
by Marko Mäkelä 11 Aug '09

11 Aug '09

When the resolution of highway=residential was reduced, highway=service should have been reduced as well. It looks odd to see highway=service but not the highway=residential that they are connected to. Please apply this patch. The resolution of highway=track looks a bit high too, but displaying highway=track at low zoom levels could be useful in sparsely built areas. Marko Index: resources/styles/default/lines =================================================================== --- resources/styles/default/lines (revision 1122) +++ resources/styles/default/lines (working copy) @@ -46,7 +46,7 @@ highway=primary_link [0x08 road_class=3 highway=residential | highway=living_street [0x06 road_class=0 road_speed=2 resolution 23] highway=secondary [0x04 road_class=2 road_speed=3 resolution 20] highway=path {add access = no; add bicycle = yes; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23] -highway=service [0x07 road_class=0 road_speed=1 resolution 22] +highway=service [0x07 road_class=0 road_speed=1 resolution 23] highway=steps {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23] highway=tertiary [0x05 road_class=1 road_speed=3 resolution 20] highway=track [0x0a road_class=0 road_speed=1 resolution 21]

5 6

[PATCH] Style additions for marine navigation markers
by Clinton Gladstone 11 Aug '09

11 Aug '09

Hello (Ahoy?), The attached patch is inspired by the current OSM image of the week: http://wiki.openstreetmap.org/wiki/Image:Seamap.png The patch, which consists of style additions, adds POIs for marine navigation (buoys, lighthouses, etc.), as well as a line type for piers. You can see the results in the attached screen shot. The POIs are incomplete, and are my best estimation for the corresponding Garmin types. Piers are added as "footways" (which may also not necessarily be correct). Despite all the flaws, this may amuse you. ;-) Cheers.

2 2

bugreport for new splitter
by Paul Ortyl 10 Aug '09

10 Aug '09

Hello! I have just testet the latest svn version of splitter (r64) I get the following exception: 12,000,000 ways processed... [GC 926169K->330369K(1422720K), 0.0038790 secs] Writing relations Sun Aug 09 11:11:14 CEST 2009 [GC 837769K->592513K(1423296K), 0.1517410 secs] Exception in thread "main" java.lang.IndexOutOfBoundsException: bitIndex < 0: -2147483627 at java.util.BitSet.set(BitSet.java:262) at uk.me.parabola.splitter.SplitParser.processRelation(SplitParser.java:189) at uk.me.parabola.splitter.SplitParser.startElement(SplitParser.java:96) at uk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java:38) at uk.me.parabola.splitter.Main.writeAreas(Main.java:231) at uk.me.parabola.splitter.Main.split(Main.java:98) at uk.me.parabola.splitter.Main.main(Main.java:78) The splittter was called as follows: java -Xmx3800m -verbose:gc -jar ../splitter.jar --max-areas=100 --max-nodes=300000 ../../europe.osm With todays (uncompressed) Europe extract from geofabrik. I have tried to use java -Xmx3800m -verbose:gc -jar ../splitter.jar --max-areas=100 --max-nodes=300000 ../../europe.osm but after "Writing relations" the CPU was at 100% for an hour without reporting anything on the console nor writing any data to disk. I was waiting for a few months for updating my maps on the etrex... I thought already, now it will be possible again... Thanks a lot for fixing splitter. It seems to be really close! I'll try to report any problems I encounter with new versions ASAP. Paul -- Don't take life too seriously; you will never get out of it alive. -- Elbert Hubbard

8 18

[PATCH v2] - Add support for marine (aka extended) types
by Mark Burton 10 Aug '09

10 Aug '09

v2 Space optimisation - no longer outputs per-subdivision 13-byte record if the map contains no elements that have an extended type. ------------------- Ahoy there shipmates, This patch is a first stab at providing support for the 3-byte extended types that are used on marine maps. Extended types are specified as a 6 digit hex number. The first two digits are always 01. An example type is 0x010200 (point type Buoy). Points, lines and polygons can all be given extended types. The cGPSMapper user manual lists all of the types. Note that routable ways cannot have an extended type. If you try to give a road an extended type, it will converted into a line. At this time, the various extra attributes that can be assigned to the marine entities (depth, colour, light colour/flash, etc.) are not handled but I have made some progress in understanding their encoding so at least some of these could be supported in the future. Obviously, the OSM data would need to be enriched to specify the required attributes. It now works well enough to warrant testing on more map data but I am expecting that there will be problems given the extent of the patch and the nature of what it's doing. Please test if you can and report success/failure/etc. Cheers, Mark

1 0

Suggestions: improvements to mkgmap --style-file= and --list-styles options
by Charlie Ferrero 10 Aug '09

10 Aug '09

1. Currently, if you invoke mkgmap with the --style-file= tag and point to a non-existent style file (or incorrect path), mkgmap continues regardless (and applies the inbuilt default style, afaict). Can I suggest a patch to mkgmap that at least makes it clear that no style file was found in this circumstance? Sadly I lack the programming skills to do this, but hopefully it's a relatively trivial thing to change. 2. Secondly it seems to me that mkgmap has three inbuilt styles (default, noname, test) that you cannot change by editing the files in the resources folder. Viz: as a new user, it confused me that I though was editing the points file in the resources/default folder and invoking mkgmap with --style=default I could not see any effect on the map output. By trial and error I found that only by specifying --style-file=resources/default when invoking mkgmap would my changes to the style file be reflected in the map. This implies to me that the "default" style rules must be inbuilt into mkgmap. Indeed, running java -jar mkgmap.jar --list-styles suggests that there are 3 different inbuilt styles. Because there was nothing to say otherwise, I had assumed that I could just invoke mkgmap with --style=default (having edited the style files in the resources/default folder) and directly affect the output map. It might therefore be less confusing to rename the subfolders in resources (or rename the output of --list-styles). Or best of all, make it clear in the documentation that mkgmap has inbuilt styles that you can see if you use --list-styles, but cannot edit. If you want to create your own style you need to edit the files in the resources folder and then invoke the file with --style-file= instead. Charlie

4 3