November 2009 - mkgmap-dev - The mkgmap lists

[PATCH v1] remove bogus nodes
by Mark Burton 29 Nov '09

29 Nov '09

With the recent reversion of the Table A breakage, it's now useful to post this patch for wider testing as it no longer causes my Nuvi to barf. What it does is remove routing nodes from ways that should never have been put there in the first place. Without this patch, a routable way will have a node for each of its points that are shared by any other way (whether the other ways are routable or not). For example, at the moment, if a way shares its points with a boundary line or shape, each of those points will become nodes. From the routing point of view, that's (essentially) harmless but having extra nodes does take up space and must slow down the routing calculation. It therefore makes sense to remove the bogus nodes. What this patch does is defer the processing of all of the points/lines/shapes until after their types have been computed. Having computed the ways' types we know what's routable and what isn't so nodes only need to be created where routable ways meet. That's the theory, in practice, it produces slightly smaller maps. Whether it actually improves the routing quality is yet to be determined. Obviously, the gain you will see depends on how many bogus nodes are in your maps. All feedback welcome. Mark

3 27

Re: [mkgmap-dev] Simplifying ways
by Johann Gail 28 Nov '09

28 Nov '09

>>> >>> I noticed that some Garmin maps display 1:1 to openstreetmap data, >>> but on route calculation show up to 10% shorter distance. Maybe here >>> only routing nodes are simplifed (straighter line). >> >> Sorry, could you explain in more detail? I'm not sure what you mean >> here. >> 'Simplifiing routing nodes' is the thing, which tries Mark with his >> bogus node patch. > Well I noticed this on a serpentine way in the Swiss Alps. > > I routed over Topo Swiss v2 and distance was 2.3km, then on > Openstreetmap mkgmap created map 2.8km. Though when putting the maps > transparent above each other, there was nearly no difference to tell > in the shape of the ways. From plain eye openstreetmap seemed to be > shorter even. Therefore I assumed that the way it was showing was > longer than the way the routing happened on. Also my bicycle computer > showed 3.1km on the supposedly 2.3km part of the route. > . > Thats interesting. The distance for routing is contained in the routing tables and these are not touched from me in any patch. I really don't know, as I have never looked into it, but here is an assumption: I think the arcs conains the distnace from node to node. Maybe here is the direct line from node to node calculated and not the real length from the winding serpentine.

2 1

[PATCH v3] remove bogus nodes
by Mark Burton 28 Nov '09

28 Nov '09

v3 - now duplicates ways so that any structural changes to the way made while processing a line/road will not affect the original way and so each map object generated from the original way will see the full set of points in the way. Duplicating the ways appeared to have no noticeable effect on the run time when processing the GB map. -------- v2 - avoid assertion when more than one routable way is generated from the same OSM way ------- With the recent reversion of the Table A breakage, it's now useful to post this patch for wider testing as it no longer causes my Nuvi to barf. What it does is remove routing nodes from ways that should never have been put there in the first place. Without this patch, a routable way will have a node for each of its points that are shared by any other way (whether the other ways are routable or not). For example, at the moment, if a way shares its points with a boundary line or shape, each of those points will become nodes. From the routing point of view, that's (essentially) harmless but having extra nodes does take up space and must slow down the routing calculation. It therefore makes sense to remove the bogus nodes. What this patch does is defer the processing of all of the points/lines/shapes until after their types have been computed. Having computed the ways' types we know what's routable and what isn't so nodes only need to be created where routable ways meet. That's the theory, in practice, it produces slightly smaller maps. Whether it actually improves the routing quality is yet to be determined. Obviously, the gain you will see depends on how many bogus nodes are in your maps. All feedback welcome. Mark

2 2

Splitter 103
by Chris Miller 28 Nov '09

28 Nov '09

I've just checked in some further changes to the splitter that some of you may be interested in. It now has support for the <bounds/> tag in OSM files. The splitter will now ensure the resultant split OSM files all fall within the <bounds/> specified in the source file. The advantage is that it means the splitter can be called recursively without growing the tile borders. If for example one of the OSM files generated is too big to process via mkgmap successfully, you can run the splitter on it again with a smaller --max-nodes value to split it further, and all tile boundaries will meet up nicely without overlapping any of the other tiles. Previously that wasn't the case. I've also added a --status-freq parameter that will cause the splitter to periodically output elapsed time and memory status information. This defaults to 120 seconds, you can disable it if you want with --status-freq=0. Enjoy, Chris

