November 2011 - mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] [PATCH v5]splitter memory usage
by Michael Prinzing 17 Nov '11

17 Nov '11

On Wed, 16 Nov 2011 22:37:31 +0100, WanMil wrote: >I will merge the branch back to trunk after getting some feedback on the >list that the changes are worthy to merge. The patched splitter is the first version since r161 that is usable on my system (Win XP 32 bit, Java 1.7 , 1.7GB RAM). It is running very fast, with very low memory consumption compared with the unpatched r181 (which is using huge amounts of memory even for processing small areas). Moreover it is possible again to add contour data with node IDs higher than the max node ID from the OSM data which also did not work with r181 (not even with plenty of RAM). So for me there is no doubt that these changes are worthy to be merged to trunk. Thank you again Gerd for doing this. Michael BTW: Would it be possible to let the splitter decide if it uses 'optimize-mem' by default depending on the available heap space (no if there are more than 2GB available, yes with less than 2GB)?

1 0

Re: [mkgmap-dev] [PATCH v5]splitter memory usage
by Michael Prinzing 17 Nov '11

17 Nov '11

On Wed, 16 Nov 2011 22:37:31 +0100, WanMil wrote: >I will merge the branch back to trunk after getting some feedback on the >list that the changes are worthy to merge. The patched splitter is the first version since r161 that is usable on my system (Win XP 32 bit, Java 1.7 , 1.7GB RAM). It is running very fast, with very low memory consumption compared with the unpatched r181 (which is using huge amounts of memory even for processing small areas). Moreover it is possible again to add contour data with node IDs higher than the max node ID from the OSM data which also did not work with r181 (not even with plenty of RAM). So for me there is no doubt that these changes are worthy to be merged to trunk. Thank you again Gerd for doing this. Michael

1 0

Load custom polygons to Garmin GPS using ogr2osm and mkgmap
by Adrien ANDRE 17 Nov '11

17 Nov '11

Hi everybody, i'm trying to load custom polygons to Garmin GPS using ogr2osm and mkgmap. The problem is that i can't see my polygons on the GPS maps. However, everything is OK with a downloaded OSM file. Here is the script i use : python ogr2osm/ogr2osm.py polygons-4326.mif bzip2 -k -f polygons-4326.osm # wget http://download.geofabrik.de/osm/europe/france/guyane.osm.bz2 python pyMkgmapGarmin/pyMkgmapGarmin.py \ polygons-4326.osm.bz2 guyane.osm.bz2 Does anybody know why ? Thanks in advance, Regards Adrien

2 5

Lower speed on highway=construction, disused=yes
by Marko Mäkelä 17 Nov '11

17 Nov '11

This patch should omit highway=proposed from the generated maps, and it should lower the road speed of construction=* and disused=yes. The highway=construction is still translated with a different line style, but other highway=* & (construction=* | disused=yes) will use the line type of the highway=*. This is based on a suggestion by Carlos Dávila. I did not test the routing, because I have not played with road_speed before. Can someone please tell me if this is OK to commit? Marko

1 0

Re: [mkgmap-dev] [PATCH v5]splitter memory usage
by Felix Hartmann 17 Nov '11

17 Nov '11

Well I think you didn't read my last message yet.... I think currently about 6GB of free RAM are needed to have max-area=1024 to be working (assuming max-nodes 900 000). What is the actual maximum? Could one set max-area=1300? (that is about what I think is max on my machine with max-nodes 900 000) As more RAM is available in 1-2 years some people maybe would like to go for max-area 4000 when splitting Europe (creating a map of the whole world doesn't make sense due to Garmin limits anyhow). As it needed 1pass instead of 4, the time improvement was well worthwhile (about 40% faster). I think the max-area default could be set to 512, that should need about as much memory as the old 255, shouldn't it? So it wouldn't break anything due to out of memory errors for people simply updating the splitter. On 17.11.2011 19:29, Gerd Petermann wrote: > Hello Felix, > > thanks for trying. I think the most interesting part of the fix is > that it allows to split very large files with a higher max-area value > when memory is an issue. As long as only one pass is needed, the > benefits are rather small. > BUT if you can split europe in two or three passes instaead of 5 or > more the speed is probably much better. > Anyhow, I am no longer sure about my change reg. the default value for > max-areas. I think the old default 255 was better. > On my linux box with -Xmx3200m I still needed two passes with > max-areas=512 for europe. > > ciao, > Gerd > > > > > > some more speed observations: > > country germany.pbf from Geofabrik > > > > splitter_patched with optimize-mem: 3 min 6 seconds > > splitter_patched without optimize-mem: 3min 2 seconds > > old splitter: 3 min 42 seconds > > > > I am currently running against europe.pbf, will post the results later. > > But it seems that the patched mkgmap is consistently a bit faster. I > > think optimize-mem is better of by default though (most people using > > mkgmap/splitter have powerful computers anyhow). > > I'm interested if the 1024 max areas vs the old 255 and subsequent less > > runs make for a bigger speedup than on small(er) extracts. > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev(a)lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

