Chris Miller wrote:
Hi Valentijn,
Chris Miller schreef:
but my impression is that the conclusion was that the splitter should be rounding areas off to boundaries in multiples of 4096 rather than 2048?
As far as I've seen - thanks to Steve Ratcliffe's findings - divisible by 2048 is enough, if you make sure that the difference is a multiple of 4096. (i.e. if your bounds are 0x123800 and 0x456800, that is OK; but 0x123800 and 0x456000 is not OK).
Anyway, dividing by 4096 is a good method of achieving this.
I've checked in what is hopefully a fix for this to the splitter. There's a new parameter called --resolution, which represents the lowest zoom level specified in your style file and dictates what boundaries to align the split tiles on. By default it's 13 which equates to tiles on boundaries of 2048 map units, and tiles with width/height in multiples of 4096 units.
the resolution option seems to be not working... I set resolution=15 but it defaults to 13. Actually if my lowest object is in resolution 16, meaning an empty level will be created at resolution 15, do I have to tell resolution=16 or resolution=15? - I assume 16, but to be on the safe side just went for 15..... Also since sometime the maxnodes seems to be disrepted, I noticed it this morning after updating from svn.... D:\Garmin\mkgmap>start /low /b /wait java -enableassertions -jar -Xmx1200M splitter.jar --mapid=63200000 --maxnodes=1000000 --resoultion=15 switzerland.osm /D:\Garmin\mkgmap>start /low /b /wait java -enableassertions -jar -Xmx1200M splitter.jar --mapid=63200000 /-/-maxnodes=1000000 --resoultion=15 switzerland.osm / /Time started: Thu Aug 13 01:03:10 CEST 2009 mapid = 63200000 maxnodes = 1000000 *resoultion = 15* Map is being split for *resolution 13:* - area boundaries are aligned to 0x800 map units - areas are multiples of 0x1000 map units wide and high Processing switzerland.osm 2.500.000 nodes processed... A total of 2595381 nodes were processed in 1 file Min node ID = 172204 Max node ID = 461905799 Time: Thu Aug 13 01:03:38 CEST 2009 Exact map coverage is (45.821378231048584,5.957551002502441) to (47.80904531478882,10.491621494293213) Rounded map coverage is (45.791015625,5.9326171875) to (47.8125,10.5029296875) Splitting nodes into areas containing a maximum of 1.600.000 nodes each... 2 areas generated: Area 63200000 contains *1.277.171 nodes *(45.791015625,5.9326171875) to (47.8125,8.1298828125) Area 63200001 contains *1.318.210 nodes* (45.791015625,8.1298828125) to (47.8125,10.5029296875) Writing out split osm files Thu Aug 13 01:03:38 CEST 2009 Processing 2 areas in a single pass Starting pass 1, processing 2 areas (63200000 to 63200001) 2.500.000 nodes processed... Writing ways Thu Aug 13 01:04:24 CEST 2009 Writing relations Thu Aug 13 01:04:44 CEST 2009 Wrote 2.595.381 nodes, 269.182 ways, 2.463 relations Time finished: Thu Aug 13 01:04:44 CEST 2009/
I've tested this with the netherlands.osm map and can't see any obvious problems (including around the tile borders and when routing across tiles), but as this is the first time I've used mkgmap to load osm files into MapSource I'm not 100% sure what I'm supposed to be looking for and your testing and comments would be appreciated.
Have a play and let me know if you think it's an improvement.
Cheers, Chris
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev