January 2012 - mkgmap-dev - The mkgmap lists

a few more typ compiler problems
by n Willink 08 Jan '12

08 Jan '12

Great! True color pois are now rendered correctly except for colormode=32 However,I've come across a few more blemishes. (http://www.pinns.co.uk/osm/txt2typ.zip) 1) topo1.txt : all 'place' pois get type number 0x0000 2) topo2.txt : java issues http://www.pinns.co.uk/osm/txt2typ.zip the above errors occur with other txt files as well 3) font: normal is still not accepted, it seems. -- View this message in context: http://gis.638310.n2.nabble.com/a-few-more-typ-compiler-problems-tp7132907p… Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 9

Commit: r2165: Fix typ filename for nsis file when using --output-dir.
by svn commit 08 Jan '12

08 Jan '12

Version 2165 was commited by steve on 2012-01-08 21:09:55 +0000 (Sun, 08 Jan 2012) Fix typ filename for nsis file when using --output-dir.

1 0

Commit: r2162: If the global address index option is given alongside the --gmapsupp
by svn commit 08 Jan '12

08 Jan '12

Version 2162 was commited by steve on 2012-01-06 16:58:50 +0000 (Fri, 06 Jan 2012) If the global address index option is given alongside the --gmapsupp option, then the index will be created directly within the gmapsupp.img file, so that address search will work on devices without having to install via MapSource. If in addition the tdbfile option is given, then the existing MapSource style index will also be created. This will take about twice the amount of memory, so it best to avoid doing this.

5 4

[splitter patch] limit description length to 50 characters
by Ben Konrath 08 Jan '12

08 Jan '12

I use this patch when building maps of Canada using the --geonames-file=CA.zip option. Sometimes the length of the description will be longer than 50 characters and mkgmap complains. - Ben -- http://www.linkedin.com/in/benkonrath

2 1

question on compile errors
by steve sgalowski 07 Jan '12

07 Jan '12

i have downloaded the australia-oceania.osm from http://download.geofabrik.de/osm/ but when i split it is ok but re combine is not split the osm data file start /low /b /wait java -enableassertions -Xmx600m -jar ..\bin\splitter.jar --mapid=66%FID%001 --max-nodes=800000 --overlap=2000 ..\OSM-Data\%osmfile% gmasupp.img combine start /low /b /wait java -enableassertions -Xmx1100m -jar ..\bin\mkgmap.jar --max-jobs=1 --code-page=1252 --levels=0:24,1:22,2:20,3:18,4:16,5:14 --make-poi-index --country-name="%country%" --latin1 --family-id=%FID% --mapname=66%FID%001 --overview-mapname=66%FID%000 --tdbfile --index --add-pois-to-areas --series-name="OSM-%country%" --family-name="OpenStreetMap: %country%" --road-name-pois --route --remove-short-arcs --preserve-element-order --style-file=..\bin\resources\styles\ --style=%style% --description="%country%" --gmapsupp -c template.args error msgs are severe poly line errors Stephen

2 2

Question reg. LocationHook and incomplete data
by GerdP 07 Jan '12

07 Jan '12

Hi, the current implementation of LocationHook is somehow unpredictable when data in precompiled boundaries is incomplete. Assume we have two different elements e1 and e2, and both don't have the mkgmap:postcode tag set at the time that currentLevel is set to something like mkgmap:admin_level=11. Assume e1 has all other wanted tags, but e2 is also still missing e.g. mkgmap:admin_level=4. The element e1 will be removed from the quadtree because it is considered to be fully worked out, but e2 is kept. Later, e2 may get the value for the mkgmap:postcode tag from a boundary which itself doesn't have the value, but that "lies in" a boundary which contains a value. If e1 was not removed from the quadtree, it might also have gotten the mkgmap:postcode tag set to a value from such a boundary. I am not sure, maybe I've introduced the problem with one of my patches. Anyhow, the question is: What do we want to have? Should e1 get the mkgmap:postcode tag , or should e2 not get it? Ciao, Gerd -- View this message in context: http://gis.638310.n2.nabble.com/Question-reg-LocationHook-and-incomplete-da… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 1

Loading a relation of numerous unconnected sections to my GPSr
by Bob Hawkins 07 Jan '12

07 Jan '12

I am walking parts of The Chiltern Way and, as I progress, adding members in JOSM to relation 23309. I should like to view this relation as a tracklog on my Legend HCx so that I can more easily fill in the missing parts. I cannot combine the ways in JOSM because there are numerous breaks. I can create a .gpx file but the sections are too numerous to transfer from Garmin MapSource or BaseCamp to my Legend. Ideally, I should like to combine the sections into one record, which I can do with my MapInfo software and, I daresay, QGIS (although I do not know how to do it in that particular software). However, it seems that once combined, the resulting record is not recognised as a polyline for me to be able export it as a .gpx file. I wonder if anyone can suggest a method that would get such a relation into internal memory on my Legend? I am not sure where to post this question. so I shall place it on the JOSM development list, too.

2 2

Highwayhooks.java
by Chris66 07 Jan '12

07 Jan '12

Hi, If a synthesised cycleway is added, some tags are also added like bicycle=yes, foot=no. But while "bicycle" is added to the used-tags-list, "foot" is not added. Is this intended ? Greetings, Chris

2 1

Commit: r2164: Instead of copying use the first area directly while loading precompiled bounds
by svn commit 06 Jan '12

06 Jan '12

Version 2164 was commited by wanmil on 2012-01-06 21:56:17 +0000 (Fri, 06 Jan 2012) Instead of copying use the first area directly while loading precompiled bounds The first area of any boundary loaded from the bounds file is now directly used instead of copied. This saves a lot of Area object creations although the performance improvement is hardly measurable.

1 0

Commit: r2163: Remove elements that would not pass the style processing
by svn commit 06 Jan '12

06 Jan '12

Version 2163 was commited by wanmil on 2012-01-06 20:11:27 +0000 (Fri, 06 Jan 2012) Remove elements that would not pass the style processing The new UnusedElementsRemoverHook removes all elements (nodes, ways and polygons) that lie outside the tile bounding box. These elements might have been required for the multipolygon processing. But after that they can be safely removed to save processing time and memory.

1 0