Hi WanMil,
Now, I wonder what exactly splitter should do with a way that has only points in this overlap. To make it easier, let's assume that this way is not a member of a relation. Is such a way used in mkgmap or is completely ignored?
AFAIK yes - it's completely ignored.
OK, that allows to use overlap=0 if the problem cases below are properly handled.
If it is completely ignored, I think splitter should not to write it, else it should try to write it with all nodes.
Yes, that would be great. It would avoid a lot of problems with incomplete multipolygons.
Hmm, please review. If they are ignored they should not cause trouble. But anyhow, with overlap=0 we will not have such a case.
In other words: If splitter could make sure that every way and relation that a) has a node within the real bbox b) may enclose the real bbox c) may cross the real bbox is written to the tile with all related elements (nodes of ways, members of relations), would we still need the overlap?
I think the overlap is superfluous if splitter can guarantee a) to c).
Well, the split process already detects when a way or relation is written to more than one tile, so with overlap=0 this is a candidate for the problem list. Besdies runtime and memory consumption I see one open problem left: If you use a split-file to extract e.g. Iceland from a planet, there may be polygons (e.g. ferries) crossing this part of the world without having a node in any tile. The existing split process will ignore such a polygon exactly the same way as it ignores any way in Paris or New Yor and millions of other ways or relations. To solve this problem, I plan to add "pseudo-tiles", so that each node in the input file is processed and located in at least one tile. A way that runs somewhere in Paris will only be in "pseudo tiles" south of iceland, so it should be easy to detect it as unimportant. The ferry line that is crossing the Iceland area will have points in more than one pseudo-tile, so it will be detected as a problem polygon which can cross the real tiles.
If splitter can handle a) to c) you will have the complete country boundaries in each tile. Not a problem for Luxembourg but maybe in Russia, Canada or similar big states it will blow up each tile. Maybe this growth is worthy to check once during your development.
Yes, this was already discussed before, see http://gis.19327.n5.nabble.com/Problem-with-splitter-tp5555886p5561551.html and the discussion that followed. I think solutions are possible, but require complex coding of the multipolygon handling. I like to postpone this until I am sure that the rest works.
I remember an algorithm in mkgmap that searches the nearest city. Would this algorithm "see" a city that is in the overlap ?
No, this algorithm runs after all elements have been cut to the bbox.
OK.
If you manage to implement that you will solve a long outstanding problem of splitter/mkgmap so I cross my fingers that you are successful!
Yes, I think it can be done, but probably not on 32bit systems using planet as input. On the other hand, a 64bit system with 32Gb memory isn't that expensive anymore ;-) Ciao, Gerd