Hi Felix, the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecar...@gmail.com> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then... On Mon, 7 Jun 2021 at 19:37, Gerd Petermann <gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case. See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution. Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecar...@gmail.com<mailto:extremecar...@gmail.com>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great). On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkg...@jagit.co.uk<mailto:rwb-mkg...@jagit.co.uk><mailto:rwb-mkg...@jagit.co.uk<mailto:rwb-mkg...@jagit.co.uk>>> wrote: Hi Gerd This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week. Ticker On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote: > Hi, > > the attached patch improves the overview map, but so far only when > precomp-sea is NOT used. > I tested it with --generate-sea=multipolygon,floodblocker so that > mkgmap really has a multipolygon with the natual=sea data. > > For each level in the overview map it uses the original multipolygon > data to compute the rings which will might visible at the given > resolution. This requires more time compared to the current code but > the result is much better and some fine tuning is possible. > > To be able to use this also with --precomp-sea we need some changes > in the code which generates sea.zip so that one multipolygon relation > for each tile is stored. > > I've uploaded the results here: > https://files.mkgmap.org.uk/download/511/compare.7z > What do you think? > > Gerd > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev