logo separator

[mkgmap-dev] Question regarding overlap in splitter and mkgmap

From Gerd Petermann gpetermann_muenchen at hotmail.com on Mon Oct 29 07:31:15 GMT 2012

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

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


More information about the mkgmap-dev mailing list