Wouldn't this mean that tile boundaries would overlap if they were originally touching but not aligned?
Yes, you are right. The splitter code is not sufficiently documented to make it clear what it is trying to achieve. After looking at the code, it seemed to me that the goal was to expand the boundary of *each tile separately* so that it falls onto a coarse grid while still bounding the original tile. Having read your comment, I see now that this was an incorrect interpretation. The goal is to shift the boundaries *between tiles* so that they fall onto a coarse grid without introducing overlap. In this case, my patch is not correct. However, I have three observations/questions: 1. If the goal is to shift the boundaries onto a coarse grid, why round *down* for longitudes and *up* for latitudes? Why not round in the same direction for both? 2. After rounding boundaries, the code may shift some of them to ensure that the tile sizes are even multiples of the grid spacing. Since this is done for each tile separately, I think there is a potential to introduce overlap here. If overlap really is a problem (does it break drawing and/or routing?), the decision which boundaries to shift should be coordinated among the tiles.
There is a case for expanding the dimensions of the outside edges of a complete tile set.
3. My last point is related to this comment. The current rounding code does not distinguish between internal subdivisions and outside boundaries. Thus, it will shift the area covered by the tiles so that it no longer include the complete region originally requested. To fix this, as you say, the outside boundaries should be expanded onto the coarse grid. Finally, I am wondering how important the rounding is. It seems that mkgmap will happily process arbitrary .osm files, including those that never passed through the splitter and thus do not have rounded boundaries. Would it be possible to leave out the rounding? Or is it needed for inter-tile routing for example? - Bartosz