May 2009 - mkgmap-dev - The mkgmap lists

Commit: r1047: I have extracted the SizeFilter from the SmoothingFilter
by svn commit 28 May '09

28 May '09

Version 1047 was commited by steve on 2009-05-29 00:07:28 +0100 (Fri, 29 May 2009) I have extracted the SizeFilter from the SmoothingFilter class. The inssertion in the filter chain is missing. Please use the attached patch to get it working and get the same behaviour as before. - Johann Gail

1 0

Re: [mkgmap-dev] [PATCH v5] - merge nodes to remove evil short arcs
by Marco Certelli 28 May '09

28 May '09

Mark. I compiled Italy right now with the last jar version you sent me (1044 + V5, I guess). GREAT! I've tryied to crash MapSource without any success (so far...): all roads I kew were problematic are now routable without issues. For your info, in Italy about 30/50 arcs seems to be "unroutable" (I'll try to correct them as soon as I have the OSM ID info). What to say more. Well done. As soon as you are confident to commit the patch in the trunk (I guess this is the right way to call what I called the mainstream mkgmap), I'll try the last version. Well, just a question: why if I put a wrong switch (like --delete-short-arcs) mkgmap does not tell me there is an unrecognized switch? I might use a wrong switch without knowing... Ciao, Marco.

3 2

Maps not for Cars and sharp-turns, U-Turns
by Felix Hartmann 28 May '09

28 May '09

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.

1 0

generating custom maps (stylesheet or typ files)
by maning sambale 28 May '09

28 May '09

I want to create additional custom maps aside from the regular standard map from the default stylesheets. What I want are maps for cycling/mtb. But I am a bit confused with two options, 1. creating custom styles by editing the default stylesheet, or 2. creating typ files. Can somebody explain the difference of the two options? Advance thanks! -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

4 8

[PATCH v5] - merge nodes to remove evil short arcs
by Mark Burton 28 May '09

28 May '09

v5 as per Marco's suggestion, it now merges points whose coordinates are equal rather than testing against a distance. misc minor tweaks. ---------- v4 based on r1044 ---------- v3 now requires the --remove-short-arcs option to enable this feature now deletes consecutive identical points ---------- v2 now reports OSM ids of merged/replaced nodes (at the cost of using more memory while the XML is being converted). only does this stuff if route option enabled. ---------- The attached patch is a first stab at a solution for this problem. Please test. It is implemented in an iterative fashion and it should terminate after a few passes. If 10 passes are executed it will give up, please report if you see it doing that. It would be nice if the diagnostics reported the OSM id of the nodes rather than their coordinates but I haven't worked out the best way of achieving that yet. Cheers, Mark

4 5

Commit: r1046: Now cites road's OSM id when griping about consecutive identical points.
by svn commit 28 May '09

28 May '09

Version 1046 was commited by markb on 2009-05-28 17:15:29 +0100 (Thu, 28 May 2009) Now cites road's OSM id when griping about consecutive identical points.

3 2

Commit: r1045: Now uses Way's OSM id as the RoadDef id (makes for better error messages).
by svn commit 28 May '09

28 May '09

Version 1045 was commited by markb on 2009-05-28 17:15:25 +0100 (Thu, 28 May 2009) Now uses Way's OSM id as the RoadDef id (makes for better error messages).

1 0

Commit: r1042: Add error message to report when a way contains consecutive identical nodes.
by svn commit 28 May '09

28 May '09

Version 1042 was commited by markb on 2009-05-27 18:54:04 +0100 (Wed, 27 May 2009) Add error message to report when a way contains consecutive identical nodes.

4 4

[PATCH v4] - merge nodes to remove evil short arcs
by Mark Burton 28 May '09

28 May '09

v4 based on r1044 ---------- v3 now requires the --remove-short-arcs option to enable this feature now deletes consecutive identical points ---------- v2 now reports OSM ids of merged/replaced nodes (at the cost of using more memory while the XML is being converted). only does this stuff if route option enabled. ---------- The attached patch is a first stab at a solution for this problem. Please test. It is implemented in an iterative fashion and it should terminate after a few passes. If 10 passes are executed it will give up, please report if you see it doing that. It would be nice if the diagnostics reported the OSM id of the nodes rather than their coordinates but I haven't worked out the best way of achieving that yet. Cheers, Mark

2 2

R: [mkgmap-dev] [PATCH v4] - merge nodes to remove evil short arcs
by Marco Certelli 28 May '09

28 May '09

Hi Mark, I tested the patch (V2) compiling Italy and I found that some problems are solved but others remain (maybe remain the ones coming form the exactly duplicated nodes, or some other "evil" configuration). But I hope remaining problems will disappear with the pach correctring the utilization of right HASH. Unfortunately I cannot test both patches contemporary since I'd need the .jar of 1044 + evil arc patch...). Anyway just a proposal for a V5: if it is feasible, instead of deleting arcs if lenght<3.5m, it whould be better to delete arcs if ((Utils.toMapUnits(latitude1) == Utils.toMapUnits(latitude2)) && (Utils.toMapUnits(longitude1) == Utils.toMapUnits(longitude2))) You would avoid to delete the arcs which ends will not really collapse in a single Garmin IMG point (you avoid the un-needed deletion of about 75% of arcs with respect to the simpler arc lenght test). Ciao, Marco. --- Gio 28/5/09, Mark Burton <markb(a)ordern.com> ha scritto: > Da: Mark Burton <markb(a)ordern.com> > Oggetto: [mkgmap-dev] [PATCH v4] - merge nodes to remove evil short arcs > A: "Development list for mkgmap" <mkgmap-dev(a)lists.mkgmap.org.uk> > Data: Giovedì 28 maggio 2009, 10:38 > > v4 > > based on r1044 > > ---------- > > v3 > > now requires the --remove-short-arcs option to enable this > feature > > now deletes consecutive identical points > > ---------- > > v2 > > now reports OSM ids of merged/replaced nodes (at the cost > of using more > memory while the XML is being converted). > > only does this stuff if route option enabled. > > ---------- > > The attached patch is a first stab at a solution for this > problem. > > Please test. > > It is implemented in an iterative fashion and it should > terminate after > a few passes. If 10 passes are executed it will give up, > please report > if you see it doing that. > > It would be nice if the diagnostics reported the OSM id of > the nodes > rather than their coordinates but I haven't worked out the > best way of > achieving that yet. > > Cheers, > > Mark > > -----Segue allegato----- > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

2 1