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