November 2009 - mkgmap-dev - The mkgmap lists

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

mdr address index with gmapsupp and macroadtrip installers
by maning sambale 17 Nov '09

17 Nov '09

Last time I checked address search works via mapsource upload to GPS, is this working now for gmapsupp and gmapibuilder generated installer? -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

5 9

More Dog patches
by Du Plessis, Bennie 17 Nov '09

17 Nov '09

Hi, Unfortunately I miss-spelled "doc" in the previous eMail - suppose its done now :-( I don't know if any one besides Carlos has looked at my previous patches for DOC. I attach another patch for README., including some suggestions by Carlos. Since the previous patches was not installed yet, this patch replaces the previous patch Steve will you please commit this if it meets your approval, and ignore the previous? Previous message: Steve, Attached 2 patches for mkgmap-r1381\doc\ READMEjava.patch READMEinstalling.patch If you would be so kind to commit it? Please? BTW I see a heading like Index: doc/README.java on the patches of others. Is it hand edited in, or do you use different DiffUtils than I do? Should I include it as well? Further- do you prefer the patch text copied into the email body? Groete BennieD ##################################################################################### Scanned by MailMarshal - Marshal's comprehensive email content security solution. Download a free evaluation of MailMarshal at www.marshal.com #####################################################################################

3 5