2 1

splitter produces invalid xml
by Christoph Wagner 28 Nov '09

28 Nov '09

Hello list, I found a bug in splitter, but don't know how to fix it. The problem is the following: There is a way, that is member of a relation and has special characters in its role-tag. Look here: http://www.openstreetmap.org/browse/way/26683153 The role tag in the osm-data, which I get from the Api is: role='<->' Ok, now I use the splitter and just try to split this file. The role-tag changes: role='<->' and so it's just invalid xml and mkgmap dies with a bad-file-format error. Can anybody explain the problem here with splitter? Why does it change the escaped characters and unescapes them? I use the latest splitter version from svn. Thanks Christoph

2 2

[PATCH] Distinguish stops with lit shelters by *
by Marko Mäkelä 28 Nov '09

28 Nov '09

The attached patch replaces the + in the names of shelter-equipped bus/tram/train stops with * when lit=yes. When travelling by foot or bicycle during dark time of a day, it can be helpful to find the nearest lit shelter for a break. Best regards, Marko

5 5

[PATCH v2] remove bogus nodes
by Mark Burton 28 Nov '09

28 Nov '09

v2 - avoid assertion when more than one routable way is generated from the same OSM way ------- With the recent reversion of the Table A breakage, it's now useful to post this patch for wider testing as it no longer causes my Nuvi to barf. What it does is remove routing nodes from ways that should never have been put there in the first place. Without this patch, a routable way will have a node for each of its points that are shared by any other way (whether the other ways are routable or not). For example, at the moment, if a way shares its points with a boundary line or shape, each of those points will become nodes. From the routing point of view, that's (essentially) harmless but having extra nodes does take up space and must slow down the routing calculation. It therefore makes sense to remove the bogus nodes. What this patch does is defer the processing of all of the points/lines/shapes until after their types have been computed. Having computed the ways' types we know what's routable and what isn't so nodes only need to be created where routable ways meet. That's the theory, in practice, it produces slightly smaller maps. Whether it actually improves the routing quality is yet to be determined. Obviously, the gain you will see depends on how many bogus nodes are in your maps. All feedback welcome. Mark

1 0

[PATCH v2] Fix Nuvi routing regression (rebloat Table A)
by Mark Burton 28 Nov '09

28 Nov '09

v2 - now does nothing more (or less) than revert commits 1228 and 1373. ------------ Way back in September, revision 1228 changed one of the routing data structures (Table A) to have one entry per road rather than one entry per arc (a road contains 1 or more arcs). This reduced the number of Table A entries required which made the maps smaller and, hopefully, improved the routing because the routing centres could be larger. However, I have been trying for some time now to find why the routing is partially broken on my Nuvi 255 for certain combinations of mkgmap version, extra patches and the options used when compiling the map. The same maps work fine (as far as I have tested them) on mapsource and the etrex. Not one routing failure occurred on those that could not be attributed to something else. So, after much dicking around with options, patches, etc., I think the Table A size reduction is the culprit. The attached patch essentially undoes the good work from September (although this code is simpler than what was there before). With this, the Nuvi barfs no more. The downside is that the map has grown again. Can't say whether the routing quality has changed. Rolled into this patch is another reversion. The value of MAX_ARC_LENGTH has been reverted to 75000. Never did believe that was the real solution. Please give it a go and report any findings. Mark PS - Marko, please try this and see if the routing problems you were experiencing still occur. Also, please try it on your Nuvi user and see if their problems go away. PPS - the one pleasing aspect of all this is that if it proves to be a sensible change, the node-reduction patch that I keep banging on about will see the light of day.

5 11

[PATCH v4] make DP filter avoid removing points located at nodes
by Mark Burton 27 Nov '09

27 Nov '09

v4 - err, try again --------- v3 - hopefully, now works again after being broken by the round coords filter. --------- v2 - based on r1402. ----------- Hi Felix, Please try the attached patch. I've tested it inasmuch that it doesn't blow up but whether it actually does the right thing when you have a routable and non-routable way from the same set of points, I don't know. Cheers, Mark

2 5

Commit: r1408: Revert "Reduce number of Table A entries."
by svn commit 27 Nov '09

27 Nov '09

Version 1408 was commited by markb on 2009-11-27 17:39:45 +0000 (Fri, 27 Nov 2009) Revert "Reduce number of Table A entries." This reverts commit 1228 (git aee105a6007420c27646d18264c2baaaf25911c0).

1 0