November 2016 - mkgmap-dev - The mkgmap lists

Commit r3704: drawLevel_v2.patch + emptyArea_v2.patch:
by svn commit 25 Nov '16

25 Nov '16

Version mkgmap-r3704 was committed by gerd on Fri, 25 Nov 2016 drawLevel_v2.patch + emptyArea_v2.patch: Implement new special tag mkgmap:drawLevel to improve usability of the --order-by-decreasing-area options Patches by Ticker Berkin http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3704

1 0

splitter: issues when splitting planet
by Gerd Petermann 24 Nov '16

24 Nov '16

Hi all, during the last days I noticed that splitter is about to reach an internal limit when you split planet with a rather small max-nodes value, e.g. max-nodes=800000. The log contains many lines like this: way MAP occupancy: 32.000.000, number of area dictionary entries: 58132 of 65535 If the number of dictionary entries gets to 65535 (Short.MaxValue) splitter will fail. To fix this problem I plan to change splitter to use another data structure which will int values and allows to store much more entries. The drawback is that this will require more memory, maybe much more. My current estimation is +1GB Those who split planet: Please check the splitter log , esp. the last line that start with "way MAP occupancy". If you are close to 65535 consider to use a higher max-nodes value until I have coded the new data structures. Gerd

2 2

Question about ovm-work-files
by Carlos Dávila 22 Nov '16

22 Nov '16

mkgmap keeps ovm files unless --remove-ovm-work-files=true is specified. What are these files useful for once overview map is created? Can they be reused afterwards, for example if you create two or more img from the same input tiles or if you combine previously created img in a later step?

3 3

txt to typ with mkgmap
by Arndt Röhrig 21 Nov '16

21 Nov '16

4 4

splitter r440 released
by Gerd Petermann 17 Nov '16

17 Nov '16

Hi all, I've fixed a major bug in splitter which results in wrong output files when you pass a --split-file which contains overlapping areas. See also http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter&rev=440 Splitter doesn't generate such a file, but one can create such a file in an editor (intended or accidentially) I am not sure what happens when you create a gmapsupp with overlapping tiles, I'd expect problems with routing at the tile boundaries. So, I think splitter should stop when overlaps between tiles with the same mapid prefix are found, e.g. overlapping tiles 63240010 and 63240013 are not allowed, while overlapping tiles 12340001 and 43210001 would be considered okay. I've not yet implemented this test, what do you think about it? Gerd -- View this message in context: http://gis.19327.n8.nabble.com/splitter-r440-released-tp5885986.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 6

mkgmap:drawLevel and --order-by-decreasing-area
by Ticker Berkin 17 Nov '16

17 Nov '16

Here is a patch that implements mkgmap:drawLevel It is used in conjunction with --order-by-decreasing-area and overrides the natural polygon area that is used for output sorting, hence influencing which polygons are rendered over others. The higher the value, the later the polygon is written and hence should show over other areas. Values range from 1 to 100, 1..50 will be larger than any natural area and so output earlier. 51..100 will be smaller and written later. So, if you wanted the standard sea polygons to show, rather than any mapped area beyond the coastline, could have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=99 } [0x32 resolution 10] The default for sea is drawLevel=2 (drawLevel 1 might be needed for the map background / 0x4b). Nothing else has a default and so behaves as if between 50 and 51. The Garmin device will still respect any in-build or TYP specified _draworder. With --order-by-decreasing-area it works best if everything has the same _draworder. If your Garmin device has strange rules, like not showing City (0x01..0x03) or having green areas (0x14..0x21) at a lower _draworder than most other things, consider a TYP file giving 0x01..0x55 the same value (1) except 0x4b with a lower value (0). Ticker

4 7

Buildings in default style
by Jakob Mühldorfer 17 Nov '16

17 Nov '16

Hi, another question about the default style. Some buildings are not converted properly, because they are "caught" by other conversions first. For example a large supermarket building (like this one <https://www.openstreetmap.org/way/322291694>) is dealt with here https://github.com/openstreetmap/mkgmap/blob/master/resources/styles/defaul… And never to be seen again. Would it make sense to insert a > building=* & area!=no [0x13 resolution 24 continue] To the very beginning of the polygon file, so everything that is a building is rendered as building? Or does this have odd side-effects when something like a indoor building pitch is given two types? Regards Jakob

2 1

Warn when using invalid resolution in styles
by Jakob Mühldorfer 16 Nov '16

16 Nov '16

Hi, I just had a typo in a style using resolution "25" instead of "24". Turns out mkgmap silently drops objects appearing at invalid resolution without any warning. The "--check-styles" option also does not catch it. Maybe you could implement some kind of warning when invalid resolutions are used. Regards Jakob

2 1

Commit r3703: Improve style checks to detect resolution values > 24
by svn commit 16 Nov '16

16 Nov '16

Version mkgmap-r3703 was committed by gerd on Wed, 16 Nov 2016 Improve style checks to detect resolution values > 24 http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3703

1 0

Commit r3702: sortAreas_v5.patch: Add option --order-by-decreasing-area
by svn commit 14 Nov '16

14 Nov '16

Version mkgmap-r3702 was committed by gerd on Fri, 11 Nov 2016 sortAreas_v5.patch: Add option --order-by-decreasing-area Patch by Ticker Berkin, slightly modifed http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3702

9 14