[mkgmap-dev] Problem with splitter

Tue Mar 13 08:07:18 GMT 2012

On Mon, Mar 12, GerdP wrote:

> 1) Enhance the logic in mkgmap that guesses how the missing ways completed
> the multipolygon, e.g. by adding a backtracking algorithmn (this is already
> suggested in the code).
> 2) Enhance splitter so that it writes all points and all ways of
> multipolygon to each tile.
> 3) Enhance splitter to write one extra output file that contains only the
> 1st and last point of each way that is part of a multipolygon, and create a
> method in mkgmap that looks for this data when 
> it doesn't find the way in the normal input. We need only the end points
> because we use the data only in cases where we know that they are outside of
> the bounding box. Maybe that can be done with osmfilter as well ?
> 
> I did not start coding, but I think option 3) should be easy to do and I
> hope it solves most
> of the problems. Option 2) looks more difficult and will blow up tile sizes
> and CPU cost both in splitter and mkgmap. Option 1) can be done as well. 

I don't like Option 1) at all, guessing what the data was will
only create new problems.

I would prefer Option 2), even if it is more difficult, for several
reasons. You have the correct data. You cannot run into problems if
the extra output file from 3) get's out of sync to the tiles. 
And every tile is self-contained, means you can mix them with others,
use only a subset, or give it away to somebody else without the need
to fiddle with other extra files, which have always to fit.

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?

  Thorsten

-- 
Thorsten Kukuk, Project Manager/Release Manager SLES
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)