Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-07 Thread Gerd Petermann
sea. Gerd Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkg...@jagit.co.uk> Gesendet: Mittwoch, 8. Februar 2017 00:34:01 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r377

Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-07 Thread Ticker Berkin
t; An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 > > Hi Gerd > > Algo: > > Assumes list of outer polygons and list of inner ones; > Which inners go in each outer unknown. > No additional layers of nesting. &g

Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-07 Thread Gerd Petermann
.uk> im Auftrag von Ticker Berkin <rwb-mkg...@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 18:43:43 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Hi Gerd Algo: Assumes list of outer polygons and list of inner ones; Which inner

Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-07 Thread Ticker Berkin
ev-boun...@lists.mkgmap.org.uk> im Auftrag > von Ticker Berkin <rwb-mkg...@jagit.co.uk> > Gesendet: Dienstag, 7. Februar 2017 14:34:36 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 > > Hi Gerd > > orderByDe

Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-07 Thread Gerd Petermann
git.co.uk> Gesendet: Dienstag, 7. Februar 2017 14:34:36 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Hi Gerd orderByDecreasingArea only has a param declaration and single use in MapSplitter and its value transforms to MapArea.splitPolygonsI

Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-07 Thread Ticker Berkin
a (final) field in MapSplitter? > > Gerd > > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag > von Ticker Berkin <rwb-mkg...@jagit.co.uk> > Gesendet: Dienstag, 7. Februar 2017 13:45:25 > An: mkgmap-dev

Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-07 Thread Gerd Petermann
: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Done On Tue, 2017-02-07 at 12:17 +, Gerd Petermann wrote: > Hi Ticker, > > that's what I expected. Most shapes do not have too many points > after line simplification. > If I got

Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-07 Thread Ticker Berkin
Done On Tue, 2017-02-07 at 12:17 +, Gerd Petermann wrote: > Hi Ticker, > > that's what I expected. Most shapes do not have too many points > after line simplification. > If I got that right most of the code in PolygonSplitterFilter is now > obsolete. I think it would be > better to move the

Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-07 Thread Gerd Petermann
is kept. Gerd Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkg...@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 12:49:02 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produc

Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-04 Thread Gerd Petermann
Hi Ticker, Ticker Berkin wrote > I can't do anything for a couple of days but I'd like to combine the > methods. sounds good to me. I once analysed why sub divs were split and found that most times it was because of "too many points" or "too many lines", not because of "too much data in rgn",

Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-04 Thread Ticker Berkin
Hi Gerd One of the reasons I went along the PredictPoints route is that MapArea was calculating the subDivision usage (number of items, amount of data) based on totally unfiltered lines/polygons, regardless of the resolution, so this was forcing splits where no need whatsoever. I didn't want to

Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-04 Thread Gerd Petermann
ann_muenc...@hotmail.com> Gesendet: Samstag, 4. Februar 2017 09:18:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Hi Ticker, I think the problem is that PredictFilterPoints ignores the fact that the DouglasPeuckerFilter typically reduce

Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-04 Thread Gerd Petermann
Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenc...@hotmail.com> Gesendet: Freitag, 3. Februar 2017 19:28:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Hi

Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-03 Thread Gerd Petermann
Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkg...@jagit.co.uk> Gesendet: Freitag, 3. Februar 2017 18:56:06 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 H

Re: [mkgmap-dev] r3784 produces large img files than r3773

2017-02-03 Thread Ticker Berkin
Hi Gerd Most of the changes that will make a difference to size are related to MapArea/SubDivision contents and splitting hence ShapeMergeFilter activity. As far as changes in size between the versions: 3782-3784 should be similar and a little bit worse than 3781 because of a fix to stop a

[mkgmap-dev] r3784 produces large img files than r3773

2017-02-03 Thread Gerd Petermann
Hi Ticker, I compared the sizes for a map of spain with and without option --order-by-decreasing-area, I always see larger files with r3784. With r3777 and r3778 the files are typically a bit smaller than with r3773. Is there a good reason for that ? Gerd