August 2009 - mkgmap-dev - The mkgmap lists

mapname splitter V mkgmap
by frmas 19 Aug '09

19 Aug '09

Hello, Always testing, to find out what I'm doing wrong. If I run mkgmap that way : OPT_GMAPSUPP=" \ -Xmx896M \ -jar $FILEDIR/mkgmap.jar \ --country-name=$COUNTRY_NAME \ --country-abbr=$COUNTRY_ABBR \ --family-id=148 \ --gmapsupp \ --ignore-maxspeeds \ --ignore-turn-restrictions \ --latin1 \ --location-autofill=1 \ --lower-case \ --preserve-element-order \ --product-id=$INDEX_CARTE \ --remove-short-arcs \ --road-name-pois \ --route \ --style-file=$FILEDIR/styles/arvernes \ --tdbfile \ --transparent \ -c $CARTESDIR/template.args \ " java $OPT_GMAPSUPP --description="$DESCRIPTION" --family-name="$FAMILYNAME" --series-name="$SERIESNAME" Or that way : OPT_GMAPSUPP=" \ -Xmx896M \ -jar $FILEDIR/mkgmap.jar \ --country-name=$COUNTRY_NAME \ --country-abbr=$COUNTRY_ABBR \ --family-id=148 \ --ignore-maxspeeds \ --ignore-turn-restrictions \ --latin1 \ --location-autofill=1 \ --lower-case \ --mapname=09050305 \ --preserve-element-order \ --product-id=$INDEX_CARTE \ --remove-short-arcs \ --road-name-pois \ --route \ --style-file=$FILEDIR/styles/arvernes \ --tdbfile \ --transparent \ -c $CARTESDIR/template.args \ " java $OPT_GMAPSUPP --description="$DESCRIPTION" --family-name="$FAMILYNAME" --series-name="$SERIESNAME" The map created is always named : 63240500 For the first run, i understand, but for the second, I thought the map would have been named 09050305.img Between the two runs, I removed the option --gmapsupp and replaced it with --mapname=09050305 The template.args file : mapname: 63240500 description: OSM Map input-file: 63240500.osm.gz So I suppose that once the mapname in the template.args file is given, I can't change it with a parameter on the mkgmap command line, as long as I use the "-c template.args" parameter ?? Francois --

2 4

Instructions to make contour maps
by Nolan Clifford 19 Aug '09

19 Aug '09

Ralf, thanks for posting your instructions. I will try them out later. Is is it possible to do without srtm (I'm on a mac and want to avoid executing windows commands)? Am I on the right track with the following approach: 1. Download file(s) from say http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Eurasia/ . Suppose I download N52W009.hgt.zip 2. Decompress the above file(s) and store them in some directory ("jnk" in my case). 3. Download a .osm file with data covered by the bounds of the contour data in step 1. 4. Compile with the command java -Xmx1g -Xms1g -jar /Applications/ mkgmap/dist/mkgmap.jar --description="OSM_Ireland" --country- name="Ireland" --country-abbr="IRL" --series-name="Openstreetmap" -- latin1 --tdbfile --codepage=1252 --family-id=1 --product-id=1 -- contours --dem-type=SRTM --dem-path=/Users/nolan/jnk/ --dem-separate- img data.osm The above fails. I often get an error whereby it is looking for contour data in a neighbouring tile that I was not expecting it to need but maybe it needs to do some interpolation. Once I fix this and download the required contour tile I then get a weird error whereby it compains about negative altitudes! For example: EVERE (Main): java.util.concurrent.ExecutionException: java.lang.IndexOutOfBoundsException: elevation: -610 631 java.util.concurrent.ExecutionException: java.lang.IndexOutOfBoundsException: elevation: -610 631 Maybe I am under completely the wrong impression and what I am trying to do is just not possible. Either way, any enlightening pointers would be appreciated. Thanks, Cliff

2 1

Commit: r1139: The latitude output in NOD3 now has 180 degrees (0x800000) added to it.
by svn commit 18 Aug '09

18 Aug '09

Version 1139 was commited by markb on 2009-08-18 23:27:08 +0100 (Tue, 18 Aug 2009) The latitude output in NOD3 now has 180 degrees (0x800000) added to it. Shouldn't make any practical difference but at least it's more authentic!

1 0

[PATCH v1] - fix boundary node lat
by Mark Burton 18 Aug '09

18 Aug '09

I discovered that the latitude value in the boundary nodes (NOD3) table should have 180 degrees added to it (aka 0x800000) to make it consistent with Garmin maps. The fact that we can route between (our) tiles without this mod shows that it doesn't really matter but we may as well be as authentic as possible. So, tiddly patch attached, please test it with regard to inter-tile routing. I am not expecting anything to change. Cheers, Mark

2 2

Commit: r1138: Update to v3 of Rudi's multipolygon patch.
by svn commit 18 Aug '09

18 Aug '09

Version 1138 was commited by steve on 2009-08-18 12:32:19 +0100 (Tue, 18 Aug 2009) BRANCH: multipolygon Update to v3 of Rudi's multipolygon patch. Code added to deal with multiple outer polygons.

1 0

maps mixed
by frmas 18 Aug '09

18 Aug '09

Hello, Now according to the latest firmware, we no longer have to create a gmapsupp.img file to get multiple maps. I created multiple maps (data downloaded from geofabrik), and put them on the SD card. The first one (Auvergne or "Massif Central") is one I bought. germany (just baden-wuerttemberg) and france are created using my script from geofabrik data, and if I have only the first three ones, they all (3) appear well in the menu (so auvergne, germany, and france). I created four more maps (andorra, Switzerland, Luxemburg, and belgium). but now, just "auvergne.img" = massif central) is well displayed in the menu. France is mixed with Andorra and Belgium, Switzerland is mixed with Germany. Luxemburg is displayed with both of them, the one on the menu which is named "Carte OSM Suisse" (so Switzerland and Germany), and the one name "Carte OSM Andorre" (with France, Andorra, Belgium and Switzerland). A screen capture of the menu of my GPS (oregon 400T) is there : http://arvernes.dyndns.org/248.jpg The maps on the SD card are the following ones : -rwx------ 1 fm root 202973184 2009-05-23 08:35 auvergne.img* -rwx------ 1 fm root 90699776 2009-08-14 22:49 germany.img* -rwx------ 1 fm root 125825024 2009-08-17 07:01 france.img* -rwx------ 1 fm root 183808 2009-08-17 17:50 Andorre.img* -rwx------ 1 fm root 33868800 2009-08-17 17:50 Suisse.img* -rwx------ 1 fm root 3265024 2009-08-17 17:50 Luxembourg.img* -rwx------ 1 fm root 23499776 2009-08-17 17:51 Belgique.img* Maybe this has something to do with the way I use the mapname, description ?? parameters. Ideas are welcomed ;-) My script is too long to be posted here, more than 3000 lines, as I test lots of things, but if someone is interested about it, I can send it. I'm a newbie, and my test capabilities are really tiny ;-( Thank you. Francois --

