May 2009 - mkgmap-dev - The mkgmap lists

SRTM Contours
by Stuart Poulton 31 May '09

31 May '09

Hi, Does anyone have experience of using linux + SRTM + mkgmap to do contours for garmin GPS's. After no success previously, I'm about to re-investigate this, and wondered if the group had any pointers ? Cheers Stuart

3 4

Commit: r1050: Improve performance of distance calculations.
by svn commit 30 May '09

30 May '09

Version 1050 was commited by markb on 2009-05-30 10:04:26 +0100 (Sat, 30 May 2009) Improve performance of distance calculations. Moved distance() from MultiPolygonRelation class into Coord class to form the basis of quickDistance(). Original distance() now renamed to slowDistance() and distance() now calls quickDistance(). Added distanceInDegreesSquared() - this can be used for those situations where absolute distance is not required, i.e. for determining a nearest point out of a set of points. Reworked Utils.toDegrees() and Utils.toRadians() to reduce number of divisions at runtime.

3 4

Build an Italian OSM Map on Windows
by Marco Certelli 30 May '09

30 May '09

Hi all. For people interested in building an Italian map (but actually any country is supported) on a Windows Machine (maybe I'm the only one...), well I prepared a script that automates the process of downloading/splitting/building the map. MapSource Install is also supported (.reg) I also prepared and included a personal style suited for car routing. If you want to try it and have errors or suggestions, please let me know. The page for download (in Italian): http://mce66.altervista.org/software.html The direct link to the package: http://mce66.altervista.org/software/IMG-OSM-Country/CreateIMG-beta01.zip Ciao e buon Week End Marco.

2 1

Commit: r1051: Loop splitting code now copes with ways that contain nested loops.
by svn commit 30 May '09

30 May '09

Version 1051 was commited by markb on 2009-05-30 10:04:30 +0100 (Sat, 30 May 2009) Loop splitting code now copes with ways that contain nested loops. Before, having detected a loop and split the way into two, it did not then go on to check whether the first portion contained any more loops. It does now.

3 2

Quick distance and loop split fix committed
by Mark Burton 30 May '09

30 May '09

Hopefully, these patches have been tested enough to show up any gross problems - only received good reports so far. If anyone has any issues, let me know and I will revert/fix as appropriate. Cheers, Mark

1 0

[PATCH v1] - fix splitting of ways when they have loops within loops
by Mark Burton 29 May '09

29 May '09

As predicted, the loop splitting code was under-performing. The attached patch should make it split all of the loops when a way has multiple loops. Before, a loop inside another loop was not being split (but a sequence of loops would have been). Those people who are seeing the new error message about consecutive nodes/bad routing should try this patch and see if those messages go away. Also, check if it breaks anything else. Obviously, it would be good to commit this soon if it works as expected. Thanks, Mark

3 4

R: [mkgmap-dev] Maps not for Cars and sharp-turns, U-Turns
by Marco Certelli 29 May '09

29 May '09

Made some test. during fastest route serching, garmin gives a time penalty to turns. time penalty seems propotional to road speed so I think it just calculates a speed reduction due to turn and then a linear increase of speed up to the road speed. for a steep 15° turn I got 357 second penalty on a motorway (road_speed=6 i.e 108km/h) and 237 second penalty on a primary (road_speed=4 i.e. 72km/h) as the angle widens, the penalty is reduced (at 45° is about 1/3 the above values, at 90° about 1/8) Ciao, Marco. --- Gio 28/5/09, Felix Hartmann <extremecarver(a)googlemail.com> ha scritto: > Da: Felix Hartmann <extremecarver(a)googlemail.com> > Oggetto: [mkgmap-dev] Maps not for Cars and sharp-turns, U-Turns > A: "Development list for mkgmap" <mkgmap-dev(a)lists.mkgmap.org.uk> > Data: Giovedì 28 maggio 2009, 23:17 > After playing around a bit with maps > and getting really confused why on some ways I could not > route along with car/motorcycle setting, even though all > access restrictions were sorted out, I found out that in > case of very low angle of roads meeting, in car/motorcycle > setting huge detours maybe made just to turn around. > > This is quite impractical as the best routing performance > can be achieved with the car/motorcycle setting when writing > the maps in such a way that bicycle use is assumed to be > used as car/motorcycle. Using a bicycle there is no need to > prohibit any kind of u-turn, but I think we can't get this > out of the garmin programming but by changing the data > source. Has anyone any idea how we could sort out this > problem with preprocessing? > > Actually this might be usefull for car/motorcycle uses as > well. It would be better to rely on turn-restrictions than > on the garmin GPS simply deciding that at some place turning > is impossible and making a detour to turn! I don't know the > angle but I think if the meeting angle is lower than > somewhere around 20° this happens. So roads meeting would > need to be changed to meet at bigger angles than 20°. To > really find out the angle upon which Garmin GPS/Mapsource > decide a car can't turn (note avoid U-turn is not activated > of course) would need some test maps however. > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

3 2

[PATCH v7] make maps in parallel
by Mark Burton 29 May '09

29 May '09

Now respects --num-jobs again (broken in last patch). --------- 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

3 8

Commit: r1049: Added --remove-short-arcs option to enable short arc removal.
by svn commit 29 May '09

29 May '09

Version 1049 was commited by markb on 2009-05-29 09:20:10 +0100 (Fri, 29 May 2009) Added --remove-short-arcs option to enable short arc removal. Due to the limited precision of coordinates, very short arcs (say, less than about 3M) can become zero length and that causes routing to fail. This option will remove those short arcs by merging the node at one end of the arc into the node at the other end of the arc. As a side effect, consecutive identical points are removed from ways and ways that end up containing only a single point are deleted. Thanks to Marco Certelli for his help with this.

1 0

Commit: r1048: Fixed to deal with the change in StyledConverter constructor.
by svn commit 28 May '09

28 May '09

Version 1048 was commited by steve on 2009-05-29 00:25:06 +0100 (Fri, 29 May 2009) Fixed to deal with the change in StyledConverter constructor.

1 0