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