- mkgmap-dev - The mkgmap lists

relations file difference
by Gerd Petermann 01 Dec '13

01 Dec '13

Hi WanMil, please check: I've just committed r2851, a merge from trunk in the mergeroads branch, but I am not sure about the change in the relations style file. Gerd

2 1

Commit: r2849: remove obsolete call to checkFixmeCoords
by svn commit 01 Dec '13

01 Dec '13

Version mkgmap-r2849 was committed by gerd on Sun, 01 Dec 2013 remove obsolete call to checkFixmeCoords

1 0

Commit: r2848: minor correction: evaluate the fixme tag of points before
by svn commit 01 Dec '13

01 Dec '13

Version mkgmap-r2848 was committed by gerd on Sun, 01 Dec 2013 minor correction: evaluate the fixme tag of points before using routines which replace coords and drop the info.

1 0

The road network and duplicate ways
by Gerd Petermann 01 Dec '13

01 Dec '13

Hi Steve, some styles assign create multiple routable lines for the same OSM way, e.g. to set different road-class or speed values for bike and car. This seems to work, but reg. performanc I see two points: 1) We do all kinds of calculations multiple times, e.g. all the bearing calculations and (Douglas-Peucker) filters. 2) We save the points for the same line multiple times in the img file. A possible alternative would be to have a class that stores the list of points and a list of assigned types, but that would involve a lot of changes. I wonder if the img format allows to store the points only once, means, can we store one NET entry and multiple NOD entries referring to the same NET entry? Another point that I don't fully understand: In RoadNetwork.addRoad() we always add the reverse arc for each arc. I wonder why oneway roads are not treated different here, esp. if they have foot=no? Gerd P.S. A while ago I tried to find out the meaning of the curve data encoded with two bytes. I failed because I was not able to change display tool to read my Garmin map NOD file. I saw too many "sync lost" messages. I guess the format is too different, e.g. NOD header length is 0x3f. I have created a local copy of NodConvert that is more up to date. Should I commit that?

1 0

r 2839 in high-prec-coord branch
by Gerd Petermann 30 Nov '13

30 Nov '13

Hi all, it took a while to analyse many special cases, but today I've committed r2839. Compared to trunk you should see: - better routing results because bearing values are calculated using the high precision values of coordinates. - fewer optical errors caused by rounding, e.g. ugly roundabouts or havy zig-zagging lines in the img when OSM data shows an almost straight line - smaller img file size because many obsolete points are removed - slightly higher peak memory usage, else not much difference in throughput Wrong angles are corrected by either moving the displayed points a little bit or by removing them. In some cases, points are merged as in the old short-arc-removal process, but with improvements: - if a way has only two points, the algo tries to keep that way in favor to a wrong angle in the img (else routing would be changed in favor to optic) - very close exit points on a roundabout are kept if possible (to avoid wrong "leave roundabout at" messages Up to now the changes are calculated for routable ways. In a second step, non-routable ways (not shapes) sharing modified points are modified as well. This is useful for those users who create styles for biking. The code needs a bit of review, but I think the result is very good now. Next on my todo list: 1) Change the implementation of the --link-pois-to-ways feature. Current implementation is too complex. Maybe it doesn't work at all now. @WanMil: Or do you already work on it? 2) Implement the merge-shape feature. Gerd

3 4

Access handling trunk <=> mergeroads branch
by WanMil 30 Nov '13

30 Nov '13

Hi, I am comparing differences between the mergeroads branch running the compatibility mode and the trunk. Having the following way: access = destination highway = path The access bits are set as: trunk | branch no_car | 0 | 1 no_bus | 0 | 1 no_taxi | 0 | 1 no_foot | 0 | 0 no_bike | 0 | 1 no_truck | 0 | 1 no_throughrt | 1 | 1 delivery | 0 | 1 emergency | 0 | 1 0 = bit is not set 1 = bit is set For delivery and emergency I am not sure if delivery/emergency is allowed if the bit is set or unset. At the moment the trunk allows all type of vehicles to use the given way. I think that's not good. The branch allows only foot to use the way. What do you think should be the correct access bit mask for the given way? Does anyone know if delivery bit == 1 means the way can be used if one has something to deliver to a point of this way? And the same for emergency? WanMil

3 3

[splitter patch] check for mapids with less than 9 digits
by Ben Konrath 28 Nov '13

28 Nov '13

Hi guys, I ran into a problem where my map failed to generate properly with mkgmap when the mapid used with splitter had more than 9 digits. I've attached a patch for splitter to check for a mapid with more than 9 digits. Thanks, Ben

2 2

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