[mkgmap-dev] Error processing tile

Mon Jun 5 08:54:05 BST 2023

Hi Gerd

Yes. MapSplitter enforces all the subDivision limits (#items and
#pointsInItems) before the filtering has happened. A Polyline might
need to be split into many lines if it has a large number of points,
but, at a given resolution, many points might be discarded. Using this
fact it can estimate the worst-case number of line splits to use in the
subDivision line count limit. This logic makes the most significant
difference at low resolutions but, in Carlos's data, there must have
been roads with multiple points in res24 squares.

Ticker

On Mon, 2023-06-05 at 06:48 +0000, Gerd Petermann wrote:
> Hi Ticker,
> 
> okay, after some more debugging I think I understand. The problem
> is/was that the code in PredictFilterPoints assumes that the obsolete
> point removal happens before line splitting,
> but the actual order in MapBuilder is/was different (and wrong).
> 
> Gerd
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Gerd Petermann <gpetermann_muenchen at hotmail.com>
> Gesendet: Montag, 5. Juni 2023 08:14
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Error processing tile
> 
> Hi Ticker,
> 
> The fix helps with the data from Carlos and it also seems to improve
> the img size.
> So far so good.
> I don't understand if this patch really fixes the error or if just
> changes "something" which prevents the error.
> Or in other words: How does it prevent the overflow of the counter?
> 
> Gerd
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Sonntag, 4. Juni 2023 10:15
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Error processing tile
> 
> Hi Gerd
> 
> Realising that something is increasing the number of lines in a
> subdivision and I wasn't getting the problem with my build I
> remembered
> I'd noticed that this could happen due to changes made to the line
> filtering in the low-res-opt branch work and supplied
> filterOrderLowRes.patch to restore some of the vital orderings - see
> forwarded email.
> 
> The vital part is relating to MapSplitter/Area predicting the maximum
> number of splits to a line after RoundCoords & RemoveObsoletePoints
> have done their work.
> 
> Attached is patch of the code I've been using appropriate to trunk.
> 
> Ticker
> 
> -------- Forwarded Message --------
> From: Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> To: Development list for mkgmap <mkgmap-dev at lists.mkgmap.org.uk>
> Subject: Re: [mkgmap-dev] Problems with sea in overview map
> Date: Fri, 21 May 2021 17:10:07 +0100
> 
> 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
> _______________________________________________
> 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