[mkgmap-dev] Problems with sea in overview map

Mon May 24 13:20:34 BST 2021

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