[mkgmap-dev] Problems with sea in overview map

Wed May 19 12:14:50 BST 2021

Hi Gerd

I don't see that rounding can cause self-intersecting polygons - it
might produce sides that touch each other.

I imagine that DP can cause self-intersection and this is more likely
on shapes typical of the result of a hole-cut. I wasn't presuming it
would fix them.

RemoveObsoletePointsFilter should be able to remove the cut to a hole
that has become a point. However this is run after DP. Maybe swapping
the order would improve matters.

Ticker

On Wed, 2021-05-19 at 10:56 +0000, Gerd Petermann wrote:
> Hi Ticker,
> 
> I think the self-intersections are a result of the rounding of
> polygons with holes. DP just cannot fix those.
> 
> I don't want to "delay hole cutting per resolution". I want to remove
> the small holes. It doesn't matter if precomp-sea is used or not, it
> works for both.
> 
> Gerd
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Mittwoch, 19. Mai 2021 12:46
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> 
> Hi Gerd
> 
> I often see other polygons becoming self-intersecting at lower
> resolutions (or at least GPSMapEdit does). If the DP filter is doing
> this then maybe this should be tacked first, with an alternate
> version
> for polygons - I have no idea how this would be implemented.
> 
> Should shapeMergeFilter somehow consider each polygon as if its
> points
> are rounded to resolution, with adjacent duplicates removed. This
> should allow more merging and will be much less likely to be
> inhibited
> by the 256 point limit. Doing this, small holes/islands are likely to
> disappear.
> 
> I don't like the idea of trying to delay hole cutting per resolution,
> and I don't see quite how it would work for pre-comp-sea
> 
> Ticker
> 
> On Wed, 2021-05-19 at 07:06 +0000, Gerd Petermann 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
> _______________________________________________
> 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