November 2013 - mkgmap-dev - The mkgmap lists

free Garmin OSM map
by Minko 28 Nov '13

28 Nov '13

FYI: Garmin has published a free Wintersport map (Alpes) based on OSM data: See http://www.garmin.com/de/mit-garmin-im-schnee#scrolltowinterkarte It contains shaded relief and contour lines and is not routable.

4 4

IO-problem with actual trunk
by Henning Scholland 24 Nov '13

24 Nov '13

Hi, while generating a map of Oman I got the attached error-message (see below 1010). The map is generated out of planet.o5m. Henning

3 14

Possible solution for deformed polygons
by GerdP 24 Nov '13

24 Nov '13

Hi all, at the end of 2012 we discussed "Polygons deformed", see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q4/016010.html As already mentioned the rounding to map units can cause extreme errors in angles for points which are very close together. This is often the case in buildings, and also the angles in buildings are often right angles (90°), so errors are very obvious. I think I have a possible improvement for it: 1) merge polygons with equal types etc. like in merge-lines algo, so that e.g. buildings that share walls are combined to one polygon (without creating holes). See e.g. http://www.openstreetmap.org/browse/way/118911628 Merging allows to merge many building polygons to one, this makes it less likely that two points are close. 2) Detect and remove wrong angles with an algo similar to that used in r2829 to remove wrong angles in roads. I see two advantages: a) img files which are a bit closer to OSM data b) smaller img files (because of the merging) I see one small possible problem: The size filter might not remove merged polygons. Do you see other problems? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp57… Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 9

Address index for multi-country map
by Bernhard Hiller 24 Nov '13

24 Nov '13

I try to build a map of Germany, Switzerland, Austria and Czech Republic with a functional address index. I downloaded the Geofabrik extracts for those countries, combined them (after conversion to o5m format) with osmconvert, split them, and create the map. The result is quite mixed: some places show up below "Country" instead of Germany, e.g. - Addresses - Spell Country: Country - Spell City: Krummennaab - Enter Street Name: (stopped here, works) whilst - Addresses - Spell Country: Deutschland - Spell City: Krummennaab - No Results found Some places show up below "Deutschland", but (almost) no road is available: - Addresses - Spell Country: Deutschland - Spell City: Erlangen - Enter Street Name: (blank) - only "Buckenhofer Weg" available of a town with more than 100000 inhabitants... whilst - Addresses - Spell Country: Country - Spell City: Erlangen - Enter Street Name: (blank) - lists many roads of the town Near my home in Bayreuth is "Geseeser Weg". I choose that example because that street name does not exist so often. - Addresses - Spell Country: Country - Spell City: (Search All) - Enter Street Name: Geseeser - No Results found but - Addresses - Spell Country: Deutschland - Spell City: (Search All) - Enter Strret Name: Geseeser - lists "Geseeser Straße" and "Geseeser Weg" - select the latter - Enter House Number: 1 - lists "Geseeser Weg Altstadt Deutschland" and "Geseeser Weg Schnörleinsmühle". Since the part of Bayreuth is "Altstadt" (but no one would write that down as part of the address - it is Geseeser Weg 1, 95447 Bayreuth) select that - shows correctly on the map Let's try an example in Czeck Republic: Dukelská Ulica in Sokolov - Addresses - Spell Country: Ceská Republica - Spell City: Sokolov - No Results found but - Addresses - Spell Country: Country - Spell City: Sokolov - Enter Street name: Dukelská - Enter House Number: 1 - shows correctly on the map I know that I can use command line parameters for mkgmap: --country-name=Deutschland ^ --country-abbr=DEU ^ but that's not approriate here: there are 4 different countries to deal with. Otherwise, the parameters do their job correctly. According to the documentation, the style file should help mkgmap determine the country, and both my lines and points files say on their top: include 'inc/address'; How to solve this problem? Thanks for your hints.

6 12

o5m plugin for JOSM
by Gerd Petermann 22 Nov '13

22 Nov '13

Hi all, in february I wrote a plugin for JOSM to allow importing o5m files (which helps me debugging). I posted that via in the JOSM group josm-dev(a)openstreetmap.org, but I did not notice that my post did never reach that list. See http://gis.19327.n5.nabble.com/Patch-v1-o5m-support-for-JOSM-tp5749699.html The plugin worked fine for me without any changes, so if anybody interested in this I'll try to subscribe to the JOSM list. Gerd

2 2

r2829 in the high-prec-coord branch
by GerdP 19 Nov '13

19 Nov '13

Hi all, I've coded a replacement for the removeShortArcsByMergingNodes() method, called removeWrongAngles(). It also replaces the code to beautify roundabouts. Function: 1) remove zero length arcs and 2) remove wrong angles caused by rounding to map units (both only in roads and the overlaying lines). Up to now, the method accepts errors in angles of up to 30°, maybe this is going to change. The problem with the wrong angles occurs very often in roundabouts, but also in other places (causing zig-zagging) It still removes extremely short ways (when all points are rounded to the same point in map units) Please let me know what you think about it. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/r2829-in-the-high-prec-coord-branch-tp578606… Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 6

Re: [mkgmap-dev] nicer roundabouts
by Gerd Petermann 15 Nov '13

15 Nov '13

