logo separator

[mkgmap-dev] Problems with sea in overview map

From Felix Hartmann extremecarver at gmail.com on Mon May 24 10:07:58 BST 2021

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_muenchen at 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-bounces at lists.mkgmap.org.uk> im Auftrag von
> Ticker Berkin <rwb-mkgmap at 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-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at 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 at lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20210524/fbb293db/attachment-0001.html>


More information about the mkgmap-dev mailing list