[mkgmap-dev] Problem with splitter

Tue Mar 13 14:48:54 GMT 2012

Hi Thorsten,

thanks for the qucick feedback.

> Date: Tue, 13 Mar 2012 09:07:18 +0100
> From: kukuk at suse.de
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Problem with splitter
> 
> 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.

okay. Anyway, as long as you don't use planet.osm as input to splitter, you'll
always have the risk that something is missing.

> 
> 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.

okay, these are good points

> 
> 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. 

Gerd

> 
>   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)
> _______________________________________________
> 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/e95fa774/attachment.html 