May 2009 - mkgmap-dev - The mkgmap lists

[PATCH v1] support oneway=-1
by Mark Burton 17 May '09

17 May '09

This little patch adds support for oneway=-1. If you have a map that includes such an oddity, please test. Unless I receive any reports of badness, it will be committed in a few days. Cheers, Mark

1 0

[PATCH v5] make maps in parallel
by Mark Burton 16 May '09

16 May '09

Here's a better fix than last night's effort for the problem where the mapname and description for each job were getting clobbered due to the way that the command args are processed. Each job now gets a "snapshot" of the command args so it doesn't matter if they subsequently get changed. --------- Whoops! fixed a bad bug whereby each map was being output to the same file. Not sure if the fix is very elegant but at least it's not being silly any more. Now limits the default value of max-jobs to 4 no matter how many cores you have as further testing shows that having more threads just burns CPU cycles but doesn't actually finish any quicker. I guess the memory system is limiting the performance and the CPUs are spinning waiting for access. Now showing a real speedup of around 240% (my earlier higher claim was based on CPU usage and I now realise that was erroneous, sorry). -------- Now defaults to creating a thread per core so without doing anything you should see a speedup on a SMP box when processing multiple maps. You can use --max-jobs=N to limit the concurrency - you may want to specify that if you can't increase the VM size to what is required. However, it occurs to me that if you can afford a box with more than 2 cores, then you can probably afford a reasonable amount of memory (otherwise, what's the point in having more cores?) Added help blurb. -------- OK, let it not be said that I don't listen to others! The attached patch provides support for making maps in parallel. By default, the behaviour is the same as before but if you specify --num-threads=N where N is greater than 1, it will process N maps at the same time and then combine the results (if required). Don't forget to increase the heap size appropriately. A quick test on the big box shows good speedup - specifying --num-threads=4 and 2GB VM size. I was seeing better than 380% utilisation with 8 cores in use. I suspect the performance limitation here will be VM size and memory system bandwidth. BTW - I don't think num-threads is actually the best name for the option, so please suggest alternatives. Cheers, Mark

2 10

Commit: r1038: Don't share inner ways between all multi-polygon relations.
by svn commit 16 May '09

16 May '09

Version 1038 was commited by markb on 2009-05-16 10:27:36 +0100 (Sat, 16 May 2009) Don't share inner ways between all multi-polygon relations. Removed erroneous static that would have made the inner ways common to all instances of MultiPolygonRelation.

1 0

Commit: r1037: Insert a new point to shorten overly long segments.
by svn commit 16 May '09

16 May '09

Version 1037 was commited by markb on 2009-05-16 09:42:12 +0100 (Sat, 16 May 2009) Insert a new point to shorten overly long segments.

1 0

Commit: r1036: Added Coord makeBetweenPoint(Coord other, double fraction).
by svn commit 16 May '09

16 May '09

Version 1036 was commited by markb on 2009-05-16 09:42:09 +0100 (Sat, 16 May 2009) Added Coord makeBetweenPoint(Coord other, double fraction). This returns a new point that lies on the straight line between the current point and 'other' and its distance from the current point is 'fraction' of the distance to 'other'.

1 0

Cannot find matches in a selected street POI using Nuvi
by maning sambale 15 May '09

15 May '09

Using the --road-name-pois switch I get this report from a Nuvi user: what I have is press "where to"; "address"; "search all"; "enter street name"; then it is able to find and "select street"; pressed selected street name; then search results "no matches found. Normally after selecting the street name, if bring you to the page that states "go" or "show map". -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

1 0

Re: [mkgmap-dev] [PATCH v6] make maps in parallel
by Martin Marinus 14 May '09

14 May '09

Hi Mark, > Now reports exceptions in the worker threads. I'm having the same kind of problems as Clinton (skipped files), so I wanted to do some testing. However, version 6 of your patch seems to ignore my "--max-jobs=1"; it always uses 4 threads (quad-core machine). Any idea? Kind regards, Martin

2 1

[PATCH v1] shorten long segments to avoid bad routing
by Mark Burton 13 May '09

13 May '09

This little patch shortens segments that are longer than the maximum length we can currently handle by adding a new point so that the segment becomes splittable. It should stop the messages that look like this: Way Foo contains a segment that is longer than ... (routing will fail...). So if you were seeing those, please test this patch and report success/failure/etc. If it's good, I will commit it. Cheers, Mark

3 4

[PATCH v6] make maps in parallel
by Mark Burton 13 May '09

13 May '09

Now reports exceptions in the worker threads. --------- Here's a better fix than last night's effort for the problem where the mapname and description for each job were getting clobbered due to the way that the command args are processed. Each job now gets a "snapshot" of the command args so it doesn't matter if they subsequently get changed. --------- Whoops! fixed a bad bug whereby each map was being output to the same file. Not sure if the fix is very elegant but at least it's not being silly any more. Now limits the default value of max-jobs to 4 no matter how many cores you have as further testing shows that having more threads just burns CPU cycles but doesn't actually finish any quicker. I guess the memory system is limiting the performance and the CPUs are spinning waiting for access. Now showing a real speedup of around 240% (my earlier higher claim was based on CPU usage and I now realise that was erroneous, sorry). -------- Now defaults to creating a thread per core so without doing anything you should see a speedup on a SMP box when processing multiple maps. You can use --max-jobs=N to limit the concurrency - you may want to specify that if you can't increase the VM size to what is required. However, it occurs to me that if you can afford a box with more than 2 cores, then you can probably afford a reasonable amount of memory (otherwise, what's the point in having more cores?) Added help blurb. -------- OK, let it not be said that I don't listen to others! The attached patch provides support for making maps in parallel. By default, the behaviour is the same as before but if you specify --num-threads=N where N is greater than 1, it will process N maps at the same time and then combine the results (if required). Don't forget to increase the heap size appropriately. A quick test on the big box shows good speedup - specifying --num-threads=4 and 2GB VM size. I was seeing better than 380% utilisation with 8 cores in use. I suspect the performance limitation here will be VM size and memory system bandwidth. BTW - I don't think num-threads is actually the best name for the option, so please suggest alternatives. Cheers, Mark

1 0

Routing problem
by Joachim Zobel 12 May '09

12 May '09

Hi. I am using the map from http://openstreetmap.teddynetz.de/latest/de_rout_gmapsupp.img.gz that has been generated by mkgmap war Version 1024 with $JAVA -jar $BASE/$MKGMAP --family-id=42 --style-file=$BASE/teddy --road-name-pois --add-pois-to-areas --location-autofill=2 --country-name=Deutschland --country-abbr=DE --gmapsupp --latin1 --net --route $BASE/rout/*.osm.gz $BASE/teddy.TYP I find that the routing for pedestrians gets very crappy on longer distances (> 10 km) and tends to use large roads. As an example when cycling from http://www.openstreetmap.org/?lat=50.93348&lon=6.78133&zoom=17&layers=0B00F… to http://www.openstreetmap.org/?lat=50.93348&lon=6.78133&zoom=17&layers=0B00F… is nonsense until I cross this point (the same in both directions): http://www.openstreetmap.org/?lat=50.93348&lon=6.78133&zoom=17&layers=0B00F… After that the route is really good. Any hints on what might be going wrong? Sincerely, Joachim

3 3