February 2011 - mkgmap-dev - The mkgmap lists

[PATCH v1] Fix so that all polygons are really closed
by WanMil 28 Feb '11

28 Feb '11

As András Kolesár found out the PolygonSplitter did not close all polygons. There were several more places in the code where polygons were not closed. I am not really sure if that caused any problems in the map but definitely the coding was not clean. The patch fixes the conversion between mkgmap objects (List<Coord>) and Java2D objects (Polygon, Area). Additionally the StyleConverter ensures that lines which are assigned with polygonal garmin types are closed by adding the first coord to its list of points. Please test and inspect the polygons crossing the tile borders in particular. WanMil

5 13

Multipolygon problem
by Charlie Ferrero 28 Feb '11

28 Feb '11

Hello all, I have the following rule in my polygons style: surface=sand [0x1b resolution 20] The problem is the following multipolygon: http://www.openstreetmap.org/browse/relation/1221199 This is a complex multipolygon which, in certain sections, uses the coastline to define the outer. Parts of the coastline (and therefore parts of the multipolygon) have the key/tag pair surface=sand The result is that mkgmap attempts to build a multipolygon for Port Philip Bay and fill it with sand, which is not ideal: http://www.cferrero.net/maps/img/1.png What I can't figure out is how to adjust my polygon style rules to avoid this happening. Or tell mkgmap not to process multipolygons of type natural=bay Neither of the following two variations of the rule makes any difference: surface=sand & natural!=coastline [0x1b resolution 20] surface=sand & type=!multipolygon [0x1b resolution 20] Nor does natural=coastline & surface=sand {delete surface} make any difference whether I put it in the lines file or the polygons file Does anyone have a suggestion on how to fix this? Thanks! -- Charlie

6 16

Commit: r1871: Avoid translating linear man_made=* as polygons. Translate some as lines.
by svn commit 28 Feb '11

28 Feb '11

Version 1871 was commited by marko on 2011-02-28 14:09:11 +0000 (Mon, 28 Feb 2011) Avoid translating linear man_made=* as polygons. Translate some as lines.

3 2

Commit: r1870: Merge the index branch to trunk.
by svn commit 28 Feb '11

28 Feb '11

Version 1870 was commited by steve on 2011-02-28 13:44:14 +0000 (Mon, 28 Feb 2011) Merge the index branch to trunk. The global index is now much improved: - Searching for names with accented characters - Searching works after being downloaded to a device. - Searching for streets with a city specified works..

1 0

tilesplitter java Exception
by Thorsten Kukuk 28 Feb '11

28 Feb '11

Hi, until now I used the following to split the osm.pbf data: osmosis --rb ../../osm-data/$COUNTRY.osm.pbf --wx - | tilesplitter --mapid=$TILEID --max-nodes=900000 --description="$DESC" --cache=tile-cache With r123, this worked fine, but with the precompiled java jar r164 I get the following error: Exception in thread "main" java.lang.NoClassDefFoundError: crosby/binary/file/BlockReaderAdapter Caused by: java.lang.ClassNotFoundException: crosby.binary.file.BlockReaderAdapter at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) Could not find the main class: uk.me.parabola.splitter.Main. Program will exit. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg)

2 4

[TeamCity, SUCCESSFUL] Build mkgmap::trunk build #1866-974
by teamcity＠mkgmap.org.uk 27 Feb '11

27 Feb '11

Build mkgmap::trunk build #1866-974 successful (tests passed: 152). Agent: Iocaste Build results: http://teamcity.mkgmap.org.uk/viewLog.html?buildId=3367&buildTypeId=bt2 Changes included (1 change) ==================================================== Change 1866 by wanmil (1 file): Adapt the expected size of the LBL file which has changed by the last commit see more information about changed files: http://teamcity.mkgmap.org.uk/viewLog.html?tab=buildChangesDiv&buildId=3367… ============================================================================ Configure email notifications: http://teamcity.mkgmap.org.uk/profile.html?init=1&tab=userNotifications

1 0

Commit: r1866: Adapt the expected size of the LBL file which has changed by the last commit
by svn commit 27 Feb '11

27 Feb '11

Version 1866 was commited by wanmil on 2011-02-27 21:37:15 +0000 (Sun, 27 Feb 2011) Adapt the expected size of the LBL file which has changed by the last commit

