Hi Gerd,
> 1) According to Steve the alignment to 2048 units is not mandantory, > the ony important point is that you don't have gaps. > The value 2048 results from the default resolution 13 : 2 ^ (24-13) = > 2048. I see. In resolution 13 the overview map is generated, right? This emtpy polygon for this map is visible behind the OSM map and doesn't match the foreground tiles if they are not aligned to this 2048 units. This explains I think in this kind of artefacts at the corners: https://dl.dropbox.com/u/64716698/OSM/mkgmap/corners.jpg Another thing is that the map disappears (behind the background overview map?) and becomes unroutable when you zoom into this edges at very high zoom. Since this all happens at the edges it is not so important, but when I combine those maps, it becomes an issue. > Regarding improvements: > If I got this right your problem is that you don't have enough memory > to split Europe with option keep-complete, > and the bottleneck is in the " handle-problem-list" phase. That is a problem, but the main reason is that I try to divide Europe into a few logical areas (that fits together) which are small enough to make a gmapsupp.img to download for my map users. And I dont want to let the splitter decide those areas, but I want rectangular areas. https://dl.dropbox.com/u/64716698/OSM/mkgmap/EU_N1_GPS.jpg https://dl.dropbox.com/u/64716698/OSM/mkgmap/EU_N2_GPS.jpg Last try was to feed the splitter N1.poly and M1.poly, those polygons were aligned at the Garmin grid (dividable by 2048) but the splitter rounded the polygons differently, so the ressulting tiles of N1 and M1 didnt quite match (and their borders were not a multiple of 2048). > I see these options to help in your case: > 1) Complex: Implement an algorithm in splitter which does something > similar to your approach: Partition the input file into a few large > areas > and calculate each partition seperately. Maybe you can use N1 and M1 poly's as example? > 2) Simple: Implement a parm that tells splitter not to trim the tiles > to the polygon boundaries. Since splitter initially generates tiles > which are aligned this > might help. is implemented in the attached patch. > You have to add parm --no-trim-to-polygon to activate this. > The binary is available here: > http://files.mkgmap.org.uk/download/90/splitter.jar Thanks Gerd, I'll give that a try and run the splitter on N1/M1 to see what the results are.
N1.poly
Description: Binary data
M1.poly
Description: Binary data
_______________________________________________ mkgmap-dev mailing list [email protected] http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
