[mkgmap-dev] Problem with splitter

Tue Mar 13 16:33:18 GMT 2012

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 at aighes.de
> To: mkgmap-dev at 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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20120313/d6efad00/attachment.html 