August 2015 - mkgmap-dev - The mkgmap lists

question about ignored no_u_turn restriction
by Ben Konrath 22 Aug '15

22 Aug '15

Hi everybody, I recently noticed a bunch of warning messages about ignored no_u_turn restrictions. Here's an example: 2015/07/04 18:12:50 WARNING (RestrictionRelation): 17244023.o5m: Turn restriction (no_u_turn) http://www.openstreetmap.org/relation/4630872 (at http://www.openstreetmap.org/?mlat=41.890540&mlon=-87.805101&zoom=17) no_u_turn with equal 'from' and 'to' way and via node is ignored Looking at the rules for restrictions and the relation itself, I can't see what the problem is. https://wiki.openstreetmap.org/wiki/Relation:restriction http://www.openstreetmap.org/relation/4630872 Does anybody know why this particular restriction is being ignored? Thanks, Ben

5 15

sharp angles and routing
by Gerd Petermann 22 Aug '15

22 Aug '15

Hi Felix, please check: you said that sharp angles also have an effect on pedestrian routing, I was not able to reproduce that. Can you give an example? Gerd

3 8

Warnings about correct ways produced by --check-roundabout-flares
by Carlos Dávila 21 Aug '15

21 Aug '15

Option --check-roundabout-flares produces a lot of warnings about ways that are correct IMHO, like the following examples: (RouteNode): 55114001.o5m: Incoming roundabout flare road (http://www.openstreetmap.org/browse/way/22974731) points in wrong direction? http://www.openstreetmap.org/?mlat=39.476332&mlon=-6.340242&zoom=17 (RouteNode): 55114002.o5m: Outgoing roundabout flare road (http://www.openstreetmap.org/browse/way/53537671) does not finish at flare? http://www.openstreetmap.org/?mlat=36.471647&mlon=-6.207968&zoom=17 (RouteNode): 55114001.o5m: Incoming roundabout flare road (http://www.openstreetmap.org/browse/way/183666800) points in wrong direction? http://www.openstreetmap.org/?mlat=40.026175&mlon=-6.096136&zoom=17 (RouteNode): 55114001.o5m: Outgoing roundabout flare road (http://www.openstreetmap.org/browse/way/55608338) points in wrong direction? http://www.openstreetmap.org/?mlat=39.430758&mlon=-6.365738&zoom=17 (RouteNode): 55114002.o5m: Outgoing roundabout flare road (http://www.openstreetmap.org/browse/way/226321374) points in wrong direction? http://www.openstreetmap.org/?mlat=37.234124&mlon=-7.250831&zoom=17 Code for this check was written long ago now and perhaps could be improved some way to avoid such noise. I can supply more examples if needed, my log is full of them.

2 4

Wierd routing problem
by John Aldridge 19 Aug '15

19 Aug '15

I'm having a weird routing problem! I'm using CreateIMG (which uses mkgmap to do the work) to create a Garmin compatible map of the UK. I've installed this map into BaseCamp, and I'm trying to create a route. There's a point on a local minor road which BaseCamp refuses to route through *unless* the route options permit the use of 'Interstates'! There is no node in OpenStreetMap at this point, although BaseCamp, displaying the map I've created, does show a black dot at the point in question. I don't know what this black dot signifies. The problem point is at the centre of http://www.openstreetmap.org/#map=16/52.1631/0.2473 and the BaseCamp view of this area is http://www.jjdash.myzen.co.uk/temp/routeproblem.png This problem has only recently started happening, though I both have updated BaseCamp and built a new map from current data, and don't know which of these might be responsible. I am using a slightly customised set of stylesheets, but these have not changed since the last time this worked properly. I also know CreateIMG uses rather an old version of mkgmap, but again this has not changed. Any ideas? Or is there a better place to ask for help? Thanks in advance! -- Cheers, John

4 8

Numbering loss in the version which came after the r3602
by Alexandre Loss 19 Aug '15

19 Aug '15

Hi Gerd, Since yesterday we (a group that compiles maps in Brazil) begin to see some loss of numbers in some of our maps. As we had never had this problem before, I suspected that the error could have been introduced in some recent version of mkgmap. So, I restored some old releases for testing and I found that the numbering were generated correctly until release 3602 as seen in the image below in the white-box ("390 Rua Porto Alegre"): *Snapshot taken form MapSource of a map compiled wiht mkgmap r3602* [image: Imagem inline 1] Using the same source osm file, the numbering is lost in the street "Rua Porto Alegre" (for example), if the map is compiled with any newer release of mkgmap than 3602. The snapshot bellow was taken from a map compiled with release 3616:: *Snapshot taken form MapSource of a map compiled wiht mkgmap r3616:* [image: Imagem inline 2] These compiled maps img are available for tests at the file sharing area: http://files.mkgmap.org.uk/download/270/03205200_r3602.img http://files.mkgmap.org.uk/download/271/03205200_r3616.img You can search for street "Rua Porto Alegre" to see the problem, but it problem can be found in other places too. My guess is that the problem arose when housenumber2 brahch was merged to trunk. If you need more information, please let me know. Thank you. Regards, Alexandre

5 13

road construction
by Steve Sgalowski 19 Aug '15

19 Aug '15

with road construction can there be many road speeds , e.g. 40, 60, 20 ,80 and 50, 70 ( kph) but still with the same classification as construction . or could this also be the same for un paved roads . stephen

1 0

Commit: r3631: apply road-speed-class-v1.patch :
by svn commit 19 Aug '15

19 Aug '15

Version mkgmap-r3631 was committed by gerd on Wed, 19 Aug 2015 apply road-speed-class-v1.patch : the patch changes mkgmap so that it evaluates the tags mkgmap:road-class-min and mkgmap:road-class-max also when mkgmap:road-class!=* Simillarly the tags mkgmap:road-speed-min and mkgmap:road-speed-max are also evaluated when mkgmap:road-speed!=* This allows to revert the change in r3628

1 0

bicycle=use_sidepath
by Gerd Petermann 18 Aug '15

18 Aug '15

Hi all, while looking at the sharp angles problem I noticed that the default style ignores the tag bicycle=use_sidepath. Shouldn't we interpret this like bicycle=no? Gerd

7 14

Commit: r3630: housenumbers: improve matching of addr:street and highway names
by svn commit 18 Aug '15

18 Aug '15

Version mkgmap-r3630 was committed by gerd on Tue, 18 Aug 2015 housenumbers: improve matching of addr:street and highway names Accept different capitalisation of the road name when trying to find a match.

1 0

addr:street and street name matching for house number searchs
by Carlos Dávila 18 Aug '15

18 Aug '15

HousenumberRoad throws a warning when addr:street from a node and name of the street the node is next to are not equal, even if they differ only in the capitalization. See for example nodes http://www.openstreetmap.org/node/2486105470 and http://www.openstreetmap.org/node/2486105464 (addr:street=carrer del Montseny) which are next to way http://www.openstreetmap.org/way/8590864 with name=Carrer del Montseny. One of the names is more correct than the other but, having in mind that Garmin changes capitalization arbitrarily, I'm not sure if we should keep these warnings. Another case to discuss is when one of addr:street or way name contains special letters and the other one not (eg. Asturies vs Astúries). Here one of the names is wrongly written and should be corrected in OSM data, so may be worth keeping the warning.

3 6