November 2010 - mkgmap-dev - The mkgmap lists

2 pois for a single polygon/multipolygon
by maning sambale 23 Nov '10

23 Nov '10

This way is tagged as a amenity=townhall and a multipolygon relation: http://www.openstreetmap.org/browse/way/24159829 http://www.openstreetmap.org/browse/relation/452620 In my style: polygons: building=* | man_made=* | amenity=* | tourism=* [0x13 resolution 24] and in the points: amenity=townhall [0x3003 resolution 21] building=* [0x6402 resolution 24] I have the add-pois-areas switch enabled This resulted to two POI icons (the little PH flag) in garmin http://farm2.static.flickr.com/1290/5184379090_bbeeeaffc8_b.jpg -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

7 15

actual splitter branch
by h.scholland＠googlemail.com 22 Nov '10

22 Nov '10

Hi, I would like to use new binary-format with mkgmap splitter, but I've no idea how to build a jar-file from branch. In makgmap-dev I read that you have build it successfully. Would it be possible, that you send me a working splitter.jar with binary support? You can email it to h.scholland(a)googlemail.com Greets aighes

6 11

Flood blocker
by WanMil 21 Nov '10

21 Nov '10

I have committed a first version of a flood blocker to the coast branch. The blocker is quite simple and works only for multipolygon sea generation. At the moment it removes sea polygons that contains one or more highways. Please give it a try and let me know about your experiences. (Don't expect too much :-) Have fun! WanMil

7 9

mkgmap and threads
by WanMil 21 Nov '10

21 Nov '10

I have observed that typically mkgmap does not use more that 2 threads. If the max-jobs parameter is set to a greater value than 2 the surplus threads are blocked in the MapMaker.loadFromFile. There is a note in the MapMaker source code: // work around non-reentrancy of GType priority stuff // by serialising the map reading Is there any chance to remove this synchronization to get a gain of more threads? What has to be done to remove the synchronization in the MapMaker class? WanMil

2 2

Commit: r1733: Remove synchronisation around loading routine.
by svn commit 21 Nov '10

21 Nov '10

Version 1733 was commited by steve on 2010-11-21 13:11:08 +0000 (Sun, 21 Nov 2010) Remove synchronisation around loading routine.

1 0

!< not working -- problem with conditions in style-file.
by Felix Hartmann 19 Nov '10

19 Nov '10

There is a problem in the style handling. "!<" is not working. Assume I would like to reverse the statement layer<0 into meaning layer < 0 does not exist. Currently I could write layer!=-1 & layer!=-2 and so on. But that sums up to quite a lot of text. Essentially I would like to have the following statement shorter...: & ( tracktype!=1 | tracktype!=2 | tracktype!=3 | tracktype!=4 | tracktypeadded=yes ) but replacing it with & (tracktype!<5 | tracktypeadded=yes ) does not yield the same outcome. Have I got a logical problem, or is it mkgmap?

5 10

Some options from -c not applied
by Carlos Dávila 18 Nov '10

18 Nov '10

I'm using the args file attached below with -c option, having two problems: 1: area name in the resulting map is Morocco for all tiles (MapSource). 2: SPAIN-18.TYP is correctly applied to Spain tiles, but MOROC-19.TYP is not applied to Morroco's map. Do you know what I'm doing wrong? Isn't it possible to use two different TYP files in the same mkgmap run? family-id=18 product-id=1 family-name=OpenStreetMap España country-name=ESPAÑA country-abbr=ESP area-name=España latin1 code-page=1252 mapname: 63240001 description: ES-Madrid input-file: ../mapas/ultimo-n/63240001.osm.gz mapname: 63240002 description: ES-Valladolid input-file: ../mapas/ultimo-n/63240002.osm.gz mapname: 63240003 description: ES-Valencia input-file: ../mapas/ultimo-n/63240003.osm.gz mapname: 63240004 description: ES-Sevilla input-file: ../mapas/ultimo-n/63240004.osm.gz mapname: 63240005 description: ES-Barcelona input-file: ../mapas/ultimo-n/63240005.osm.gz mapname: 63240006 description: ES-Santander input-file: ../mapas/ultimo-n/63240006.osm.gz mapname: 63240007 description: ES-Zaragoza input-file: ../mapas/ultimo-n/63240007.osm.gz mapname: 63240008 description: ES-Vigo input-file: ../mapas/ultimo-n/63240008.osm.gz input-file: typ/SPAIN-18.TYP name-tag-list=int_name,name lower-case charset=windows-1256 code-page=1256 family-id=19 product-id=1 family-name=OpenStreetMap Morocco country-name=Morocco country-abbr=MAR area-name=Morocco mapname: 63240009 description: MA-Rabat input-file: morocco.osm input-file: typ/MOROC-19.TYP

2 2

Sea generation
by WanMil 18 Nov '10

18 Nov '10

Hi all, I have started to rework the sea generation code. There have been several reports of problems with flooded tiles in the last weeks so I think it is neccessary to improve some parts of it. The first thing I've started is to implement a flooded tile blocker. The algorithm has been discussed a while ago on this list. It uses a quadtree implementation which is able to return all points contained by a polygon. The quadtree is filled with all highway points. If a sea polygon contains too many points that belong to highways something is wrong and the sea polygon is discarded. That's the idea... Let's see how it works. The quadtree might also be used to correct wrong sea polygons. But that's one of the further steps. Do you have any other ideas how to improve the sea generation and how to make it more failsafe? Then please let me know. Have fun! WanMil

11 36

TYP file for default mgkmap
by Minko 15 Nov '10

15 Nov '10

I wonder if anyone has a TYP file available for the default mkgmap styles. If i download the world osm routbale map from Lambertus' site at http://garmin.na1400.info/routable.php the colours and symbols in Mapsource are not displayed very well (horizontal brown stripes representing forest, yuck!) I know this could be represented a lot better with a simple TYP file (Garmin uses nowadays also Typ files for the city navigator etc) and since the routable garmin osm maps will be of the killer apps of the osm community is there a TYP file out there that could be implemented in the standard mkgmap? To give an example, I put two images on http://sites.google.com/site/openfietsmap/osm-1 The first one is the default mkgmap of a region in the Netherlands, the second one my openfietsmap with a modified mkgmap style and TYP file. On osm there are more such styles, like the mapnik version which look very pretty: http://wiki.openstreetmap.org/wiki/User:Petrovsk/FR:My_Garmin_map_styles http://blog.lionelmaraval.fr/post/2010/01/23/Carte-pseudo-mapnik-pour-Garmin So any ideas to improve the layout of the mkgmap styles with a typ file would be recommended. Cheers, Minko

1 1

combining two img covering other polygon below
by maning sambale 13 Nov '10

13 Nov '10

Hi, I am converting selected contour lines as a polygon. The contour polys are in a separate osm file. Compiling with the following commands: java -Xmx1512m -jar mkgmap.jar --read-config=args.list philippines.osm contour.osm args.list below: code-page=1252 ea tdbfile latin1 country-abbr=PHI country-name=PHILIPPINES remove-short-arcs=5 route road-name-pois add-pois-to-areas family-id=639 family-name=OSM_PHIL overview-mapname=40000001 series-name=OSM_PHIL description=OSM_PHIL style-file=/home/maning/Downloads/osm/routable_garmin/svn/styles/osm-ph generate-sea=polygons,extend-sea-sectors,close-gaps=1000 index adjust-turn-headings check-roundabout drive-on-right check-roundabout-flares report-dead-ends transparent The problem, all other polygons and lines are "under" the contour polys including the boundingbox of the test contour map. POIS and labels are visible. See image here: http://farm2.static.flickr.com/1390/5166129071_b804c4622e_b.jpg Any advice? -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

2 3