[mkgmap-dev] Problems with sea in overview map

Wed May 19 08:35:42 BST 2021

I think this is worse with too low polygon-size-limits... The default of 8
is pretty little. I think also for sea/islands a better approach is to only
consider resolution 24 and 23 to be detailed without much dropping /
generalisation. And then drop more. So something like
--polygon-size-limits=24:8,23:10,22:12,21:14,20 or bigger 20 makes more
sense as long as this does not empty the sea :-)

But yes of course, I am sure there are better ways to merge more than just
higher polygon size limits. That one is the dumb aproach...

In general maybe there is a better data source than OSM for the overview
map? Garmin is not using OSM data for their OSM based maps for the overview
map. Likely they decided it is too much work to get OSM filtered down
nicely. However I do not know which data would be compatible (to mkgmap and
more importantly in licensing). Aside from specilised things - like ICN/NCN
cycleroutes in a map for cyclists, the overview map should include:
Sea/Land (generalized)
Country borders
Very big cities (but relative to the population of that country) to at some
point only major capitals.
Very big/long rivers (rivers moved to relations - but they are often
lacking)
Maybe major railways
Major highways.
For resolution 17 and 16 maybe huge forests. but not much in terms of
polygons...
I likely missed 2-3 things but no more. And those things will be hard again
with OSM database. Would be nice to show the ice on the poles or maybe
green for the worlds largest jungles/forests - but that is soo hard with
OSM.

Likely with 3000-4000 hours manual work one could create a OSM derived
basemap database and then all those filters and considerations would be
much less important.

The full OSM dataset is just a burden for the overview map, I really
appreciate that you spend so much effort and time to improve mkgmap to work
around the limitations.

On Wed, 19 May 2021 at 15:06, Gerd Petermann <
GPetermann_muenchen at hotmail.com> wrote:

> Hi all,
>
> I've identified a few problems with the handling of natural=sea in areas
> with lots of islands, e.g. coast of Norway. Thouands of rather small
> polygons are created, esp. when also natual=land is rendered.
> 1. Typical tiles are rather large, they span several precompiled sea tiles
> if --precomp-sea=sea.zip is used. As of now, the polygons from different
> sea-tiles are never merged. This might be improved to reduce file size and
> possibly also improve rendering
> 2. Even at resolution 12 the curent code distributes the thousands of
> tiles into multiple sub divisions before ShapeMerger is executed for each
> subdiv. Shapes (polygons) are only merged when the number of points for one
> shape stays inside the IMG limit of 256 points, so the merger cannot do
> much.
> 3. Douglas-Peucker (DP) filter is used for the merged shapes which contain
> holes. This gives weird results because the invisible lines which connect
> the holes are causing heavy self-intersections at low resolutions. I think
> this is one reason for white triangles in the sea.
>
> I am experimenting with these ideas:
> - At low resolutions the ShapeMerger could merge more so that shapes with
> more than > 256 points are produced, assuming that DP filter will remove
> many of them. Not sure if this works with shapes that have holes.
> - At low resolutions it is likely/wanted that small islands disappear, so
> we should remove those first, together with the lines that connect them
> with the outer ring.
> - The simplified sea polygons without holes should be merged as much as
> possible before using any filter, maybe DP should be executed first on the
> merged shapes so that fever subdivs are created.
>
> Each method has its own effects and I'm searching for the best combination
> and order.
>
> A lot of this is only possible because we now have Tickers code that
> allows multipolygon splitting without using java.awt.geom.Area.intersect()
> . Tickers code in ShapeSplitter seems to be able to handle the holes
> properly.
>
> Gerd
>
>
> _______________________________________________
> 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/20210519/2aac1203/attachment.html>