April 2009 - mkgmap-dev - The mkgmap lists

some comments on mkgmap default style
by maning sambale 06 Feb '10

06 Feb '10

Hi, some observation about the default style: 1. Coastlines are shown as thin blue lines, is it possible to render coastline as polygon, where sea areas are shaded as blue. A work around I did before is to manually edit all sea-areas and then add a natural=water tag (bad data edit) . 2. Administrative boundaries clutter the map. They appear like roads and can be confusing while driving. Suggestion is to make the admin boundaries thinner. Hope it helps improving the default stylesheet. -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

5 8

[PATCH] alpha patch for simplifying ways and reducing img size
by Johann Gail 27 May '09

27 May '09

Find attached an patch (usable on R915), which reduces the point density of ways and roads to reduce the filesize of the resulting img file. It does it by using the douglas peucker algorithm. With this algorithm it is possible to set a max error distance and the resulting line will have filtered out all points without any points outside this distance band. For an exact explanation consult wikipedia. I tried it with an error distance of 10m. Higher distances don't gain much more. The saving is in some areas with bad osm data (useless high point density) up to 25%. In general it saves only 5% in file size. Consider this patch as an alpha release, which should only show the possibilities. For the release it will need at least an option at the commandline for setting the error distance. Also I'm not sure, if the StyledConverter.java is the correct file for this patch. I've seen there is some filter infrastructure in the mkgmap project, but I've no idea how to use it.

5 14

[PATCH] enable xinclude in parser
by Christian Gawron 19 May '09

19 May '09

Hi, the attached patch enables the xinclude feature in the SAX parser. I found this useful to create maps with contour lines without having to merge the osm files: <?xml version='1.0' encoding='UTF-8'?> <osm version='0.5' generator='JOSM'> <xi:include href="contours.osm" xmlns:xi="http://www.w3.org/2001/XInclude"/> ... BTW: I wrote a little Java program to generate contour lines from the CGIAR GeoTIFFs. Is anyone interested in testing it? Best wishes Christian Index: src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5MapDataSource.java =================================================================== --- src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5MapDataSource.java (Revision 991) +++ src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5MapDataSource.java (Arbeitskopie) @@ -63,6 +63,8 @@ try { InputStream is = openFile(name); SAXParserFactory parserFactory = SAXParserFactory.newInstance(); + parserFactory.setXIncludeAware(true); + parserFactory.setNamespaceAware(true); SAXParser parser = parserFactory.newSAXParser(); try {

5 4

Bug Report: First rule matches in style files ... not quite!
by Thilo Hannemann 18 May '09

18 May '09

It says in the documentation that the first rule in the style file that matches the elements is the one used. That is not quite true! The reason is, that the code handles the rules by putting them into baskets organized by the first condition of the rule (with some exceptions). There is for example a basket for all rules with the first condition "highway=residential". When deciding which rule to apply the code will iterate through all the tags of the osm element. It will determine whether there is a corresponding basket and then apply all the rules in that basket in sequence, until one fits. This does work only in simple cases. For example see a way with the following tags: highway=residential rcn=yes This is a residential way that is part of the regional cycle network. (Probably derived by using the "relations" style file to add the tag "rcn=yes" to all ways that are part of an rcn network.) The lines style file will look like -- rcn=yes [ ... some attributes for ways of the cycle network ... ] highway=residential [ ... some other attributes for generic residential roads ... ] -- If the documentation was right the way should always match the first rule (rcn=yes ...). But that is not the case, because it depends on which of the two tags is handled first. This in turn depends on which tag comes first in the osm data. If the tag "rcn=yes" is handled first, the first rule will match, because there is a fitting basket "rcn=yes". This would be according to the documentation. If the tag "highway=residential" is handled first, that rule will (unexpectedly) match, because there is also a fitting basket "highway=residential". To summarize the problem: The baskets are not ordered, therefore the application of the rules is only "until first hit" inside a basket. Between baskets it is "first tag in the osm data that fits". To make matters worse the code also tries to optimize the rules, so that the simple rule "first condition determines basket" does not hold. By inspecting the code it is possible to tweak the rules so that everything works ok, but if somebody can't read the code and tries to build complex style files he will run into serious trouble. Best regards Thilo

3 4

Splitting the UK
by Stuart Poulton 17 May '09

17 May '09

Hi All, I currently use the following to download and split the UK from a planet file using osmosis. In order to get routable maps, should I now be using the mkgmap splitter on an extract of the UK from the planet ? Does osmosis allow mkgmap routing across tiles ? Regards Stuart get -O - http://planet.openstreetmap.org/planet-080730.osm.gz| gunzip -c | ../Software/osmosis-0.24/bin/osmosis --rx /dev/stdin enableDateParsing="no" \ --log-progress \ --buffer bufferCapacity=1000 \ --tee 15 \ --bounding-box top="60.855" bottom="58.695" left="-3.505" right="-0.745" \ --bounding-box top="58.705" bottom="55.495" left="-8.005" right="-4.995" \ --bounding-box top="58.705" bottom="55.495" left="-5.005" right="-1.495" \ --bounding-box top="55.505" bottom="52.995" left="-2.005" right="0.405" \ --bounding-box top="55.505" bottom="52.995" left="-5.005" right="-1.995" \ --bounding-box top="55.505" bottom="52.995" left="-8.005" right="-4.995" \ --bounding-box top="55.505" bottom="52.995" left="-10.655" right="-7.995" \ --bounding-box top="53.005" bottom="49.845" left="-8.005" right="-4.995" \ --bounding-box top="53.005" bottom="51.295" left="-10.655" right="-7.995" \ --bounding-box top="53.005" bottom="50.095" left="-5.005" right="-1.995" \ --bounding-box top="53.005" bottom="50.495" left="-2.005" right="-0.495" \ --bounding-box top="53.005" bottom="50.645" left="-0.505" right="1.005" \ --bounding-box top="53.005" bottom="50.895" left="0.995" right="2.005" \ --bounding-box top="50.105" bottom="48.995" left="-2.755" right="-1.995" \ --bounding-box top="52.750" bottom="52.250" left="-2.450" right="-1.250" \ --write-xml file="B-Grid0.osm" \ --write-xml file="B-Grid1.osm" \ --write-xml file="B-Grid2.osm" \ --write-xml file="B-Grid3.osm" \ --write-xml file="B-Grid4.osm" \ --write-xml file="B-Grid5.osm" \ --write-xml file="B-Grid6.osm" \ --write-xml file="B-Grid7.osm" \ --write-xml file="B-Grid8.osm" \ --write-xml file="B-Grid9.osm" \ --write-xml file="B-Grid10.osm" \ --write-xml file="B-Grid11.osm" \ --write-xml file="B-Grid12.osm" \ --write-xml file="B-Grid13.osm" \ --write-xml file="Midland.osm"

3 4

Commit: r996: Fix rounding in two places.
by svn commit 07 May '09

07 May '09

Version 996 was commited by steve on 2009-04-05 19:43:28 +0100 (Sun, 05 Apr 2009) Fix rounding in two places. Before the patch clipping was a little inaccurate. Some points 2m outside the bounding box gets included in the img. With this patch it works correctly now. I've tested this since some days and up to now found no new failures. Whatever the reason for this small delta was, there should be no bad effects, if one adds a somewhat bigger delta. - Johann Gail

3 5

Abbreviated text in mobileXT
by nyem 06 May '09

06 May '09

Hello, I wonder if anyone has tried mkgmap-generated map on Garmin mobileXT (symbian). Text labels (POI and streetnames) are all abbreviated. Burger King appears as B K, but KFC is OK. A spell search on 'Burger' correctly returns 'B K'. Setting all labels as uppercase doesn't work though. I've tried different options (latin1, lower-case in mkgmap and upcase, codepage in osm2mp) but still the same problem. No such problem viewing the map in mapsource. I use osm2mp.pl to generate the mp file and the same mp file works OK when compiled at mapcenter2. Attached are screenshots of mkgmap and mapcenter2 generated maps for comparison. best regards, nyem

5 8

Oops, sorry for the breakage!
by Mark Burton 03 May '09

03 May '09

Hi Steve, Sorry I broke the tests by adding Way(long). I wanted to make sure that all Ways had an id value. I don't know anything about building the tests, perhaps I should! Cheers, Mark

2 1

Commit: r1026: Fix tests so that they compile agains after Way() constructor
by svn commit 30 Apr '09

30 Apr '09

Version 1026 was commited by steve on 2009-04-30 21:44:59 +0100 (Thu, 30 Apr 2009) Fix tests so that they compile agains after Way() constructor was removed.

1 0

Commit: r1025: Prevent NPE when multi polygon missing the relation role.
by svn commit 30 Apr '09

30 Apr '09

Version 1025 was commited by steve on 2009-04-30 21:40:29 +0100 (Thu, 30 Apr 2009) Prevent NPE when multi polygon missing the relation role.

1 0