April 2011 - mkgmap-dev - The mkgmap lists

typ not included in the gmapsupp
by maning sambale 06 Apr '11

06 Apr '11

I'm using r1905 with the following command: java -Xmx1512m -jar mkgmap.jar --read-config=args2.list philippines.osm.pbf MINIMAL2.TYP args2.list code-page=1252 latin1 country-abbr=PHL country-name=PHILIPPINES remove-short-arcs=5 route add-pois-to-areas family-id=639 family-name=OSM_PHIL overview-mapname=40000001 series-name=OSM_PHIL description=OSM Philippines style-file=/home/maning/Downloads/osm/routable_garmin/git/osmphgps/styles/default generate-sea=polygons,extend-sea-sectors,close-gaps=1000 adjust-turn-headings drive-on-right report-dead-ends ignore-maxspeeds link-pois-to-ways location-autofill=0 road-name-pois gmapsupp The gmapsupp doen't include the typfile. Moreover, it created other img even if I activated the gmapsupp switch: 5120 2011-04-06 12:37 40000001.img 566 2011-04-06 12:37 40000001.tdb 28743168 2011-04-06 12:37 63240001.img 28795392 2011-04-06 12:37 gmapsupp.img Any ideas? -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

1 0

NSIS installer improvements phase 3 v1
by Nakor 05 Apr '11

05 Apr '11

Hi, Please find attached a patch with a new set of enhancement/fixes for the NSIS installer: * new installer page allowing the user to delete MapSource cache * fix for maps with a space in the overview name * fix issues with custom versions of installer.nsi Thanks, N.

3 5

Commit: r1908: Enable file sizes up to 512M
by svn commit 05 Apr '11

05 Apr '11

Version 1908 was commited by steve on 2011-04-05 11:46:54 +0100 (Tue, 05 Apr 2011) Enable file sizes up to 512M In the img header there is a disk partition table, the sectors should be 6 bits and the cylinders should take up 10 bits. Previously had 8 bits for each, fix so that extra cylinders can be specified.

1 0

Mapsource crash DSK_PRIVPARTITION.CPP-312-6.16.3.0 / osmmap_mdr.img >128 MB ?
by Peter Lerner 04 Apr '11

04 Apr '11

Hello mkgmap developers! I experimented a little bit with the AiO Europe Map in Mapsource and the 496 available *.img tiles. ( Source of *.img files: ftp://ftp5.gwdg.de/pub/misc/openstreetmap/download.openstreetmap.de/aio/europa-daily/img/ ) Installing and viewing the AiO map in Mapsource is always fine. The problem is when you "select" the tiles e.g. to upload them to your GPS device. Then Mapsources crashes with an error: Mapsource Error "DSK_PRIVPARTITION.CPP-312-6.16.3.0" . To narrow down the problem I created arbitrary subsets of the available 496 *.img files and installed those into Mapsource. The crash happens always when you try to include more than approx. 290-300 tiles (ca. 2,2-2,3 GB). Same error every time, when you have more than that number of tiles. The problem is also _not_ related to a single tile! I suspect that there is some internal limit, e.g. number of certain elements, an index that exceeds a certain number, ...!? Could it be that the size of the osmmap_mdr.img being >128 MB is a problem? This was some eye-catching coincidence taking into account the Mapsource error DSK_PRIVPARTITION probably having to do with the "file system layout" in the osmmap_mdr.img file ? This problem drives a lot of people crazy since May 2010 ... there are some reports about that on the AiO wiki and AiO forum since then. If I can do any further analysis let me know (i'm not a java guru). Peter

4 5

Commit: r1907: Reduce artefacts caused by multipolygon cuts
by svn commit 04 Apr '11

04 Apr '11

Version 1907 was commited by wanmil on 2011-04-04 22:21:53 +0100 (Mon, 04 Apr 2011) Reduce artefacts caused by multipolygon cuts The artefacts are avoided by selecting cutting lines that lie on a n*2048 Garmin units grid. Additionally a bug is fixed where in some special cases an inner area was not cut out. This was caused by the java.awt.geom.Area.equals() method, that sometimes returns true although the compared areas are not congruent.

1 0

[PATCH v1] Prefer multiples of 2048 as cut coordinates in multipolygons
by WanMil 04 Apr '11

04 Apr '11

Based on the proposal of Ralf Kleineisel the patch tries to cut multipolygons at multiples of 2048 in Garmin coordinates. This reduces artefacts at the cut lines of the multipolygons. The patch contains also a fix for the bug found by Nakor (Some inner areas are ignored in mulitpolygon processing). Please test it soon. I plan to commit that within the next 2 days if noone complains about it. WanMil

5 6

natural=peak altitude conversion
by Minko 04 Apr '11

04 Apr '11

Hi, I've noticed some inconsistencies in the rendering of heights of peaks. In the default style file, the altitude is converted from meters to feet because Garmin likes that. natural=peak {name '${name|def:}${ele|height:m=>ft|def:}' } [0x6616 resolution 24] Here are some examples where it goes wrong: Kahler Asten, near Winterberg, Germany http://www.openstreetmap.org/browse/node/83318818 GPS shows: 256m Mapsource: no height info osm tags: * ele: 840,8 * name: Kahler Asten * natural: peak Wetztstein, near Winterberg, Germany http://www.openstreetmap.org/browse/node/664200355 Gps shows 235m Mapsource: no info osm tags: * ele: 771 m * name: Wetzstein * natural: peak Example where it is rendered correctly: Bremberg near Winterberg, Germany http://www.openstreetmap.org/browse/node/316037203 Gps shows 809m Mapsource: 809m osm tags: * ele: 809 * name: Bremberg * natural: peak So only if the altitude is given in numbers (without decimal fractions or m) it is rendered correctly. I'm sure this can be improved in the style file by some kind of logical expression but how?

2 3

Generating sea
by Josef Latt 03 Apr '11

03 Apr '11

Hi, I use '--generate-sea=extend-sea-sectors,close-gaps=2000,floodblocker' to generate the sea in my map. Between the sea polygones are little gaps. They aren't a problem, but the map looks better without them. Any hints? Gruß Josef -- PGP Schlüssel: 311D1055 http://keyserver.pgp.com

3 6

Commit: r1906: Fix IndexOutOfBoundsException when using pbf with generate-sea=fbdebug
by svn commit 03 Apr '11

03 Apr '11

Version 1906 was commited by wanmil on 2011-04-03 16:19:43 +0100 (Sun, 03 Apr 2011) Fix IndexOutOfBoundsException when using pbf with generate-sea=fbdebug

1 0

Sea (or lakes) issue
by Nakor 03 Apr '11

03 Apr '11

Hello, I have a tile out of splitter which covers the area http://www.openstreetmap.org/?minlon=-81.342773&minlat=41.220703&maxlon=-79… . I did not find yet any option to have the lakes (delimited by natural=coastline) rendered properly. I tried various generate-sea options but did not get the expected result. With no --generate sea I get only parts of Lake Erie and Lake Ontario with water (I guess because there are some water=* polygons in those particular places) With extends-sea-sector, MapSource crashes With multipolygons or no-sea-sectors, both lakes are OK but Ontario is flooded With polygons the whole tile is flooded What options should I use to get it right? Thanks, N.

3 14