1 0

splitter error : java.lang.NoClassDefFoundError: crosby/binary/file/BlockReaderAdapter
by frmas 27 Feb '11

27 Feb '11

Hello, Running splitter, now, this is the error I get : Exception in thread "main" java.lang.NoClassDefFoundError: crosby/binary/file/BlockReaderAdapter Caused by: java.lang.ClassNotFoundException: crosby.binary.file.BlockReaderAdapter at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) Could not find the main class: uk.me.parabola.splitter.Main. Program will exit. Last time I ran it (02/21) with the same parameters, it worked like a charm. Francois --

3 5

[Alpha PATCH] Lookup names for sea polygons
by Clinton Gladstone 27 Feb '11

27 Feb '11

The attached patch is a highly alpha version of code which attempts to determine the ocean or sea name of generated sea polygons. - The code uses a web service from geonames.org (see http://www.geonames.org/export/web-services.html#ocean) - The results can sometimes be wildly inaccurate. :-) What you need: 1. To use this, you must first create a free user account at geonames.org, and activate that account for the free web services. (http://www.geonames.org/login) 2. Then you must specify your user name with the "geonames-user" parameter in mkgmap's --generate-sea option. Example: --generate-sea=multipolygon,extend-sea-sectors,close-gaps=1000,floodblocker,geonames-user=<your user name> (Replace "<your user name>" with your geonames.org user name.) 3. For the moment, this only works with multipolygon sea generation, although this can be changed later. How it works: For each sea polygon, the code makes one or more HTTP calls to http://api.geonames.org/oceanJSON and uses the first sea name found. Example HTTP call: http://api.geonames.org/oceanJSON?lat=51.08498811721802&lng=156.70072317123… The code attempts lookups for the following coordinates in the following order. : 1. The center of gravity of the first way in the multipolygon. 2. The first coordinate in the first way in the multipolygon. 3. - 6. The corners of the bounding box. 7. The center of the bounding box. The code uses the first valid name found (and skips the other lookups). The result: If everything works nicely, and you are lucky, you'll get nice named sea polygons. However, in most cases, you'll get semi-accurate results. Often only one sea (multi-)polygon is created per tile. Polygons which cross sea borders will only have the name of the first sea found. For example, in the attached screen shot of the coast of South Africa, you can see that the South Atlantic Ocean extends too far to the East. As such, the results can be considered to be of entertainment value only. :-) I would appreciate your feedback though, especially if you have ideas to improve this.

2 1

[TeamCity, FAILED] Build mkgmap::trunk build #1865-973
by teamcity＠mkgmap.org.uk 27 Feb '11

27 Feb '11

Build mkgmap::trunk build #1865-973 failed (tests failed: 1 (1 new), passed: 151). Agent: Iocaste Build results: http://teamcity.mkgmap.org.uk/viewLog.html?buildId=3366&buildTypeId=bt2 Failed Tests Summary: Newly failed tests (1 test, alphabetically ordered) ================================================================== func.route.SimpleRouteTest.testSize Newly failed tests details (naturally ordered) ================================================================== func.route.SimpleRouteTest.testSize (new) ================= junit.framework.AssertionFailedError: LBL size expected:<27693> but was:<27672> at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.failNotEquals(Assert.java:618) at org.junit.Assert.assertEquals(Assert.java:126) at org.junit.Assert.assertEquals(Assert.java:443) at func.route.SimpleRouteTest.testSize(SimpleRouteTest.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41) at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.ParentRunner.run(ParentRunner.java:220) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:422) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:931) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:785) Changes included (2 changes) ==================================================== Change 1865 by wanmil (1 file): Autoclose lines only if both endpoints are outside the bounding box Change 1864 by wanmil (4 files): Fix polygon splitting Some polygons were not closed any more after splitting them due to an inappropriate usage of the PathIterator class. All conversion stuff mkgmap objects <=> Java2D objects are now placed in the Java2DConverter class. The background polygon is closed now. see more information about changed files: http://teamcity.mkgmap.org.uk/viewLog.html?tab=buildChangesDiv&buildId=3366… ============================================================================ Configure email notifications: http://teamcity.mkgmap.org.uk/profile.html?init=1&tab=userNotifications

1 0