Hi Minko, great! Thanks for the hints ! Gerd > Date: Fri, 15 Nov 2013 18:05:22 +0100 > From: ligfietser(a)online.nl > To: gpetermann_muenchen(a)hotmail.com > Subject: Re: [mkgmap-dev] nicer roundabouts > > Thanks Gerd for the fixes, it works ok now with r2825 > > > ----- Oorspronkelijk bericht ----- > > Van: "Gerd Petermann" <gpetermann_muenchen(a)hotmail.com> > > Aan: "Minko" <ligfietser(a)online.nl> > > Verzonden: Vrijdag 15 november 2013 14:27:19 > > Onderwerp: RE: [mkgmap-dev] nicer roundabouts > > Hi Minko, > > > > > > > > > > An explanation could be that I use three different routable lines on > > > top of each other: > > > > > yes, the code did not handle this case. Seems I am getting old, as I > > forget this trick again and again. > > Maybe our default style should also use a type file, dunno how many > > devices are not able to handle it... > > > > Fixed with r2825. > > > > Gerd

1 0

Drive-on-left
by Colin Smale 15 Nov '13

15 Nov '13

Hi, In the last couple of years I have been making maps with mkgmap for both the UK and various continental countries. One problem that I have never been able to fix until now is that the "drive-on-left" flag didn't seem to have any effect on roundabouts in the UK. The "impact" is limited because roundabouts are one way anyway, but the pictographic representations of roundabouts always assume drive-on-right so you appear to be directed to drive the wrong way. I took a look at the code and saw that the drive-on-left and drive-on-right flags are only used to set a flag in NODHeader.java. However I just discovered ImgTool[1] which exposes the "TRE parameters", a sequence of four numbers which, I noticed, include a flag for "drive-on-left". This was not being set on my UK maps (despite using the drive-on-left option for mkgmap) so they all appeared to be drive-on-right. With ImgTool I was able to simply set this bit in my img file - and then the problems with the roundabout direction disappeared! I am not really a Java programmer so I don't feel confident about trying to fix this myself, but it seems there is related code in TREHeader.java including the following declarations: public static final int POI_FLAG_TRANSPARENT = 0x2; public static final int POI_FLAG_STREET_BEFORE_HOUSENUMBER = 0x4; public static final int POI_FLAG_POSTALCODE_BEFORE_CITY = 0x8; I think it just needs something like this adding: public static final int POI_FLAG_DRIVE_ON_LEFT = 0x20; plus the code to set this bit depending on the drive-on-left flag. It would be great if this could be changed in mkgmap. If I should really be logging this elsewhere please accept my apologies and point to me to the right place and I will enter the details there. Best regards (and thanks everyone for a tremendous program!) Colin [1] https://sites.google.com/site/sherco40/imgtool [1] Links: ------ [1] https://sites.google.com/site/sherco40/imgtool

7 19

nicer roundabouts
by Gerd Petermann 14 Nov '13

14 Nov '13

Hi all, I've coded a new algo to detect and remove sharp angles in roundabouts caused by rounding coordinates to map units. There are many special cases, but I think it works quite well now. Please test mkgmap-high-prec-coord-r2819 . I found two typical problems: 1) Small roundabouts (radius < 10m) mapped with (too) many points, this gives ways like in 157324858_o.gpx 2) Large roundabouts (radius > 16m) mapped with too few points. Note that some of these problems cause routing problems in the trunk version but not in the branch. I've left a lot of debugging messages in the code, so you should write the sysout to a file (I'll change the code to use the logging system later) I have also left an option --x-gpx-dir=<dir-for-gpx-files> to create gpx files showing the ways in various stages. Note that this option produces many small files, so use it only with one or a few input files. The gpx files have a name scheme: [way-id]_o.gpx: original way, once with high precision coordinates, once with the rounded values [way-id]_del1_[n]_[pass].gpx: way before a remove-point-action [way-id]_del2_[n]_[pass].gpx: way after a remove-point-action [way-id]_m.gpx: final roundabout, once with high precision coordinates, once with the rounded values, plus map unit grid You should not find many of these: [way-id]_repl_o_[pass].gpx, id]_repl_n_[pass].gpx way that is connected to a roundabout, and the move of the node causes a notable change in the angle near the roundabout. I found no case where this lead to uglyer angles, typically, the changed way was closer to the one in OSM . Open question: The algo doesn't add points to make a roundabout rounder. It just complains like this: Way http://www.openstreetmap.org/browse/way/136791460: roundabout has rather few distinct points: 9 (radius ~ 17 m) Way http://www.openstreetmap.org/browse/way/136791476: roundabout has rather few distinct points: 8 (radius ~ 20 m) Both examples also show why adding points is not a good idea. The rule for these messages : if (radius < 10.0) niceNumSides = 8; else if (radius < 13.0) niceNumSides = 12; else if (radius < 20.0) niceNumSides = 16; else niceNumSides = 20; if (points.size() < niceNumSides){ if (points.size() < 16) System.out.println(msgPref + ": roundabout has rather few distinct points: " + points.size() + " (radius ~ "+Math.round(radius)+" m)"); niceNumSides = points.size(); } Are these rules okay? Are the messages helpful? Gerd

3 8

test, please ignore
by Valentijn Sessink 12 Nov '13

12 Nov '13

test, please ignore

1 0