Hi, the current implementation of splitter doesn't even try to detect if a polygon contains a split tile. In short it works like this: a) read osm data and calculate the tile areas. b) Close file and start reading again c) Distribute all nodes, each node is written to a maximum of 4 different tiles. d) for ways, look at which tiles the points of the way were written, and write the way to all of them e) for relations, look at which tiles the nodes and points of the rel were written and write the rel to all of them There is no calculation in splitter that tries to connect the ways of a relation to find out what is inside or outside of the relation. So, if you look at one tile, you see only ways and rels that have at least one point in it. I think it is quite easy to implement a 3rd pass in splitter that a) detects to what tiles a relation was written and makes sure that all members (ways and nodes) belonging to this relation are also written to each tile (if not already done) a) detects to what tiles a way was written and makes sure that at least the 1st and last node of the way is written to each tile. This will allow mkgmap to calculate the details within the tile area as well as the multipolygons that have at least one point in that tile without any guessing. Maybe I also find a way to detect those ways and relations that may completely contain a tile. If I see this right, we just have to calculate the bounding box of all points and check if the tile area intersects with it This will find all good candidates, but maybe requires a lot more cpu time. Gerd
Date: Tue, 13 Mar 2012 16:30:22 +0100 From: osm@aighes.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with splitter
Maybe splitter could detect, if a tile is completely inside such a "polygon" and then only add a rectangle with a negative ID (or parse for highest used node/way-ID).
At all I think, that needed diskspace isn't a huge problem, if there is no more guessing.
Henning
Am 13.03.2012 16:06, schrieb Thorsten Kukuk:
Hi Gerd,
On Tue, Mar 13, Gerd Petermann wrote:
I'm not that sure option 2 will really blow up the tile size and CPU cost. Today, most people creating a map use a very huge number for --overlap to avoid this kind of problems. And how many multipolygons are really that big that they go over several tiles? I fear the administrative boundaries and coastlines. You are right, this could become a real problem :(
I think the coastlines are already incomplete for europe if you don't work on the planet file. Since they are no longer closed, would they really end in every tile?
Of course if you have an extract for great britain, or even more worse, for complete north america. Especially in the last case, you will have about 1500 tiles all containing the boundaries and the coastline.
Maybe the solution would be to merge mkgmap and tilesplitter and do the split on the processed mkgmap data. But I don't know enough about how this works to know if this is doable at all.
Thorsten
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev