November 2012 - mkgmap-dev - The mkgmap lists

splitter improvements
by UliBaer 14 Nov '12

14 Nov '12

> Hi, > > I want to reproduce the problem, but I don't see a file with 1.9GB at this place: http://140.78.94.22/osm/ > Where am I wrong? > Gerd Just saw, my email program messed up the format, so here once more in better readable form: Hi Gerd, sorry, i forgot to mention: I take the germany+.osm.xz (2.9GB) as input to xz.exe and pipe the output (~35GB) to osmconvert.exe and convert the stdin to germany+.osm.pbf. This file is about the same size around 1.9GB as the extract i made myself. Thanks for testing! Regards, Uli

2 1

Re: [mkgmap-dev] splitter improvements
by UliBär (Gmail) 13 Nov '12

13 Nov '12

> Hi, > > I want to reproduce the problem, but I don't see a file with 1.9GB at this place: http://140.78.94.22/osm/> Where am I wrong? > GerdHi Gerd,sorry, i forgot:I take the germany+.osn.xz as input to xz.exe and pipe the outputto osmconvert.exe and convert the > stdin to germany+.osm.pbf.This file ist about the same size ~1.9 GB as the extract made by myself. Thanks for testing!

1 0

splitter improvements
by GerdP 13 Nov '12

13 Nov '12

Hi all, I've just committed r229. I've fixed all reported errors regarding --keep-complete and found some nice performance improvements for Hennings special case (planet as input, split-file with > 800 tiles, many of them overlapping each other) and some general improvements regarding memory requirements. The larger the input file and the number of tiles, the larger is the improvement, so I assume that Henning will now be able to split planet within 3 hours. A few users wanted to see the generated problem list, so it is now written to the output directory. The program writes the generated candidates. If you always use the same split-file, it might be usefull to reuse the list with the problem-file parm instead of using keep-complete. For a two weeks old germany.osm.pbf I get > 1.800.000 lines (32Mb), so I doubt that someone ones to edit such a file ;-) ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-improvements-tp5735230.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 13

multiple code-pages in a map
by Henning Scholland 13 Nov '12

13 Nov '12

Hi, I have a problem with a map containing different code-pages. A problematic region for me is Middle Asia. There are parts with Chinese names, Cyrillic names, Arabian names, Turkish namesand Hebraic names. I create the map with code-page=1251 (means Cyrillic)and it works for the Cyrillic partquite good. But in all other parts mainly ? are displayed. Do you have any solution beside only use english names? This isn't quite useful, because in the region you wont find English names. Maybe it would be possible to transliterate all names, which couldn't be displayed in the used code-page? Or cuttiles at country-boarders like Garmin did it? Henning

1 0

mkgmap r2372 and --process-destination bug?
by Thorsten Kukuk 13 Nov '12

13 Nov '12

Hi, I tried mkgmap r2372 with --process-destination option today. I made the necessary changes to my style file, but at some time I get the following backtrace: java.lang.IllegalArgumentException: fromIndex(0) > toIndex(-1) at java.util.ArrayList.subListRangeCheck(Unknown Source) at java.util.ArrayList.subList(Unknown Source) at uk.me.parabola.mkgmap.reader.osm.LinkDestinationHook.retrieveWays(LinkDestinationHook.java:69) at uk.me.parabola.mkgmap.reader.osm.LinkDestinationHook.end(LinkDestinationHook.java:207) at uk.me.parabola.mkgmap.reader.osm.OsmReadingHooksChain.end(OsmReadingHooksChain.java:79) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:71) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:144) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:210) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:207) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) That's reproduceable and removing the --process-destination option solves this. Any ideas what's going wrong? Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

2 2

Commit: r2373: Skip one-node-ways in process-destination algorithm to avoid list range exceptions
by svn commit 13 Nov '12

13 Nov '12

Version 2373 was commited by wanmil on 2012-11-13 16:09:22 +0000 (Tue, 13 Nov 2012) Skip one-node-ways in process-destination algorithm to avoid list range exceptions

1 0

problem with russian charset
by Michał Rogala 13 Nov '12

13 Nov '12

