- mkgmap-dev - The mkgmap lists

Commit: r1524: Let the background polygon (type 0x4b) cover the whole map area.
by svn commit 10 Feb '10

10 Feb '10

Version 1524 was commited by markb on 2010-01-28 13:25:35 +0000 (Thu, 28 Jan 2010) Let the background polygon (type 0x4b) cover the whole map area.

4 5

Commit: r1568: Revert "Let the background polygon (type 0x4b) cover the whole map area."
by svn commit 10 Feb '10

10 Feb '10

Version 1568 was commited by markb on 2010-02-10 18:53:03 +0000 (Wed, 10 Feb 2010) Revert "Let the background polygon (type 0x4b) cover the whole map area." This reverts commit 1524. It has been reported that having a big background poly makes the eTrex Legend HCx ignore the colour defined for the poly in the TYP file and it reverts to using "Garmin yellow".

1 0

Commit: r1567: Do not remove ways that completely contain the bounding box
by svn commit 10 Feb '10

10 Feb '10

Version 1567 was commited by steve on 2010-02-10 13:10:11 +0000 (Wed, 10 Feb 2010) Do not remove ways that completely contain the bounding box in the multipolygon code. WanMil

1 0

Re : [PATCH v2] Multipolygon & generate-sea : patch v2 OK
by David 09 Feb '10

09 Feb '10

Hello Wanmil, I tried your patch v2 and it works for me.They are horizontal and vertical artifacts (like thin rectangular holes between sea polygons) but I am not sure they are linked to your recent changes. It is like a loss of precision or lost points depending on level of details. Thank you, David

1 0

BUG: riverbank drawing error
by Matteo Gottardi 09 Feb '10

09 Feb '10

Hi all. If a riverbank intersect a landuse, the riverbank should be drawn on top of the landuse. See the attachment for an example. Pls excuse my bad english... -- * Matteo Gottardi | matgott(a)tin.it * ICQ UIN 20381372 * Linux - the choice of a GNU generation * GPG Fingerprint: * B9EE 108F 52C8 D50C B667 B1F2 AB56 8A01 BA3D 36A1

4 3

Re : [PATCH v1] Multipolygon: do not remove ways that completely, contain the bounding box (WanMil)
by David 08 Feb '10

08 Feb '10

Hello Wanmil, I tried your patch and it did not work for me. As Steve pointed out the problem, I commented all the code of the patched removeWaysOutsideBox() and the sea multipolygon is generated as expected. I don't know if it is linked but there are still some artefacts which appear in Mapsource and GPS display depending on zoom level and visible in all detail levels. These artefacts are horizontal or vertical holes between pieces of lands (islands) and/or map border (tested with latest mkgmap and ireland.osm from geofabrik.de 2010/02/07, generate-sea=multipolygon,close-gap=1000 and default style). Cheers, David PS : thank you Steve

2 2

[PATCH v1] Reduce memory footprint of tags
by WanMil 08 Feb '10

08 Feb '10

The discussions around "Commit: r1566: Drop all tags from the osm file that are not used" inspired me to address the memory footprints of the tags. The patch reduces the memory footprint by using the String.intern() method. This ensures that the String "highway" exists only once when stored as tag. Additionally the values of the most common tags with a limited number of different values are also interned. (It makes sense to intern the value of a highway tag but it does not make sense to intern the value of a name tag because the share rate of the name tag values is too low). This all might sound embarrasing but the String objects that are returned from the XML reader are not interned. You can test this easily by exchanging the put method in class tag: public String put(String key, String value) { if ("highway".equals(key) && "highway" != key) { log.error("Tag is not interned"); } ensureSpace(); Integer ind = keyPos(key); if (ind == null) assert false : "keyPos(" + key + ") returns null - size = " + size + ", capacity = " + capacity; keys[ind] = key; String old = values[ind]; if (old == null) size++; values[ind] = value; return old; } You will see lots of "Tag is not interned" errors. I have seen memory reductions of > 10%. Please test this patch against your well known tiles. It would be perfect if someone has a tile and knows its minimum memory requirement for mkgmap. This patch should lower it. WanMil

3 2

[PATCH] Bug in label encoding
by Ronny Klier 08 Feb '10

08 Feb '10

I think there is a bug in label encoding in Format6Encoder. For some string length the last encoded byte is not stored. E.g. having a string "10007" the encoded byte buffer looks like this [0] [0x86] [1] [0x8] [2] [0x20] [3] [0x9f] [4] [0xf0] The number of stored bytes is 4. So the 0xf0 will not show up in the final image file.

4 4

Splitter caused a RestrictionRelation warning
by Marko Mäkelä 08 Feb '10

08 Feb '10

Chris, I had to shrink my tiles further to fix routing breakage, and got this additional warning (in addition to many multipolygon warnings) for the new splitting boundary: 2010/02/08 10:38:33 WARNING (RestrictionRelation): 63240002.osm.gz: Turn restriction http://www.openstreetmap.org/browse/relation/308019 lacks 'from' way I did not see this with the old areas.list, using the same source. This is just FYI when you work on preserving relations. Currently, I think that the current behaviour (discarding nodes or ways outside the cutting area) is OK for route relations but not for anything else (turn restriction, through-road, multipolygon). Marko

2 1

Small bug in mkgmap style handling on action rules
by Felix Hartmann 08 Feb '10

08 Feb '10

Hi, I just discovered a bug (this is happening on both trunk as well as style-speed). This rule is applied twice if both mtb:scale and mtb:scale:uphill are present: ( mtb:scale=* | mtb:scale:uphill=* ) { set name='${name} M${mtb:scale}${mtb:scale:uphill}' | '${name} M${mtb:scale}.' | '${name} Mx${mtb:scale:uphill}' | 'M${mtb:scale}${mtb:scale:uphill}' | 'M${mtb:scale}.' | 'Mx${mtb:scale:uphill}' } One can code around it like this which gives the result that would be expected from the single line above. I think this bug only affects action rules, not normal rules. mtb:scale=* & mtb:scale:uphill=* & extremecarvernameset!=* { set name='${name} M${mtb:scale}${mtb:scale:uphill}' | '${name} M${mtb:scale}.' | '${name} Mx${mtb:scale:uphill}' | 'M${mtb:scale}${mtb:scale:uphill}'; set extremecarvernameset=yes } mtb:scale=* & extremecarvernameset!=* { set name='${name} M${mtb:scale}.' | 'M${mtb:scale}.'; set extremecarvernameset=yes } mtb:scale:uphill=* & extremecarvernameset!=* { set name='${name} Mx${mtb:scale:uphill}' | '${name} Mx${mtb:scale:uphill}'; set extremecarvernameset=yes } This would not be noticed when action rules are used to work on access tags (acces tag set twice to the same value), but it can be confusing for setting the name. BTW is the --name-tag-list option still usefull. I think it can be better done directly from the style-file (or is it faster to do via name-tag-list??). Actually it would be great if for international names, we could have at least a second choice in the search index. Also the --no-sorted-roads option does not bring any speed improvements anymore. I think it can be removed.

2 2