Following are the results processing Portugal: Size osmupdate split into o5m split into pbf mkgmap portugal.o5m 713 MB 0:00:36 0:00:38 0:00:46 o5m: 0:01:25 portugal.pbf 410 MB 0:01:02 0:02:09 0:02:20 pbf: 0:01:27 With these figures the only reasonable option for me would be to output pbf from splitter to reduce disk I/O. Time penalty for the other steps is too high for me. Currently my server is working some 12 hours/day updating maps. El 10/11/21 a las 22:59, Felix Hartmann escribió:
O5m is always faster, but needs more disk space. Converting geofabrik osm.pbf to o5m makes sense however (especially if you can write to Ramdisk or slow Harddisk)
On Wed, 10 Nov 2021, 17:38 Carlos Dávila <carlos@alternativaslibres.org <mailto:carlos@alternativaslibres.org>> wrote:
I'm aware of the supposed advantages of pbf, but I did some tests in the past and I found o5m to be quite faster than pbf, but I'll test again.
El 10/11/21 a las 9:43, Gerd Petermann escribió: > Hi Carlos, > > I'll try to debug this. > > BTW: I see you use *.o5m for the tiles (output from splitter). I think this is no longer a good choice, pbf is a lot smaller and almost as fast. Esp. when it comes to the goal of reducing disk I/O (as with --gmapi-minimal) > > Gerd > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Carlos Dávila <carlos@alternativaslibres.org <mailto:carlos@alternativaslibres.org>> > Gesendet: Dienstag, 9. November 2021 22:54 > An: mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > Betreff: Re: [mkgmap-dev] New assertion, now with code-page=632 and Japan tile > > Hi Ticker > > Not sure if relevant, but note in this case assertion occurs while > compiling the tile, not the index. In fact, --index is not included in > the command. > > El 9/11/21 a las 21:55, Ticker Berkin escribió: >> Hi >> >> I think this assertion could be removed from the code. >> >> Looking through the definition of Shift-JIS, I read it as saying the >> second byte shouldn't be zero, so I don't know why this happens. >> >> As with the Chinese code-pages, mkgmap has places where multi-byte >> encodings are not handled correctly in the --index generation and >> unknown meanings of flags to the Garmin software. >> >> Ticker >> >> >> >> On 09/11/2021 19:43, Carlos Dávila wrote: >>> code-page=932, sorry for the typo. >>> >>> El 9/11/21 a las 20:36, Carlos Dávila escribió: >>>> The command below produces an assertion while compiling this tile >>>> <https://files.mkgmap.org.uk/download/526/31191025.o5m <https://files.mkgmap.org.uk/download/526/31191025.o5m>> from Japan. >>>> Process continues with remaining tiles and finishes without "Number >>>> of MapFailedExceptions: 1" as expected. This is with r4813, but I >>>> also tried with an old version of mkgmap with the same result. >>>> >>>> java -Xmx27G -ea -jar mkgmap.jar--code-page=632 31191025.o5m >>>> Mkgmap version 4813 >>>> Time started: Tue Nov 09 20:18:16 CET 2021 >>>> WARNING (global): Setting max-jobs to 8 >>>> Exception in thread "main" java.lang.AssertionError: found trailing >>>> 0 in chars >>>> at >>>> uk.me.parabola.imgfmt.app.labelenc.EncodedText.<init>(EncodedText.java:39) >>>> >>>> at >>>> uk.me.parabola.imgfmt.app.labelenc.AnyCharsetEncoder.encodeText(AnyCharsetEncoder.java:112) >>>> >>>> at >>>> uk.me.parabola.imgfmt.app.lbl.LBLFile.newLabel(LBLFile.java:132) >>>> at >>>> uk.me.parabola.imgfmt.app.lbl.PlacesFile.createPOI(PlacesFile.java:253) >>>> at >>>> uk.me.parabola.imgfmt.app.lbl.LBLFile.createPOI(LBLFile.java:172) >>>> at >>>> uk.me.parabola.mkgmap.build.MapBuilder.processPOIs(MapBuilder.java:670) >>>> at >>>> uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:325) >>>> at >>>> uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:114) >>>> at >>>> uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:62) >>>> at >>>> uk.me.parabola.mkgmap.main.Main.lambda$processFilename$1(Main.java:291) >>>> at >>>> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >>>> at >>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >>>> >>>> at >>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >>>> >>>> at java.base/java.lang.Thread.run(Thread.java:829) >>>> >>>> >>>> _______________________________________________ >>>> mkgmap-dev mailing list >>>> mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> >>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> >>> _______________________________________________ >>> mkgmap-dev mailing list >>> mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> >>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> >> _______________________________________________ >> mkgmap-dev mailing list >> mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> >> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev