June 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

Putting the DP code under the microscope
by Mark Burton 13 Aug '09

13 Aug '09

Hi, As today's topic is the DP code, I thought I would take a close look. Not sure, but is the i-- on line 93 erroneous? As i will be decremented at the end of the loop anyway, it seems to me that the extra decrement will give rise to the possibility that a Coord won't be tested to see if it's a CoordNode and so it will get zapped if it's not outside the error tolerance? Do we care? Cheers, Mark

5 18

Overview map: tiny patch/review series
by Elrond 12 Aug '09

12 Aug '09

Hi developers, Probably many have already noticed, that the overview map (used to contain the polygons for selecting tiles in mapsource) isn't perfect. Often the polygons are much too large, or sometimes too small. They also feel like having a bias (at least for me). I have tried to fix this. And I think I was successful. After a short talk on irc we concluded: Instead of just commiting stuff, I will post patches here on the ML for review. So that people can give comments before I commit them. This is for mainly two reasons: 1) Some thoughts are not too simple, and I want to make sure, everyone understands them and at the same time, that they're right. 2) Some parts change some internals drastically and I feel, I might have overlooked something in this cause. Elrond

7 22

Translating command line strings into target charset
by Marko Mäkelä 01 Aug '09

01 Aug '09

My friend, who owns a Garmin GPSMap 60CSx, notified me of a character set problem in a tile name of my map. I wasn't aware of the problem, because my Edge 705 does not display map tile names. The tile Etelä-Suomi (Southern Finland) appears as EtelÃ¤-Suomi, where the currency symbol ¤ is displayed as a black diamond. Other ä characters in the gmapsupp.img are encoded as the byte code 304 in octal notation. The workaround should be simple: in mkgmap.args, write the ä as \304 instead of using UTF-8. But I would except the parameter to be translated. After all, the style files are already interpreted as UTF-8. I think that the right fix of this bug would be such that \u escape codes are expanded before utf-8 to target character set translation, and hex and octal escape codes (\xC4, \304) are expanded after the translation. That would also allow us to embed Garmin control characters where desired. Also, I would like to have some transliteration in the UTF-8 to cp1252 (latin1) translation. The Garmin displays many latin1 and cp1252 code points as a black diamond, as I posted some time ago. We could avoid that by translating those code points. I attempted to override the built-in translation (in the JRE as far as I understood) some time ago, but I must have patched the wrong place, because my changes had no effect. Any hints, Steve? Regards, Marko

2 1

route displayed under the road
by maning sambale 27 Jul '09

27 Jul '09

Hi, I am sending several reports from feedback of other users. When you view the map, the route going there is placed under the actual road. mkgmap ver 1064 compile syntax time java -Xmx512m -jar ${mkgmap_path}mkgmap.jar --code-page=1252 \ --tdbfile --gmapsupp --latin1 --country-abbr=PHI --country-name=PHILIPPINES \ --no-poi-address --remove-short-arcs --route --road-name-pois --add-pois-to-areas --transparent \ --family-id=639 --family-name="OSM_PHIL" --overview-mapname=40000001 --series-name="OSM_PHIL" \ --description="OSM_PHIL" --style-file=${style_file} \ ${download_dir}split_file/*.osm.gz -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

2 5

[PATCH] some natural points
by Marko Mäkelä 11 Jul '09

11 Jul '09

Some natural=* POI values were missing from the translation. On the Edge 705, natural=wood will be displayed with an icon. That would be useful for marking the names of forest areas in cities. The other two (natural=rock, natural=water) will be displayed as hollow white circles by the Edge 705. The attribute natural=rock is not listed at http://wiki.openstreetmap.org/wiki/Key:natural, but I thought that it would be OK to mark large rocks (diameter over 1 m) as natural=rock. Please apply the attached patch. On a related note, when I tested this, I originally downloaded a small area and tried to create a map. The map was blank when zoomed at anything closer than 80 m. No tooltips were presented for any roads or POIs, and the Edge 705 complained something about no POI information being available. The bounding box of the download was as follows: minlat='60.3461917134347' minlon='25.0977978880827' maxlat='60.3564969730713' maxlon='25.1192281119173' Surprisingly, routing worked, even though the map was blank at closer zoom levels (tested 20 to 50 m). Ultimately, I edited a 180MB *.osm map tile in a text editor and changed some attributes there. When compiled, that map tile was displayed OK. Regards, Marko

4 11

Recommended "stable" version?
by Nop 03 Jul '09

03 Jul '09

Hi! According to the Wiki page, the last version recommended as reasonably stable is 858. As I needed some particular improvements, I am using 1001, which works reasonably well. However, there are some weird glitches in my map that may be caused by problems in my preprocessing or in mkgmap with equal propability. So an update to a later version might in order but quite a number of the posts here seem to indicate that many things are very experimental so this might be a change for the worse at the moment. My map is not intended for routing, so will not profit from any features to that end, I am rather hoping for general improvements of processing and reliability. So the question is: Are there any plans to work towards another recommended reasonably stable version? Or do any of you have a personal recommendation for a build that in your experience should not cause trouble? thanks Nop _______________________________________________

2 2

Option "preserve-element-order"
by Thilo Hannemann 02 Jul '09

02 Jul '09

Has anybody had success controlling the drawing order with the "-- preserve-element-order" option? The drawing order is random for me, with or without this option. Would be nice to get it working, though, especially for overlays. Regards Thilo

5 10

ASTER elevation data
by Marko Mäkelä 30 Jun '09

30 Jun '09

I came across this via Slashdot: http://asterweb.jpl.nasa.gov/ http://www.nasa.gov/home/hqnews/2009/jun/HQ_09-150_ASTER_Topographic_Map.ht… Quoting the press release above: "Previously, the most complete topographic set of data publicly available was from NASA's Shuttle Radar Topography Mission. That mission mapped 80 percent of Earth's landmass, between 60 degrees north latitude and 57 degrees south. The new ASTER data expands coverage to 99 percent, from 83 degrees north latitude and 83 degrees south. Each elevation measurement point in the new data is 98 feet apart." This is good news for us North Europeans. The north limit of the SRTM is a few hundred meters north from my home, about 30 km north from the Helsinki coast. Can anyone who knows the topography business take a look at this data and write scripts for translating ASTER elevation data and OSM with mkgmap? At the end of the above press release, there are a few links that ought to be useful for us: > For visualizations of the new ASTER topographic data, visit: > http://www.nasa.gov/topics/earth/features/20090629.html > Data users can download the ASTER global digital elevation model at: > https://wist.echo.nasa.gov/~wist/api/imswelcome > and > http://www.gdem.aster.ersdac.or.jp Best regards, Marko

5 4

Performance
by Richard Fairhurst 29 Jun '09

29 Jun '09

Hi all, I've not used mkgmap for a good while and am really impressed with all the features that've been added in recent months. I'm currently trying to create a map from a GB planet extract, and performance seems much slower than I remember. I've split the extract into six parts with splitter.jar (I'm using some big route relations so can't split it any further). The first .osm (36Mb) has been chuntering away for an hour and a half and the .img hasn't been produced yet - is this normal? The command line I'm using is: java -Xmx1000m -jar mkgmap-r1067/mkgmap.jar --style-file=/path/to/ cyclemap/ --route --net --no-sort-roads -c template.args The style file is reasonably complex and contains numerous 'set' instructions, plus a handful of relation 'apply's. My system is an Intel Mac mini, OS X 10.5, 1Gb. cheers Richard

5 8