- mkgmap-dev - The mkgmap lists

Missing bicycle turn directions
by Marko Mäkelä 22 Nov '09

22 Nov '09

I did not get two turn instructions on my latest bicycle ride. Luckily, it was a familiar route and I was paying attention to the map, not keying in the ref= of a bus stop or something. The first occurrence was when I was approaching http://www.openstreetmap.org/browse/way/5053613/history from north. (It was version 3; I tried to make the angle a little steeper in version 4. For what it is worth, I built the map with mkgmap --adjust-turn-headings.) The second occurrence was a T crossing at the north end of http://www.openstreetmap.org/browse/way/34137262/history (I did not move the north node in the last revision.) I was supposed to turn left at the end of the way, but I did not receive any instructions. Could adjust-turn-headings be straightening the line too much? Or should I move the curve of http://www.openstreetmap.org/browse/way/23098405 a little bit to the west to improve the routing instructions? Best regards, Marko

2 2

Routing issue
by Nakor 22 Nov '09

22 Nov '09

Hello, I have spotted a routing issue with a mkgmap generated map. I was able to reproduce it in several versions: 1188, 1228 and 1265. The source file is the Cloudmade Michigan file (Sep 30), that I split using splitter. I can reproduce the issue either using the whole Michigan state (5 tiles) or just the tile where it happens. The tile were it happens has the following bounding box: 44.472656,-87.890625 to 47.548828,-83.144531 You can look at the following map: http://maps.cloudmade.com/?layers=&lat=46.115967&lng=-85.494747&zoom=13&dir… If I try to route from A to B, either on MapSource or on my etrex Vista, I get a line from A to D and a line from D to C If I try to route from A to C (or west of C), MapSource shows an error and the GPS can route but stille displays A-D-B lines. If you try either route (A to B or A to C) in Cloudmade, they work fine. I can provide the osm data (22 Mb gzipped) if needed. Thanks, N.

4 15

Continue patch not working on two routable roads.
by Felix Hartmann 21 Nov '09

21 Nov '09

In general the continue patch works great. However the continue patch does not seems to drop stuff if mkgmap later on thinks it is identical?? After messing for 3 hours now trying to find out why some actions don't work I have found out that mkgmap does not enact the "continue" action, in case it thinks that the result is identical - or the tags are identical. OR if there is a difference in the routing attributes (or oneway). So currently it is not possible to put two oneway streets counterfacing via continue command, nor two identical ways with different routing speed. So lets start easy: *The following also does not work * highway=* [0x01 road_class=0 road_speed=1 resolution 20 continue] highway=* [0x01 road_class=0 road_speed=1 resolution 24] highway=* [0x01 road_class=0 road_speed=1 resolution 24] *While the following works without probs:* highway=* [0x02 road_class=0 road_speed=1 resolution 20 continue] highway=path [0x01 road_class=0 road_speed=1 resolution 24] highway=path [0x01 road_class=0 road_speed=1 resolution 24] *The following example simply does not work:* highway=* & incline=down {set oneway=yes; set copy=98} highway=* & incline=up {set oneway=-1; set copy=99} highway=* & incline<0 {set oneway=yes; set copy=98} highway=* & incline>0 {set oneway=-1; set copy=99} highway=* & copy=* [0x16 *road_class=4 road_speed=3* resolution 20 continue] highway=* & copy=99 {set oneway=yes} [0x01 road_class=0 road_speed=1 resolution 24] highway=* & copy=98 {set oneway=-1} [0x01 road_class=0 road_speed=1 resolution 24] *- here 0x16 only is output. The following example will work however:* highway=* & incline=down {set oneway=yes; set copy=98} highway=* & incline=up {set oneway=-1; set copy=99} highway=* & incline<0 {set oneway=yes; set copy=98} highway=* & incline>0 {set oneway=-1; set copy=99} highway=* & copy=* [0x16 continue resolution 20] highway=* & copy=99 {set oneway=yes} [0x01 road_class=0 road_speed=1 resolution 24] highway=* & copy=98 {set oneway=-1} [0x01 road_class=0 road_speed=1 resolution 24]

2 2

Bug with background Polygon
by Felix Hartmann 20 Nov '09

20 Nov '09

When creating maps from mp format, I think that mkgmap adds duplicate 0x4b background polygon. (if I create a map with mkgmap, then open the .img with mapedit and save as mp, and recreate with mkgmap, it has two times background polygon set). - according to Popej, the author from gmaptool, it should even be possible to create maps without background polygon at all.

4 7

Setting map name when seen in eTrex Vista
by Peter & Suzie 20 Nov '09

20 Nov '09