Hi! I would like to generate a map of Poland, Germany, Czech Republic and Russia. Charset for Poland, Germany and Czech Republic is CP1250 - for Russia I suppose it's CP1251. The problem is - when I generate a map with CP1250, all russian letters are shown as '?' which is fully understood by me as they aren't part of CP1250 and mkgmap tranforms them into default '?' I would like all those russian characters to be transcoded into their ASCII equivalents, as in --latin1 charset. How can I do this? I suppose I need to create special translation table in resources/chars folder. Latin1 and ASCII folders are already there, but when I create CP1250 directory with sample translation table (copied from ASCII) it doesn't seem to have any effect. Thank you from advance for any help :)

1 0

Commit: r2372: New option --process-destination
by svn commit 11 Nov '12

11 Nov '12

Version 2372 was commited by wanmil on 2012-11-11 16:54:53 +0000 (Sun, 11 Nov 2012) New option --process-destination When using the Garmin Types 0x08 and 0x09 (Ramp) Garmin is evaluating the first way after all the *_link ways to display the destination of the link. But in the OSM data only the _link ways are tagged with destination. When this option is set the destination tags of motorway_link and trunk_link ways are copied to the first non link way so that the Garmin can show the destination. Note: There must be a rule in the lines style file that uses the destination tag to set the display_name tag

1 0

Endless loop with splitter r221
by Thorsten Kukuk 10 Nov '12

10 Nov '12

Hi, looks like I run into an endless loop with splitter r221 when trying to split my own created DACH extract. Anything I could provide to help here? Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

5 25

immediate crash due to library issue??
by Greg Troxel 10 Nov '12

10 Nov '12

I've been running mkgmap fairly regularly for several years. I have a script that runs splitter and then mkgmap, and routinely 'svn up' to the latest (trunk) and 'ant build'. Usually this works fine. Today, I updated to: Path: . URL: http://svn.parabola.me.uk/mkgmap/trunk Repository Root: http://svn.parabola.me.uk/mkgmap Repository UUID: 25d90789-57f7-4ee0-8453-03a3dfeeeb22 Revision: 2371 Node Kind: directory Schedule: normal Last Changed Author: wanmil Last Changed Rev: 2370 Last Changed Date: 2012-11-01 07:07:58 -0400 (Thu, 01 Nov 2012) From a version probably in early October ("svn reflog" doesn't seem to work :-). Running mkgmap, I got: Time started: Sat Nov 10 08:50:17 EST 2012 java.lang.NoSuchMethodError: uk.me.parabola.mkgmap.reader.osm.Tags.get(Ljava/lang/Object;)Ljava/lang/String; at uk.me.parabola.mkgmap.reader.osm.Element.getTag(Element.java:50) at uk.me.parabola.mkgmap.reader.osm.HighwayHooks.onAddNode(HighwayHooks.java:97) at uk.me.parabola.mkgmap.reader.osm.OsmReadingHooksChain.onAddNode(OsmReadingHooksChain.java:64) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinHandler$BinParser.parseDense(OsmBinHandler.java:122) at crosby.binary.BinaryParser.parse(BinaryParser.java:124) at crosby.binary.BinaryParser.handleBlock(BinaryParser.java:68) at crosby.binary.file.FileBlock.process(FileBlock.java:135) at crosby.binary.file.BlockInputStream.process(BlockInputStream.java:34) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:63) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:144) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:210) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:207) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Exiting - if you want to carry on regardless, use the --keep-going option Time finished: Sat Nov 10 08:50:18 EST 2012 Total time taken: 903ms I tried 'ant clean' followed by 'ant build' again, but that didn't help. I looked at https://wiki.openstreetmap.org/wiki/Mkgmap/dev and it references protobuf.jar and osmprotobuf.jar; I suspect the problem may be that I had an old version. I dimly recall a tool 'ivy' that is supposed to deal with getting up-to-date versions, but I can't find any reference to it in the sources or the wiki page. So I wondered if the protobuf versions I had (fall 2010) were old. I removed all files in my working directory that weren't versioned (except for a few text files of notes to myself), and rebuilt. Now it seems ok. So there seems to be a bug in dependency tracking.

1 0