December 2014 - mkgmap-dev - The mkgmap lists

Mapsource crashes while calculating a route
by Andrzej Popowski 29 Sep '16

29 Sep '16

Hi, I have observed crashes for some time. Mapsource 6.16.3 indicates a bug in module MPL_MAP.CPP. Basecamp reports an error or goes into infinite loop. Now I have extracted minimal source data, which creates faulty map. Removing any road or even a crossing point restore routing. Bug exist in mkgmap r2815, r2857, r2889, r2975 and r2976. Map created by mkgmap r2795 works correctly. I'm attaching here files to reproduce problem: mkgmap.bat - batch, which I have used to create the map, test-a.pbf - very simple OSM source data, route.gpx - short route, which causes a crash in Mapsource. -- Best regards, Andrzej

4 15

process-exits vs process-destination
by Franco Bez 08 Oct '15

08 Oct '15

Hi all, is there a way to combine the features process-exits and process-destination in a single style ? Based on my experience process-desitnation does a marvellous job when entering a motorway ( does it also work with also trunk roads ? ), while process-extis is perfect when leaving a motorway or trunk road. For instance the roundabout here http://www.openstreetmap.org/?lat=47.89665&lon=10.64805&zoom=17 has two exits towards the B12. Routing from the "Sudetenstraße" going North (maybe towards Augsburg) I would like the Garmin device to announce "5 th Exit - B12 (München)". On the other hand routing to the South (maybe Kempten) it should announce "2nd exit - B12 (Kempten)". Using process-exits this does not work, it's only "5th Exit - B12" resp. "2nd Exit - B12". I would have to use process-destination instead to get the desired messages displayed. Coming home from the trip, routing from the B12 towards "Sudetenstraße" I would like "exit to the right - Exit Kaufbeuren". Using process-exits this works perfectly. Would I use process-destination I would get "exit to the right towards B12 Verteilerring" or even "exit to the right towards Sudetenstraße" a really useless announcement as the sign on the trunk road reads "Kaufbeuren / Neugablonz / Mauerstetten". So this is why I would like to have an option that combines the functionality of process-exits and process-destination. Do you see any way to achieve this in one single style ? Ciao, Franco

7 6

Why is there a code-page in the .typ-file? And - is there a code-page a gmapsupp.img?
by Felix Hartmann 20 Mar '15

20 Mar '15

Hi Everyone 1. Switching to unicode I ask myself If I should also change the typ-file to code-page=65001 - is this only for the case that you want to label a line/poi/polygon using unicode characters - or should any .typ-file that is "bundled" by a unicode map, also be unicode? Does anyone know a garmin unicode map that has a .typ-file? 2. I couldn't notice any change on compiling a gmapsupp.img regarding a code-page set. Is there actually a code-page for a gmapsupp.img? Especially regarding address index. Or is the code-page only for the map.img files themselves? Felix -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

4 5

Re: [mkgmap-dev] elevation data
by Mike Baggaley 19 Jan '15

19 Jan '15

Hi Andrzej, Thanks for the quick response. As it happens, I already had the show-profiles option in my configuration, but I was using just a gmapsupp.img file and I have now realised that the elevation data is available if I use the separate tile files and set the registry to install the map. Is there any way to get that data included in a gmapsupp.img file, or an extra file to distribute with a gmapsupp.img file? I'm trying to avoid having to use both the combined img file and all the components as well. Cheers, Mike

12 30

random housenumbers
by Gerd Petermann 09 Jan '15

09 Jan '15

Hi Steve, how can I make sure that Garmin programs do not try to interpolate housenumbers for places where this is not wanted? Is it possible that there is another attribute besides ODD,EVEN,BOTH ? Gerd

2 7

Issues with barrier=*
by Helge Olav Helgesen 31 Dec '14

31 Dec '14

Hi I am using the latest mkgmap (and have tried some older versions as well). What I see is that barrier=* tags with either motor_vehicle=no or motorcar=no still creates a route through the barrier. I noticed this when my GPS sent me through this node: https://www.openstreetmap.org/node/1276408049 My GPS is a Nüvi 3597 with the latest software from Garmin. I am using mkgmap with the default style. I have also tried to work with the default style from the extras folder. I added a handler for motor_vehicle as it was not there from before. (Added to the points file: barrier=* & motor_vehicle=* { set mkgmap:car='${motor_vehicle|subst:private=>no}' }) Not sure how to solve this, any ideas? ... Helge

3 8

A few thoughts on non-rectangular tiles
by Steve Ratcliffe 29 Dec '14

29 Dec '14

Hi Here are a few thoughts on non-rectangular tiles. The main problem is knowing where to start really. The Files --------- I looked into this a few years ago and I don't think that there is anything fundamentally different about producing non-rectangular tiles. It is normal to split tiles at land based country borders, so that the tile follows the border exactly. For countries separated by sea, such as Sweden and Finland straight lines can often be used without regard to the alignment that we currently use. - You just create a tile with an arbitrary shape, the background polygon if any follows the shape. - The TRE section still records the bounding box of the tile. - the TDB file still contains those rectangular bounding boxes and so they will, in general, overlap. - You add add the actual shape of the tile as a 'map selection area' to the overview map. So we need to allow an arbitrary polygon as background in mkgmap. Splitting --------- The majority of tiles would remain rectangular as they at present. Tiles that would contain a land border need to be further split along that border. This could be done 1. Directly by splitter 2. By running mkgmap once for each country. 3. Some intermediate process. I believe it would be best in the long term for splitter to make the split, but perhaps the other strategies could be used temporarily in order to concentrate on other parts of the process. I think that the bounds file (or some similar purpose built file) should be used. There is no need to split along coastal boundaries. Only if a tile would reach to another country does it need to be split. When splitter creates the tiles, the actual boundary of a tile needs to be communicated to mkgmap in some way. Implementation -------------- Currently we have restrictions on the alignment of tile boundaries, these can all go, as this is a constraint to make things easier for us and not a feature of the format. There will probably be a few things to fix up so that the tiles still meet and route without gaps. I would suggest starting out with one tile cut in two with a sloping line. If we can get that to work without routing problems or visible gaps across all zoom levels, then most of the problems should be sorted out before putting in the work to support completely arbitrary boundaries. Then we add a more complex background polygon. ..Steve

6 9

elevation data
by Mike Baggaley 29 Dec '14

29 Dec '14

Hi, I've built a map containing contour data, using line styles 0x21 and 0x22. These are displayed in BaseCamp with the correct elevations. However, if I open a route and try to display the Graph tab, it says, "The current map does not contain any elevation data on the selected route(s)." The route crosses contour lines, so I surmise that the map needs further information. Can anyone tell me what I need to do? Thanks, Mike

2 1

Small improvements for house numbers
by Gerd Petermann 24 Dec '14

24 Dec '14

Hi all, the corrections in r3392 improves the house number code. In some cases a house number was added to the wrong part of a road, sometimes even the wrong side. Possible effect: When you search for a specific number in a street in a specific town in some cases, MapSource shows multiple possible places. Besides wrong OSM data there are many other possible reasons for that, I fixed only one of them until now. The rest is work in progress... Gerd

1 0

Commit: r3392: HousenumberGenerator: use same correction as in r3391 for Coord.shortestDistToLineSegment
by svn commit 24 Dec '14

24 Dec '14

Version mkgmap-r3392 was committed by gerd on Wed, 24 Dec 2014 HousenumberGenerator: use same correction as in r3391 for Coord.shortestDistToLineSegment Effect of the error: Some house numbers were added to the wrong sides of the street or a wrong part. E.g. when the road contains a 90 degree turn

1 0