January 2010 - mkgmap-dev - The mkgmap lists

Commit: r1518: Fix problem where polygon rules would overwrite line rules with the same key.
by svn commit 27 Jan '10

27 Jan '10

Version 1518 was commited by steve on 2010-01-27 12:57:17 +0000 (Wed, 27 Jan 2010) BRANCH: style Fix problem where polygon rules would overwrite line rules with the same key. Make the style tester on osm files more useful by using preserve-element-order so files are directly comparable and preserve the order of the elements in the input files. Default style now appears to fully work in the style branch. It does not use continue, and that is not compatible yet.

1 0

Re: [mkgmap-dev] Commit: r1491: The NSIS install builder can now
by Du Plessis, Bennie 27 Jan '10

27 Jan '10

G> How do you tell mkgmap to include the TYP file in the NSIS script? I G> think I tried the obvious, but I must be missing something simple. For G> now I need to edit the install script by hand. Index files are working G> as expected. G> G> Garvan Hi Garvan, I am not an expert, but your question intrigued me. I want to do the same. So I tried some things. I don't know what the obvious is that you tried, but what works for me is To include the TYP file in the input files to mkgmap. For instance java -ea -Dlog.config=Log.txt -Xmx1000m -jar path\to\mkgmap.jar path\to\map.osm path\to\file.typ The nsi script then contains commands to include the TYP file in the registry. Please see if this works for you. (I only tried a small test map, and only checked for commands in the nsi file, but I did not build or execute the installer yet) BennieD PS if this is the correct way, we should include it in a help file somewhere The opinions contained in this message are those of the sender only and do not reflect those of Sappi Limited or any of its subsidiary or associated companies. "This message, including any attachment(s), may contain information which is private, privileged or confidential and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient of this message, please notify the sender thereof and destroy/delete the message. Neither the sender nor Sappi Limited (including its subsidiaries and associated companies, jointly referred to as 'Sappi') shall incur any liability resulting directly or indirectly from accessing any of the attached files which may contain a virus or the like. Any opinions, statements, conclusions and other information contained in this message and/or its attachment(s) that do not relate or refer to the official business of Sappi Limited or any of its subsidiary or associated companies shall be regarded as neither provided nor approved by any Sappi company. Views expressed in this message or its attachment(s) may not necessarily be those of Sappi and Sappi cannot be held liable for any direct or indirect loss or injury resulting from the contents of a message and/or its attachments." Directors names A list of Sappi companies and the names of their directors can be retrieved from http://www.sappi.com/SappiWeb/Investor+info/Corporate+governance/Board+resu… ##################################################################################### Scanned by MailMarshal - Marshal's comprehensive email content security solution. Download a free evaluation of MailMarshal at www.marshal.com #####################################################################################

1 0

[PATCH v1] Remove error messages from multipolyon code
by WanMil 27 Jan '10

27 Jan '10

The patch reduces the error messages in case some polygons intersects or overlaps to warnings. Additionally all ways that are completely outside the bounding box are no longer processed. This is a result of the discussion http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/006629.html The warning message can be upgraded to error messages again if the multipolygon code has improved its tile bounds handling. WanMil

2 1

Commit: r1517: Reduce multipolygon error messages. (WanMil)
by svn commit 27 Jan '10

27 Jan '10

Version 1517 was commited by marko on 2010-01-27 08:00:49 +0000 (Wed, 27 Jan 2010) Reduce multipolygon error messages. (WanMil)

1 0

Commit: r1516: Updated style branch style tester.
by svn commit 27 Jan '10

27 Jan '10

Version 1516 was commited by steve on 2010-01-27 01:23:25 +0000 (Wed, 27 Jan 2010) BRANCH: style Updated style branch style tester. You can now give a style file and a .osm file and it will print out as text the result of applying the style. ways only at present.

1 0

Commit: r1515: Reclaim the setCollector on Osm5XmlHandler so
by svn commit 26 Jan '10

26 Jan '10

Version 1515 was commited by steve on 2010-01-26 23:38:33 +0000 (Tue, 26 Jan 2010) BRANCH: style Reclaim the setCollector on Osm5XmlHandler so that we don't always have to use MapDetails.

1 0

[PATCH v1] adjust turn headings more
by Mark Burton 26 Jan '10

26 Jan '10

This patch modifies the turn heading adjustment code so that the GPS will tell you to turn when you are routing from a main road to a side road in situations like this: S S ^ S | MMMMMMMMMMMMMM | M | M | M M You can see that the main road goes around a left corner and the side road carries straight on. Without this patch, neither mapsource or a Nuvi will tell you to turn right at this junction even if the side road has a different road class/speed from the main road. This patch also allows you to globally enable/disable the possible adjustments by providing a bitmask with the --adjust-turn-headings option. By default, all (currently, there are 2) kinds of adjustments are enabled. See the help blurb for more info. A value of 1 gives the old behaviour. Mark

3 6

Re: [mkgmap-dev] Bogus warnings about intersected ways in multipolygons
by Adrian 26 Jan '10

26 Jan '10

I don't think these warnings are bogus. Mkgmap definitely has problems with multipolygons. The Languedoc-Roussillon extract (southern France) from Geofabrik provokes about a hundred of these warnings. But I believe that the intersected ways are being generated by mkgmap and that the OSM data is OK. Mkgmap-r1475 did not have this problem but r1502 and r1507 both do. I am unable to pinpoint more accurately when the behaviour changed because I do not have copies of the relevant releases. Perhaps r1494 could be put back on the web site, in the hope that we might have the benefit of the fixes to generate-sea without the multipolygon problems. Exactly where the problems show up can depend on where the tiles are split. One example is at http://www.openstreetmap.org/?lat=43.4047&lon=3.5107&zoom=13&layers= B000FTF as seen on Lambertus' site. Take a look at his tile 63240406.img dated 20-01-2010. If you look at the vineyards (land-use polygons) in the vicinity of Pinet, you will see an obvious straight edge which is spurious, and areas where the inside and outside of the polygon have swapped over.

5 8

[PATCH v1] - handle "anti-islands"
by Mark Burton 26 Jan '10

26 Jan '10

This patch extends the sea generation stuff to cope with anti-islands (water inside, land outside and, presumably, where the anti-treasure is hidden). Anti-islands are tagged natural=water (you can't use natural=sea because it will be beneath the surrounding land polygon). Note that if your map contains any islands whose direction is incorrect, they will now be filled with water. To help find such islands, a warning message is output when an anti-island is discovered. The upside is that if your map contains anti-islands whose direction is correct, they will now become visible. Mark

3 5

Transliteration
by Steve Ratcliffe 26 Jan '10

26 Jan '10

Hi Back in October I created the translit branch to add all of the transliterations from the perl Text::Unidecode module, but I have heard no comments on it. I shall merge it, since it is probably better than showing question marks even for countries where it doesn't work very well. But there is one controversial point, in that I have included separate tables for latin1 in some cases, that include accented characters. These were derived from icu4j. However the romanisation schemes use many accented characters outside of latin1, so I had to drop those and the resulting mixture may not make any sense at all. In fact I will probably drop them, unless someone says that they are useful / or provides better tables. There is a better transliteration program being developed by 'greencaps' on the forum and is used by Lambertus's maps. This would be preferred but the code is not released, although the author says they intend to do so at some point. So the current transliteration on trunk and in the branch is neither language nor context dependant. That means that each letter is considered on its own and not in relation to the letter(s) that preceed or follow it. You can download a ready built jar at http://www.mkgmap.org.uk/snapshots/ (mkgmap-translit-r1314.jar). ..Steve

1 0