Re: [mkgmap-dev] [PATCH v2] Precompiled sea
El 04/05/12 19:33, Clinton Gladstone escribió: On May 3, 2012, at 23:55, WanMil wrote: I have already found a few tiles with flooding (e.g. NE of Russia). I have to investigate that. But I will be happy if you find some other things :-) I've also been testing a little bit. So far the results have been pretty good. One point I'm not sure on is how the --precomp-sea option should work together with the other coastline related options. - I assume that the --coastlinefile is now redundant, correct? - What about the various --generate-sea parameters? I currently use the following when compiling: --generate-sea=multipolygon,extend-sea-sectors,close-gaps=1000,floodblocker Are most or all of these parameters now redundant? If you use --precomp-sea you don't need --generate-sea at all, just omit it. That's true. --precomp-sea uses multipolygon processing. The --generate-sea parameters are not used at all if --precomp-sea is set. Also the --coastlinefile is ignored too. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r2275: Allow only flat file structure in boundary zip file to speed up detection of missing boundary files.
Version 2275 was commited by wanmil on 2012-05-06 19:32:32 +0100 (Sun, 06 May 2012) Allow only flat file structure in boundary zip file to speed up detection of missing boundary files. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r2276: Split subparts of lines that exceed the maximum size of a subdivision
Version 2276 was commited by wanmil on 2012-05-06 19:44:28 +0100 (Sun, 06 May 2012) Split subparts of lines that exceed the maximum size of a subdivision If two subsequent points of a line exceed that maximum size of a subdivision some points are added inbetween to fulfill the subdivision rules. --GerdP ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [TeamCity, FAILED] Build mkgmap::trunk build #2276-1225
Build mkgmap::trunk build #2276-1225 failed (tests failed: 1 (1 new), passed: 234). Agent: Iocaste Build results: http://teamcity.mkgmap.org.uk/viewLog.html?buildId=4023buildTypeId=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: TRE size expected:1343 but was:1445 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:60) 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:518) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906) --- Stdout: --- Time started: Sun May 06 19:54:26 BST 2012 Time finished: Sun May 06 19:54:29 BST 2012 Total time taken: 2477ms Changes included (1 change) Change 2276 by wanmil (3 files): Split subparts of lines that exceed the maximum size of a subdivision If two subsequent points of a line exceed that maximum size of a subdivision some points are added inbetween to fulfill the subdivision rules. --GerdP see more information about changed files: http://teamcity.mkgmap.org.uk/viewLog.html?tab=buildChangesDivbuildId=4023buildTypeId=bt2 Configure email notifications: http://teamcity.mkgmap.org.uk/profile.html?init=1tab=userNotifications ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch] Improve boundary splitting
Hi Gerd, I decided not to include your patch. The improvement is done only for the precompilation step. So it affects only a very few people that precompile the boundaries. The patch itself adds another conversion step from Area to Shape format. In my point of view this is the breaking point where the source code will be no longer maintainable. Before adding some special algorithms to improve performance it is necessary to overwork the boundary related classes and give them a clean structure. The current structure is the result of implementing a totally new function of mkgmap and improving and changing it completely for performance reasons (with a great result!). Now once it's working there is the time for some restructuring. Sorry for that! I hope you understand my reasons. WanMil Hi WanMil, attached is a patch that uses an optimized implementation of the Sutherland-Hodgman algorithm http://en.wikipedia.org/wiki/Sutherland-Hodgeman wikipedia which is much faster than the area.intersect. It is only used to create the precompiled boundaries. The improvements depend on the continent, for africa I see 130 secs with r2272 and 84 secs with the patched version. For asia, I see only a small improvement of ~ 10% On my machine, the precompilation of the boundaries is now quite often waiting for the disk. http://gis.19327.n5.nabble.com/file/n5670294/BoundarySplitter.patch BoundarySplitter.patch Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Patch-Improve-boundary-splitting-tp5670294p5670294.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r2277: Adjust TRE size of test
Version 2277 was commited by wanmil on 2012-05-06 20:16:39 +0100 (Sun, 06 May 2012) Adjust TRE size of test Commit 2276 changed the size of the TRE file by using a different subdivision algorithm. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2277: Adjust TRE size of test
Gerd, the SimpleRouteTest checks if the file sizes of the img files are as expected. After commiting the subdivision change the TRE file size changed. I think thats ok, but can you please check that yourself? Thanks! WanMil Version 2277 was commited by wanmil on 2012-05-06 20:16:39 +0100 (Sun, 06 May 2012) Adjust TRE size of test Commit 2276 changed the size of the TRE file by using a different subdivision algorithm. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [TeamCity, SUCCESSFUL] Build mkgmap::trunk build #2277-1226
Build mkgmap::trunk build #2277-1226 successful (tests passed: 235). Agent: Iocaste Build results: http://teamcity.mkgmap.org.uk/viewLog.html?buildId=4024buildTypeId=bt2 Changes included (1 change) Change 2277 by wanmil (1 file): Adjust TRE size of test Commit 2276 changed the size of the TRE file by using a different subdivision algorithm. see more information about changed files: http://teamcity.mkgmap.org.uk/viewLog.html?tab=buildChangesDivbuildId=4024buildTypeId=bt2 Configure email notifications: http://teamcity.mkgmap.org.uk/profile.html?init=1tab=userNotifications ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] latin1 an index creation
Hi Steve, sorry for my late answer. I tried it again. If I use only --code-page= for my maps of Germany, Alps and Great Britain index wont be created. There are some tmp-files remaining. If I use --code-page= --latin1 everything is fine. My maps of Turkey, Scandinavia, BeNeLux, Poland-Czech, Denmark, Middle Asia and Patagonia works fine in both cases. Do you have any explanation for that? Henning Errormessage: Exception in thread main java.lang.ArrayIndexOutOfBoundsException: -63 at uk.me.parabola.imgfmt.app.srt.Sort$SrtCollator$PositionIterator.next(Sort.java:458) at uk.me.parabola.imgfmt.app.srt.Sort$SrtCollator.compareOneStrength(Sort.java:386) at uk.me.parabola.imgfmt.app.srt.Sort$SrtCollator.compare(Sort.java:353) at uk.me.parabola.imgfmt.app.mdr.PrefixIndex.createFromList(PrefixIndex.java:73) at uk.me.parabola.imgfmt.app.mdr.PrefixIndex.createFromList(PrefixIndex.java:99) at uk.me.parabola.imgfmt.app.mdr.Mdr17.addPois(Mdr17.java:100) at uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSections(MDRFile.java:290) at uk.me.parabola.imgfmt.app.mdr.MDRFile.write(MDRFile.java:247) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinishForDevice(MdrBuilder.java:382) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuilder.java:116) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:440) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:114) Am 29.04.2012 19:31, schrieb Steve Ratcliffe: Hi On 24/04/12 10:22, aighes wrote: would it be possible to add a hint in help=options, that --latin1 is needed for generating the index? What is needed that you need the *same* code-page as was used to create the map. It works as far as I can tell even without any latin1 or code-page argument as long as everything is created without a code page. I will add a note in the help about that. Or change the code, that all strings for index-creation were automatically converted to latin1 and strings shown in the map are converted with --code-page. Don't know if this is possible. It shouldn't be too difficult to read the code-page and sort order that the individual tiles use and create the index with the same ones. If I have time I will have a look at doing that. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