1 0

mkgmap 2098 (not previous versions): java.lang.NullPointerException
by Felix Hartmann 17 Nov '11

17 Nov '11

When compiling a map with mkgmap 2098 I get the following error (austria.pbf from geofabrik, my style). 2097 still compiles without problems/error messages. Also 2098 is not faster than 2097 for me (actually in 2 out of 3 tries even very slightly (could be measuring error) slower). It seems however that even though this error is thrown, the map is compiled more or less correctly. Here is the full description: java.lang.NullPointerException at uk.me.parabola.imgfmt.app.net.RoadDef.getStartSubdivNumber(RoadDef.java:341) at uk.me.parabola.imgfmt.app.net.NETFile.sortRoads(NETFile.java:140) at uk.me.parabola.imgfmt.app.net.NETFile.writePost(NETFile.java:86) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:206) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:97) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:61) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:217) 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)

2 2

Commit: r2100: Fix null pointer exception when there is no level 0.
by svn commit 17 Nov '11

17 Nov '11

Version 2100 was commited by steve on 2011-11-17 14:44:14 +0000 (Thu, 17 Nov 2011) Fix null pointer exception when there is no level 0.

1 0

Commit: r2098: Prevent the extremely slow running of mkgmap under certain circumstances.
by svn commit 17 Nov '11

17 Nov '11

Version 2098 was commited by steve on 2011-11-16 21:13:53 +0000 (Wed, 16 Nov 2011) Prevent the extremely slow running of mkgmap under certain circumstances. This is a merge of the simpliy-sorted-roads branch. The responisible routine now never takes more than a fraction of a second to run.

2 1

routing improvements?
by Minko 16 Nov '11

16 Nov '11

On http://forum.openstreetmap.org/viewtopic.php?id=13257&p=3 a few suggestions were posted to improve the routing: Maybe Marko can have a look at this to see if this can be added to the default style? * highway=construction Be careful with construction=minor. http://wiki.openstreetmap.org/wiki/Key:construction "Additionally construction=minor can be used for existing highways which will be modified or repaired without being closed. In this case we don't set highway=construction but leave it at its default value. " So you will brake routing. I think that highway=construction | (highway=* & construction=* & construction!=minor & construction!=no) {add access = no; add bicycle = yes; add foot = yes; add mkgmap:dead-end-check = false } [0x16 road_class=0 road_speed=1 resolution 23] will fix it. * motor_vehicle / vehicle One thing I really miss in the default mkgmap style as well as "world" style, which I've added my own style, is the ability to obey the motor_vehicle and vehicle tags when routing. The two lines below is the one I use, you might certainly have a more effective way to get the work done. highway=* & (motor_vehicle=no | motor_vehicle=destination | motor_vehicle=agricultural | motor_vehicle=private) { add motorcar=no } highway=* & (vehicle=no | vehicle=destination | vehicle=agricultural | vehicle=private) { add motorcar=no }

4 10

TYP mkgmap integration
by Steve Ratcliffe 16 Nov '11

16 Nov '11

Hi The TYP compiler is now integrated into mkgmap on the typ branch. You should be able to supply a .txt file on the command line and it will be compiled along with any other files. If the gmapsupp option is given then the compiled TYP will be copied into the gmapsupp as you would expect. Likewise the compiled TYP name will be in the nsis file if that option is given. If family-id, product-id or code-page options are given, then they override the values given in the input .txt file, so that the TYP will work with rest of the map. So it should just work, I'm sure you will let me know if it doesn't... ..Steve

3 7