I have created 2 sets of maps and when I load them into the GPS they both have the name in the menu to hide show a map set, see menu.bmp When I go to individual maps I can see the correct names, see bike & car.bmp I have tried every option on mkgmap but this never changes, any one know where the name is set? Peter...

2 2

Commit: r1400: Change MIN_SIZE to 1 as this fills some gaps in lines when zoomed out.
by svn commit 19 Nov '09

19 Nov '09

Version 1400 was commited by markb on 2009-11-19 10:35:26 +0000 (Thu, 19 Nov 2009) Change MIN_SIZE to 1 as this fills some gaps in lines when zoomed out.

1 0

Commit: r1399: Provide a means to omit ways from the dend-end-check.
by svn commit 19 Nov '09

19 Nov '09

Version 1399 was commited by markb on 2009-11-19 10:35:22 +0000 (Thu, 19 Nov 2009) Provide a means to omit ways from the dend-end-check. To exclude a way from the dead end check tag it with mkgmap:dead-end-check = no For example, a lot of service roads are tagged oneway but they don't join up with other roads. By adding this tag, they can be excluded from the dead end check.

1 0

[PATCH v1] - round coordinates when zoomed out
by Mark Burton 18 Nov '09

18 Nov '09

Having filled some gaps with that last little patch, I was wondering why I still had quite a few gaps when zoomed out. Obviously, the coords weren't being rounded to nearest given the zoom level. So, the attached patch does that rounding and, lo and behold, even more gaps have disappeared. Please give it a go, especially for maps that cross the equator/day line where the coords flip signs. Sure to be buggy but it's looking quite promising. BTW - this patch does not contain the last patch but they probably should be used together. Mark

3 6

Naming cycleways or footways by the adjacent highway
by Marko Mäkelä 18 Nov '09

18 Nov '09

To make turn directions easier to read, I begun adding name, name:fi, name:sv to cycleways that are running adjacent to ways for motor vehicles. In this way, I will see the road names instead of "Track". Today I got some objection for that and a suggestion to introduce a tag for the "fake" cycleway names. I have to agree with the objection. Some cycleways do carry genuine names, and with my constructive tagging, it will be harder to distinguish genuinely named cycleways from ones that merely run along a way. Furthermore, some cycleway=track that are adjacent to a major road can be separated by tens of meters of natural=wood near multi-layer junctions. It would feel wrong to see these cycleways tagged with the ref or name of adjacent way (say, E75 or M1 or A1) in the SlippyMap view. Is there any "standard" tag for such "fake" cycleway names? Theoretically, the most appealing approach would be to group all OSM ways (lanes) that belong to a physical highway in a relation. Alas, based on what I have seen when fixing roundabouts, relations tend to get broken over time. Could we invent a new name tag for this? User alv proposed name:isnextto, but I find that it could be confused with a language code such as name:en. Perhaps way_name and way_ref? Any ideas? Best regards, Marko

2 3

Could not create gmapsupp file
by Marko Mäkelä 17 Nov '09

17 Nov '09

Hi, I am resending this with a more appropriate subject line. Why is mkgmap --gmapsupp failing at the end if a corrupted gmapsupp.img exists in the working directory? Marko ----- Forwarded message from Marko Mäkelä <marko.makela(a)iki.fi> ----- Date: Mon, 16 Nov 2009 10:29:55 +0200 From: Marko Mäkelä <marko.makela(a)iki.fi> To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Line/Polygon outside of the map area Hi Mark, > At this time, the only way to avoid the warnings is to comment out the > line in the source code that's producing them! I see that you disabled it in a later commit. My laptop's power supply failed, and I had to migrate to an older laptop, which my wife is using. (So, I will have to cut back my mapping activities for a couple of weeks, because I cannot use a computer during evenings.) Because copying the files was no fun at USB 1.1 speed, I kept interrupting the rsync process and adding --exclude parameters. This left my map translation directory with an incomplete gmapsupp.img file. To my great surprise, mkgmap reported "Could not create gmapsupp file" at the very end of the run. I tried several revisions, and all failed in the same way. In the end, I removed the offending gmapsupp.img and reran mkgmap successfully. > It's all to do with how polygons (and lines) are split when they extend > across multiple subdivisions in the map. Now it may be that the test > that is producing the error message can be removed and those polygons > that it thinks are outside of the map area can continue to be processed > like they were before I put the test in. In fact, you could try that > and see if any other messages appear. So if you go to line 121 of > MapArea.java and make the test in the if statement true then those > messages would go away and I would be interested to learn if you get > any other messages instead. I might do that later, when I get my own laptop back. The substitute is much slower, because it is several years older. Best regards, Marko

1 0