- mkgmap-dev - The mkgmap lists

Commit: r1542: Fixes a problem with the log.log(Level, Object...) method. Logging
by svn commit 31 Jan '10

31 Jan '10

Version 1542 was commited by steve on 2010-01-31 19:21:45 +0000 (Sun, 31 Jan 2010) Fixes a problem with the log.log(Level, Object...) method. Logging messages were logged only if the logging level was set to INFO or lower no matter which logging level was provided as parameter. WanMil

1 0

[PATCH v1] log.log(Level, Object...) method did not consider the level parameter
by WanMil 31 Jan '10

31 Jan '10

Attached patch fixes a problem with the log.log(Level, Object...) method. Logging messages were logged only if the logging level was set to INFO or lower no matter which logging level was provided as parameter. WanMil

1 0

[PATCH v1] Self intersection warning in mp
by WanMil 31 Jan '10

31 Jan '10

The mp code warns if a polygon intersects itself. This has a drawback to performance by ~10% in log level WARN is turned on. With log level ERROR the check is not performed. WanMil

2 3

Commit: r1539: I've taken a different approach and no longer collect rules into different buckets to form an
by svn commit 31 Jan '10

31 Jan '10

Version 1539 was commited by steve on 2010-01-30 11:08:30 +0000 (Sat, 30 Jan 2010) BRANCH: style I've taken a different approach and no longer collect rules into different buckets to form an index. The rules are now read literally from the top and applied to the element in turn. It turns out that this does not add any significant time because it is still very quick compared to everything else that is going on. Continue is not enabled at all in this revision so do not use if you need it.

3 5

generate-sea=multipolygon
by Chris-Hein Lunkhusen 31 Jan '10

31 Jan '10

Hi, is generate-sea=multipolygon not working anymore in the recent version (1537) ? I tried to build the acores islands with this option but there is no sea and the coastline is disappearing. When I draw the sea by hand in josm (MP box with the islands as inner), all is fine. Chris

2 1

Display of railways
by Adrian 31 Jan '10

31 Jan '10

Another Garmin foible... Sightly off-topic, but I thought this was the best place to post this information. I have a Streetpilot c550 and an etrex Legend HCx. On both, the last zoom setting at which railways are visible is 800ft (resolution 23) with normal detail setting. I have discovered that the receivers override the resolution which is set in the map (usually around 18). Why have Garmin done this? Does someone at Garmin not like railways? RoadTrip does respect the resolution which is set in the map. I have worked around this by changing the line type used for railways. I make the new line type look like a railway, with a .TYP file. I use type 0x10 in a non-routable map, and this works as expected.

2 1

Mkgmap complains about '&' in role id
by Lambertus 30 Jan '10

30 Jan '10

There are a few tiles that fail to render due to 'Bad file format: 63240029.osm.gz' on every update and I've tracked it down to Mkgmap complaining about a '&' character in the role id of a way in a relation. Example: http://www.openstreetmap.org/browse/relation/359107 Can Mkgmap be made to accept this? Or is this an error in the planet dump procedure?

3 5

Analysis of finnland mp seabounds processing
by WanMil 30 Jan '10

30 Jan '10

The generation of the sea polygons with --generate-sea=multipolygon,no-sea-sectors sometimes still produce flooded areas. I have checked the finnland map and found the following things: 1. Some of the inner polygons generated for the seabounds mulitpolygon sometimes are inverted. Usually the inner polygons should denote all natural=land but some point out the sea are. This causes the flooding. I cannot precisely point to lines of code where this happens. It might have to do with self intersecting polygons. I have attached a GPX of one of self intersecting and inverted ones. Open JOSM, import the GPX, convert it to data layer, tag the polygon with natural=land. - Compare it with the real map, you will see that it is inverted. - Run the validator plugin. You will see that it has 27 duplicated nodes (I don't think that this is a problem). And there is an intersection in the east on the osmosis boundary shape. This should not create a real problem for mp. Maybe some parts of the polygon are dropped. But this might point to a problem of the sea multipolygon creation. I could easily add a warning if a way intersects itself. Don't know if that's a performance issue but will test it. 2. Some islands seem to be tagged with natural=land. They are not considered in creating the sea multipolgyon. Example: http://www.openstreetmap.org/browse/way/48666101 Hope these two things help to reduce the flooding. WanMil

2 1

Re: [mkgmap-dev] Can you set background colour in a TYP file?
by Adrian 30 Jan '10

30 Jan '10

I believe I have a solution for this. The default background colour of a Garmin map is yellow. You would expect to be able to change this by setting the colour of polygon type 0x4b, using a .TYP file. But some Garmin devices refuse to change the background colour. I have done some tests with an etrex Legend HCx, and in addtion to type 0x4b, you cannot change the colour of 0x27, 0x31, 0x52 and 0x010100. (All of these, except 0x52, can be changed in RoadTrip.) But you _can_ change the colour of type 0x010100 on the etrex if you specify it with a bitmap! You can have all pixels the same colour in the bitmap, and you can have different colours for day and night. This is the solution used by the creator of openmtbmap, although he did not explain it. [You always have to list two colours for the bitmap. The openmtbmap bitmaps contain one pixel of the second colour. Perhaps his .TYP compiler insisted that both colours must be used.] This trick does not work with polygon type 0x4b. If you are using --generate-sea=no-mp [as in openmtbmap], you can use type 0x010100 for your land polygons and the problem is solved. I have just learned from "[mkgmap-dev] Commit: r1524: Let the background polygon (type 0x4b) cover the whole map area" that mkgmap draws background polygons of type 0x4b automatically. So we are very close to a solution for those who are not using --generate-sea or who are using --generate-sea=multipolygon. Therefore I have a suggestion - to have an option in mkgmap, either on the command line or as a style rule, for the user to choose the type of the background polygons.

1 0

Commit: r1541: Remove RuleHolder which no longer
by svn commit 30 Jan '10

30 Jan '10

Version 1541 was commited by steve on 2010-01-30 15:17:41 +0000 (Sat, 30 Jan 2010) BRANCH: style Remove RuleHolder which no longer serves any purpose. Used the Rule directly where ever a RuleHolder was used.

1 0