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

Sat Feb 4 10:13:29 GMT 2017

Hi Ticker,

attached is a patch based on r3777 which implements my idea of backtracking, see
gis.19327.n8.nabble.com/Multipolygon-Relation-checks-in-mkgmap-tt5889908.html

I think this is the better way to implement the split at high prec. It's based on r3777 because
that was the last version without the PredictFilterPoints. I did not try to implement the other improvements done in
later releases.

What do you think about this approach?

Gerd
________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen at 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 reduces the number of nodes.
The result is that many shapes are split although they would not have too many points after DouglasPeuckerFilter.

Gerd
________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen at 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 Ticker,

my impression is that the new algos are more likely to place nearby objects into different sub divs,
that would be bad for ShapeMergeFilter, esp. without --order-by-decreasing-area.
I'll try to find out more tomorrow if you have no simple fix for that.

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, 3. Februar 2017 18:56:06
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773

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 large subdivision being extended on both sides

3781 should be quite a lot better than 3780 because it stops irrelevant
items being added to the MapArea data usage count, triggering more
splitting than necessary

3779 should be better than 3778 because it should stop a lot of
splitting at lower resolution

3778-3774 should be broadly similar

Relating to a given version with and without OrderByDecreasingArea:
I've always found images a bit bigger - sometimes up to 4% for areas
with large numbers of adjacent buildings that shapeMergeFilter joins.

I haven't done anything intentional that would change this in any of
the recent revisions.

I'm not sure if this answers your question

Ticker

On Fri, 2017-02-03 at 16:32 +0000, Gerd Petermann wrote:
> 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
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: splitHighPrec.patch
Type: application/octet-stream
Size: 9758 bytes
Desc: splitHighPrec.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20170204/59e612e9/attachment-0001.obj>