- mkgmap-dev - The mkgmap lists

Why do we render place=island polygons in the default style?
by Gerd Petermann 25 Jul '16

25 Jul '16

Hi all, we came accross this in this discussion : http://gis.19327.n5.nabble.com/Option-to-output-polygons-in-size-order-tp58… The polygons file contains these two rules: place=island & name=* [0x53 resolution 19] place=islet & name=* [0x53 resolution 20] I assume they were added to "catch" small islands within lakes, but they are producing really large and complex polygons for islands like the monster mp-relation 6038068<https://www.openstreetmap.org/relation/> which covers the mainland of the UK. According to GPS MapEdit the polygon type 0x53 seems to stand for "Sandbank, tidal/mud flat", which might be good for very small islands/islets, but makes no sense for really large islands. What would be missing without the 1st rule, esp. when precompied sea data is also used? I can think of adding more clauses, e.g. place=island & name=* & natural!=coastline ... place=island & name=* & area_size() <= 100000 ... Any thoughts? Gerd

2 5

Re: [mkgmap-dev] Commit r3680: reduceImgSize_v2.patch :
by Mike Baggaley 23 Jul '16

23 Jul '16

Hi Gerd, this seems to have made a very good improvement in file size - my GMAPSUPP.IMG file has gone from 1.2GB to 1 GB. Thanks, Mike

1 0

Transferring .typ files
by Jakob Mühldorfer 21 Jul '16

21 Jul '16

Hi, sorry for a basic question, but I could not find out how to do it with the information given on the internet. Is there a way to transfer a typ file from one gmapsupp.img to the gmapsupp.img generated in mkgmap? Either during build, or by editing the finished gmapsupp.img Thanks for help on this Jakob

2 1

Commit r3683: Improve Code in LinePreparer
by svn commit 21 Jul '16

21 Jul '16

Version mkgmap-r3683 was committed by gerd on Thu, 21 Jul 2016 Improve Code in LinePreparer - If the (byte) length was not improved, prefer the bit stream that doesn't need the special "trick" to encode large values, it is assumed that this can safe a few CPU cycles when reading the map (suggested by Alexandre de Menezes) - slightly reduce needed number of iterations for search of shortest bit stream - Remove seemingly useless and confusing code in calcDeltas() http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3683

1 0

Commit r3682: Improve Filter to catch special cases where the closing point of a shape is part of a spike
by svn commit 21 Jul '16

21 Jul '16

Version mkgmap-r3682 was committed by gerd on Thu, 21 Jul 2016 Improve Filter to catch special cases where the closing point of a shape is part of a spike or lies on a straight line This will remove a few more obsolete points from shapes, but the effect on the img size is very small. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3682

1 0

Bit operatons in mkgmap
by Gerd Petermann 21 Jul '16

21 Jul '16

Hi Steve, I'd like to change this code in LinePreparer (and a copy in LinePreparerFilter) // XXX: relies on the fact that java integers are 32 bit signed final int offset = 8+shift; to final int offset = (Integer.SIZE - 24) + shift; As you see I assume the value 8 is the result of 32 - 24. and I guess that 24 is the maximum resolution. Maybe we have a proper constant for that ? Gerd

2 2

Commit r3681: add check for possible null pointer exception (NPE)
by svn commit 20 Jul '16

20 Jul '16

Version mkgmap-r3681 was committed by gerd on Wed, 20 Jul 2016 add check for possible null pointer exception (NPE) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3681

1 0

Commit r3680: reduceImgSize_v2.patch :
by svn commit 20 Jul '16

20 Jul '16

Version mkgmap-r3680 was committed by gerd on Wed, 20 Jul 2016 reduceImgSize_v2.patch : - Implement the "trick" to store delta values which require more bits than the "base" value says - Try different base values to find out if the trick reduces the length of the bit stream The patch reduces the image size by up to 13%, the additional iterations may require a few percent more run time. A real world example that shows how the "trick" works: https://www.openstreetmap.org/way/245112355 This highway has 6 points, it starts in the north, the x-delta values (in resolution 24) are 4, -19, -5, 0, 3 The largest absolute value is 19 which requires 5 bits: 10011. Since both positive and negative values exist, we have to encode the sign for each single delta value, so we have to use 6 bits (the leftmost gives the sign) So, the first iteration gives: 6 bit words : 4 = 000100 , -19 = 110011, -5 = 111011, 0 = 000000, 3 = 000011 --> 30 bits Now, the optimization process starts trying to use the "trick" with 5 bits. WIth the trick, the value 19 doesn't fit into 5 bits, so the trick is used (it stands for the binary value 1111) and the result for -19 is 10000 11100 (15 + 4 made negative) All other values fit into 5 bits, so the 2nd iteration gives: 5 bit words: 4 = 00100 , -19 = 10000 11100, -5 = 11011, 0 = 00000, 3 = 00011 --> 30 bits The next step is to try with only 4 bits. Again, only the value -19 needs the trick, this time we get - 19 = 1000 1000 1011 (7 +7 + 5 made negative) 4 bit words : 4 = 0100 , -19 = 1000 1000 1011, -5 = 1011, 0 = 0000, 3 = 0011 --> 24 bits The next step is to try with only 3 bits. This time, more values need the trick (4 , -5 and -19). For -19 we get 100 100 100 100 100 100 111 (3 + 3 + 3 + 3 + 3+ 3 + 1 made negative) The result: 3 bit words : 4 = 100 001 , -19 = 100 100 100 100 100 100 111, -5 = 100 110, 0 = 000, 3 = 011 --> 39 bits So, we see that the trick is used too often now and the resulting bit stream is much longer than the one before. So, using the trick with 4 bit words saves 6 bits for the x values. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3680

1 0

Commit r3679: overview_levels_v3.patch
by svn commit 20 Jul '16

20 Jul '16

Version mkgmap-r3679 was committed by gerd on Wed, 20 Jul 2016 overview_levels_v3.patch Fix possible problems with 0x4a polygons in the overview map when tiles with different levels are merged into one map The old code used only the first processed tile to calculate the level 0 resolution for the overview map. The patched version collects all 0x4a tiles and - if needed - reduces the resolution so that the largest tike can be written without problems. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3679

1 0

Tool to dump index?
by Thorsten Kukuk 19 Jul '16

19 Jul '16

Hi, from time to time I face the problem, that POI or addresses are not findable in mapsource or on the GARMIN device. But if you look at the map, they are there. With other styles, or making "small" changes to the style by disabling a random POI, suddenly they are there. But sometimes then other POI or addresses are missing. Is there a tool which dissembles a map and prints relevant informations about the index? I would like to compare the cases, where an index entry is not found and where it is found, and what the difference is. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

2 1