4 5

Commit: r1137: Add ability to make GType directly from tags without any styling.
by svn commit 17 Aug '09

17 Aug '09

Version 1137 was commited by markb on 2009-08-17 21:29:03 +0100 (Mon, 17 Aug 2009) Add ability to make GType directly from tags without any styling. If mkgmap:gtype tag is present, its value is expected to be a comma separated list of the form: kind,code,minres,maxres,roadclass,roadspeed. Where kind is 1 for points, 2 for lines and 3 for areas. The first 3 values are required, the others are optional. Also, decodes ~[0x??] constructs in name strings to produce highway shields, etc.

1 0

scrambled roads in netherland
by Chris-Hein Lunkhusen 17 Aug '09

17 Aug '09

Houston, I have a problem with Holland..... Don't know why I have this problem with totaly scrambled roads mainly in Netherland, maybe because of the complexity of the AMD Import data? <http://img10.imageshack.us/img10/7121/hollande.png> Should I try to split into smaller tiles? For my recent map I used maxnodes=1.200.000. Chris

3 6

Re: [mkgmap-dev] R: Progressing patches
by Marco Certelli 17 Aug '09

17 Aug '09

--- Lun 17/8/09, Mark Burton <markb(a)ordern.com> ha scritto: > Da: Mark Burton <markb(a)ordern.com> > Oggetto: Re: [mkgmap-dev] R: Progressing patches > A: mkgmap-dev(a)lists.mkgmap.org.uk > Data: Lunedì 17 agosto 2009, 11:28 > > Hi Marco, > > > Hi Mark, I did not follow very well last discussions. > I agree in enabling remove-short-arcs by default, but with > no min length (i.e. min lenght=0). > > > > Could you please explain why arcs shorter than 5m > should be collapsed? > > Arc lengths appear to be encoded in units of 16 feet. That > is equal to > approx 4.8m. i.e. an arc that is less than 4.8m is encoded > as length 0. So if we want all arcs to have a non-zero > length, they > must be at least 4.8 metres, rounding up to an integer > gives 5m. Very strange about the 16 feet units. As far as I kew garmin utilizes MKSA And even if the 16feet units is true, maybe during the encoding a rouding is appied: - an arc <2.4m is encoded as zero 16feet units - between 2.5m and 7.6m is one 16feet units. - etc. At last, in my experience with mkgmap never had problems with --remove-short-arcs without min arc length (i.e. remove only zero length arcs) Ciao, Marco. > > Personally, I am not convinced that having zero length arcs > really > makes a difference. However, some people report that the > minimum length > needs to be greater than 0 otherwise routing is broken in > some places. > > Cheers, > > Mark > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

1 0

Progressing patches
by Mark Burton 17 Aug '09

17 Aug '09

I have 3 patches currently out for evaluation: mb-min-arc-length-v4.patch various tweaks related to short arcs including making remove-short-arcs enabled by default with a min arc length of 5m - could effect any map that has routing mb-extended-types-v2.patch Support the 3-byte marine/extended types - should (if not buggy) have no bad effects on maps that don't use those types. mb-zero-style-v3.patch allows styling to be done by external program - no effect on maps that don't use this feature Naturally, I believe them all to be completely sound and worthy of inclusion in mkgmap. Shall I commit them? or is more testing/discussion required? No hurry here, just seeing what people think. Cheers, Mark

3 4