I feel that there is not too much need to get the size of the overview map down. Even for Asia continent map there is enough room. So it is better to make sure it looks nice - than smallest size. Also for resolution higher than overview map - it is usually not too important. Most people are navigating on land - so sea does not have to be rendered as often on your GPS device compared to land and roads. Meaning for >90% of Garmin mkgmap created map users it is not too often that you have a complex sea in your map. Even if you live on a mid sized island - say Cyprus or so - most of the time you do not have much sea on your GPS device. The recent work on reducing road complexity was much more important in real world use than what can be achieved by reducing sea complexity. Just my opinion. Of course nice if there is an improvement - but compared to land features for most users for sea it is not too important to reduce the points. The changes recently made did make quite a big difference in speed when zooming out / panning the map on my Oregon or etrex devices. For sea there is much less to be gained. Of course it is never bad to see some improvements - but it is less important. On PC / notebook - usually the processor should be plenty fast for drawing the map (plus the cache of Basecamp)..
On Mon, 24 May 2021 at 08:52, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Ticker / all, > > it seems I've looked at the wrong test files. I've tested with a few more > input files and now I see large white triangles with the branch version > 4736 while trunk 4735 doesn't show them. > Looks like a problem with preserving points or maybe special cases with > ShapeSplitter... > > Gerd > > > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > Ticker Berkin <rwb-mkg...@jagit.co.uk> > Gesendet: Samstag, 22. Mai 2021 13:30 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Problems with sea in overview map > > Hi Gerd > > I've been doing experiments on tiles with much more sea and islands > (tests before only had a bit of sea and lots of city). > > With my re-ordering I get a very slightly smaller main tile (4096 bytes > in 5614K) and larger osmmap.img (34304 vs. 25088) > > In both cases I'm getting quite a few shapeSplitter messages where it > finds inconsistencies in the line directions across the split-line; > normally due to self-intersection. These are happening in both the main > tile generation and the overview combining. > > Once shapeSplitter has generated this type of warning it is > indeterminate which is shape and which is hole, so I'd expect gaps in > the rendering. > > I think trunk had eradicated split/self-intersection problems in the > tile processing, including the ovm_ file generation. > > I'm not sure about the overview combiner as, in my standard map-build, > I don't merge shapes. > > Ticker > > On Fri, 2021-05-21 at 16:41 +0000, Gerd Petermann wrote: > > Hi Ticker, > > > > I tried this patch with r4734 and I see no improvements. Maps are > > larger, more white rectangles in sea. > > > > Maybe my recent changes don't work well with yours? Do you have an > > example where it improves something with r4734? > > > > Gerd > > > > ________________________________________ > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag > > von Ticker Berkin <rwb-mkg...@jagit.co.uk> > > Gesendet: Freitag, 21. Mai 2021 18:10 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Problems with sea in overview map > > > > Hi Gerd > > > > I'd been doing some investigation of filters ordering (based on > > trunk). > > I'd also done the pre-filtering of lines & shapes by minRes. > > > > My conclusions are: > > > > Shapes: > > It is better to run SizeFilter after RemoveObsoleteFilter. > > It is more efficient to run DP filter after both of these. > > > > Lines: > > LineSplitterFilter should be run after everything that can remove > > points. > > It is more efficient to run DP after RemoveObsoleteFilter. > > > > I've adapted my changes into a patch for the low-res-opt branch, > > along > > with removal of some resolution tests that are now redundant. > > > > For the contourFilters, I've left DP as the first filter but moved > > LineSplitter as for the normalFilters > > > > Ticker > > > > > > _______________________________________________ > > mkgmap-dev mailing list > > 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 > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > _______________________________________________ > mkgmap-dev mailing list > 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