August 2009 - mkgmap-dev - The mkgmap lists

[PATCH v2] - min arc length fixes
by Mark Burton 13 Aug '09

13 Aug '09

v2 of this patch not only enables remove-short-arcs by default when routing is in use (as previously discussed on ML) but it also fixes some problems in the way splitting code. I would be grateful if people could test this patch because it could possibly cure some routing failures. Cheers, Mark

2 8

Rounding bug in splitter?
by Chris Miller 13 Aug '09

13 Aug '09

Hi Steve/anyone, Can someone please clarify exactly how DivisionParser.round(Area) is supposed to behave? My understanding is that it is taking the area passed in and rounding the edges *outwards* to the nearest multiple of 0x0800. ie, the area should get a little bit bigger in each direction. If that is true, then I think there are a couple of bugs in the rounding up code, especially when dealing with negative values. Here's the output from some logging I put into DivisionParser.getTotalArea(): details=(41.23698949813843,-73.50664615631104) to (42.888779640197754,-69.93184089660645) minLat=1d52f7 maxLat=1e7faa minLon=ffcbba86 maxLon=ffce454c Rounded bounds=(41.220703125,-73.564453125) to (42.890625,-69.9609375) minLat=1d5000 maxLat=1e8000 minLon=ffcbb000 maxLon=ffce4000 As you can see, the min/max latitudes are both rounding 'outwards' and make the area bigger, as does the min longitude (though I think it should go to 0xffcbb800 not 0xffcbb000). The max longitude is rounding the other way and is making the area slightly smaller. This in turn leads to the following assertion failure (when processing massachusetts.osm with default settings and assertions enabled): Found val=1dc1ce42 lon=ffce4200 left=ffcbb000 right=ffce4000 Exception in thread "main" java.lang.AssertionError: -3259904 at uk.me.parabola.splitter.AreaSplitter.splitHoriz(AreaSplitter.java:101) at uk.me.parabola.splitter.AreaSplitter.split(AreaSplitter.java:74) at uk.me.parabola.splitter.Main.calculateAreas(Main.java:180) at uk.me.parabola.splitter.Main.split(Main.java:95) at uk.me.parabola.splitter.Main.main(Main.java:78) Another potential corner-case is when rounding the value 0 down. Because the check is for val > 0 rather than >= 0, it ends up being rounded down to 0xfffff800 rather than just being left as 0. Is that intended (not that I think that case matters so much)? Assuming my understanding above is correct, here's how I think the rounding methods should be implemented to give the correct rounding in all situations: private int roundDown(int val) { return val >> SHIFT << SHIFT; } private int roundUp(int val) { return (val + (1 << SHIFT) - 1) >> SHIFT << SHIFT; } I've tested this change successfully with several files including massachusetts.osm. What do you think, is it the right thing to be doing? Chris

7 16

Fixed Sea on Nuvi 860T
by Nolan Clifford 12 Aug '09

12 Aug '09

I manually set the colour for sea polygons in my style file and now they are showing up the same way as they do in Roadtrip / Mapsource.

1 0

Option --remove-short-arcs
by Steve Ratcliffe 12 Aug '09

12 Aug '09

Hi Is there any problem with this option, such that you might not want to use it? As I understand it, if you do not give it then routing will not work, as we know (or believe) that all routing arcs have to be more than 5.4m. If that is so, then we should just set the required behaviour whenever the route option is given. I realize that there might be other approaches, eg we could stretch arcs instead of removing them, but if removing them is our current best approach, lets make it the default. ..Steve

5 18

Inter tile routing broken
by Carlos Dávila 12 Aug '09

12 Aug '09

Yesterday I realized I can no longer calculate routes involving more than one tile in Mapsource using my Spain map. I compile it daily using latest svn and I don't know when the problem was introduced (it worked fine last time I checked it). I have tried splitting the map with latest splitter from svn and also with version downloaded from mkgmap.org. Resulting areas.list files are: svn-splitter: # List of areas # Generated Wed Aug 12 14:24:42 CEST 2009 # 63240001: 1677312,-446464 to 1941504,-137216 # : 35.991211,-9.580078 to 41.660156,-2.944336 63240002: 1941504,-446464 to 2048000,-137216 # : 41.660156,-9.580078 to 43.945313,-2.944336 63240003: 1677312,-137216 to 1894400,215040 # : 35.991211,-2.944336 to 40.649414,4.614258 63240004: 1894400,-137216 to 2048000,215040 # : 40.649414,-2.944336 to 43.945313,4.614258 web-splitter: # List of areas # Generated Wed Aug 12 16:08:13 CEST 2009 # 63240001: 1677312,-448512 to 1941504,-137216 # : 35.991211,-9.624023 to 41.660156,-2.944336 63240002: 1941504,-448512 to 2048000,-137216 # : 41.660156,-9.624023 to 43.945313,-2.944336 63240003: 1677312,-137216 to 1894400,215040 # : 35.991211,-2.944336 to 40.649414,4.614258 63240004: 1894400,-137216 to 2048000,215040 # : 40.649414,-2.944336 to 43.945313,4.614258 I also tried other osm files, with the same result. Does anyone know what is going wrong here? Regards Carlos

2 2

... and a success report
by Valentijn Sessink 12 Aug '09

12 Aug '09

A nice success report: I built a map of Germany for my Garmin Nuvi 205 BeNeLux & France. And guess what? Even inter-map-routing works! I can route from Amsterdam to an obscure place somewhere half way in Germany, without any problems. :-) V.

2 2

Commit: r1131: Add/improve help text.
by svn commit 12 Aug '09

12 Aug '09

Version 1131 was commited by steve on 2009-08-12 15:01:38 +0100 (Wed, 12 Aug 2009) Add/improve help text. - Valentijn Sessink

1 0

Sea Area not showing on Nuvi 860T
by Clifford Nolan 12 Aug '09

12 Aug '09

Just thought I would let you know that while I can see the sea area on my Vista HCx, I cannot on the Nuvi 860T. You may remember that I had some issue with the address not displaying properly on the latter unit too. I wonder if there are going to be issues with maps displaying properly on new units like the 860T. Perhaps Garmin have started changing their format. -- Regards, Cliff.

1 0

observation regarding "board ferry"
by Valentijn Sessink 12 Aug '09

12 Aug '09

Hello list, An observation I made regarding the "board ferry" message. I made a short route that involves a ferry in simulation (non-GPS) mode, so the Garmin will travel on the map all by itself. - both OSM and native Garmin will stop at the beginning of a ferry route, probably waiting for the virtual boat to leave. - however, the Garmin shows an icon of a boat, while the OSM map just shows an arrow (turn right/turn left). Could "board ferry" be a sort of turn restriction? I'm happy to test random values, but don't know where to look or what to look for. Anyone? Best regards, Valentijn

1 0

[PATCH v1] - Add support for marine (aka extended) types
by Mark Burton 12 Aug '09

12 Aug '09

Ahoy there shipmates, This patch is a first stab at providing support for the 3-byte extended types that are used on marine maps. Extended types are specified as a 6 digit hex number. The first two digits are always 01. An example type is 0x010200 (point type Buoy). Points, lines and polygons can all be given extended types. The cGPSMapper user manual lists all of the types. Note that routable ways cannot have an extended type. If you try to give a road an extended type, it will converted into a line. At this time, the various extra attributes that can be assigned to the marine entities (depth, colour, light colour/flash, etc.) are not handled but I have made some progress in understanding their encoding so at least some of these could be supported in the future. Obviously, the OSM data would need to be enriched to specify the required attributes. It now works well enough to warrant testing on more map data but I am expecting that there will be problems given the extent of the patch and the nature of what it's doing. Please test if you can and report success/failure/etc. Cheers, Mark

4 5