[mkgmap-dev] Problems with sea in overview map

Mon May 24 14:33:15 BST 2021

Hi Ticker,

I think I found my mistake. The code to re-calc the preserved points was executed for each sub division instead of once per level.

The attached patch might already solve this.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Montag, 24. Mai 2021 15:03
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problems with sea in overview map

Hi Gerd

See other thread about DP / removeObsolete ordering. RemoveObsolete
tidies up the remains after DP has done things it shouldn't

For non-road lines re. first and last - I don't think any filters will
cause there not to be a point at the res-coord of the start or end, so
I don't see that there would be a gap for different types.

ShapeSplitter will notice if the dividing line has inconsistent (non
-alternating) direction crossings (probably caused by self
-intersection). It can't deal with this, just issues a warning. It
won't notice self-intersection elsewhere and allocates "outside" before
the first line crossing, "inside" next and alternates. I think it is
possible to come up with shapes where this is the opposite what you'd
expect.

Maybe we need a proper intersecting segments checker. I've investigated
some algos. Not sure what to do with self-intersection when we find it.
Lots are simply output in RGN and devices might have some defined way
of rendering. It's only the cutting and the overview merging that don't
really have a solution.

Ticker

On Mon, 2021-05-24 at 12:20 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> the removeObsolete filter sometimes ignores the preserved status, and
> probably it doesn't make sure to keep or copy that status. Maybe that
> explains why a following DP gives other results? I think in the
> current order there is no problem with this but I'll double check
> because I think somewhere mkgmap removes points which should be
> preserved.
>
> The first/last point of lines is preserved to avoid gaps between
> connected lines of different types, e.g. when a stream gets a river.
>
> The shape merger produces self intersecting shapes. I think this is
> not a problem as long as ShapeSplitter can handle this. Can it?
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Montag, 24. Mai 2021 12:54
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
>
> Hi Gerd
>
> The meaning of the preserved flag + handling of road/line/polygon etc
> to different filters seem to be getting a bit mixed up.
>
> I'm currently seeing some problems because of first/last points in
> line
> being preserved (which some filters respect and others don't). I can
> understand this for Roads, but not other lines. Is there a reason for
> this.
>
> preserveHorizonalAndVertical preserving multiple use points might be
> good initially but could hinder removeObsolete spike removal from
> removing the cuts to a collapsed hole.
>
> Still haven't got to grips with shapeMergeFilter, but the main tile /
> ovm_ generation is producing self-intersecting polygons.
>
> Ticker
>
> On Mon, 2021-05-24 at 06:52 +0000, Gerd Petermann 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
> _______________________________________________
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: preserve.patch
Type: application/octet-stream
Size: 1801 bytes
Desc: preserve.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20210524/44ce8dac/attachment.obj>