- mkgmap-dev - The mkgmap lists

Address search: city sometimes missing
by Thorsten Kukuk 17 Jan '14

17 Jan '14

Hi, I wasn't able to find specific addresses on my Garmin 62s, even if I did know that I entered them in OSM. During testing of my adjusted style for the new mkgmap version, I found out that the addresses are not missing, but that the addresses don't have a city assigned. That's why I cannot find them on my 62s, where I have to enter a city always, but with mapsource. The question is now, why? This happens with the default style of mkgmap, too, independent of the mkgmap version. For example, look here: http://www.openstreetmap.org/#map=17/49.44674/11.03418 There are two buildings from Siemens, Von-der-Tann-Strasse 30 and 31 in 90439 Nuernberg. As you could see in the attached screenshot, only the housenumber 31 has a city assigned, the number 30 has not. I added some "echotags" to the style file: mkgmap:city is set correct to Nuernberg in all cases. Any idea what's going wrong? Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

4 18

Routing
by Steve Ratcliffe 17 Jan '14

17 Jan '14

Hi I've been looking into routing and I have updated NodDisplay so that it mostly works on any file. I've not discovered much that wasn't known before, apart from a compact way of storing directions that is probably suitable for short roads. There is a destination road-class field in the node flags that we do not seem to set, so we should fix that. I am in the process of updating the nod.txt file with everything I've learned so far. There are also two new programs. 1. test.check.NodCheck reads in a NOD file and cross checks various things. So it can tell you if the angle in NOD is similar to the actual angles between two nodes. Files give lots of errors, but it doesn't mean that they are wrong, just things to look into. 2. test.svg.Main Converts the routing graph to an SVG file that can be displayed in inkscape (and perhaps other SVG viewers). The idea is to be able to visualise what is going on. Only a portion of the file is processed, since the output is very large. They are only of use if you want to look into the routing code. The output will make no sense at all if you are not familiar with it, and possibly even if you are ;) ..Steve

4 16

Error with mkgmap-high-prec-coord-r2970
by Jaromír Mikeš 17 Jan '14

17 Jan '14

Hi, I got error with mkgmap-high-prec-coord-r2970 Time started: Thu Jan 16 23:04:03 CET 2014 java.lang.AssertionError at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.calcAreaSizeTestVal (ShapeMergeFilter.java:455) at uk.me.parabola.mkgmap.general.MapDetails.addShape(MapDetails.java:106) at uk.me.parabola.mkgmap.general.AreaClipper.clipShape(AreaClipper.java:54) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.addShape(StyledConverter. java:957) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.addConvertedWay (StyledConverter.java:267) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.access$300 (StyledConverter.java:77) at uk.me.parabola.mkgmap.osmstyle.StyledConverter$WayTypeResult.add (StyledConverter.java:211) at uk.me.parabola.mkgmap.reader.osm.WatchableTypeResult.add (WatchableTypeResult.java:45) at uk.me.parabola.mkgmap.osmstyle.ExpressionRule.resolveType(ExpressionRule. java:60) at uk.me.parabola.mkgmap.osmstyle.RuleSet.resolveType(RuleSet.java:68) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.convertWay (StyledConverter.java:250) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java: 234) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load (OsmBinMapDataSource.java:67) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource. java:127) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor. java:615) at java.lang.Thread.run(Thread.java:724) Exiting - if you want to carry on regardless, use the --keep-going option Time finished: Thu Jan 16 23:08:36 CET 2014 Total time taken: 273473ms

2 1

Mkgmap always returns exit code 0 even when it fails
by paco.tyson＠free.fr 14 Jan '14

14 Jan '14

Hi, I'm building a map generation tool with Ant. Problem is that if mkgmap encounters an error, the exit code is 0, no matter what. As this is the "OK" exit code, Ant carries on to the rest of the workflow. On the contrary, splitter does return a non zero code when it fails. Please make mkgmap return a non zero exit code for errors. Thanks, Paco

3 4

Commit: r2961: Implement reading the NOD header and add the relevant getters.
by svn commit 13 Jan '14

13 Jan '14

Version mkgmap-r2961 was committed by steve on Mon, 13 Jan 2014 Implement reading the NOD header and add the relevant getters. This is not used by mkgmap, will be used for testing/debugging in display.

1 0

RoadMerger
by Gerd Petermann 13 Jan '14

13 Jan '14

Hi WanMil, two points: 1) line 517 is obsolete: mergePoints.add(end); It just blows up the size of the list and processing time. 2) You were right regarding closed ways and different results. The merge may create p-shaped loops. See way 80605369. If the northern node 381305537 is merged first: 2014/01/06 10:20:40 Fein (RoadMerger): e:\gerd\sp_out\63240030.o5m: Merge 33134762 and 80605369 with angle 23.159455845890676 and later: 2014/01/06 10:20:40 Fein (RoadMerger): e:\gerd\sp_out\63240030.o5m: Merge 33134762 and 80605327 with angle 44.86962367701949 This produced a p-shaped road (including a loop). If the node 374244500 is processed first, no merge happens because this would produce a closed loop, so the node is added to mergeCompletedPoints. The p-shaped road is split later in StyledConverter, so this is not an error, but obviously it makes no sense to merge first and split again later. Maybe you see a simple solution for this? Gerd

7 22

Malformed piers and other issues
by Jaromír Mikeš 13 Jan '14

13 Jan '14

Hi, I just noticed some malformed shapes and other issues on my map of Finland (mkgmap 2960) 1) Here you can see marina in Tampere FIN: https://lh3.googleusercontent.com/-imfiglzjDoY/UtPvvtgjozI/AAAAAAAAASs/0UYn… As you see some piers are missing: http://www.openstreetmap.org/#map=17/61.50956/23.77275 2) Also some shapes are malformed: https://lh6.googleusercontent.com/-mgouh6oXCmg/UtPvwTjnfUI/AAAAAAAAATI/Rvx5… https://lh5.googleusercontent.com/-FzxBR8RKwuo/UtPvwbqWHHI/AAAAAAAAASM/GQNX… Here same places on OSM: http://www.openstreetmap.org/#map=19/61.51038/23.76961 http://www.openstreetmap.org/#map=19/61.50888/23.77463 3) Here is one place with a lot of disconected roads: https://lh6.googleusercontent.com/-nP6DcUoVqS4/UtPvvmmUYNI/AAAAAAAAAS4/IVDl… Same place on OSM looks nicer: http://www.openstreetmap.org/#map=19/61.50778/23.77253 4) Same road are interupted in certain zoom level: https://lh5.googleusercontent.com/-Rf2ob4Q_fQ0/UtPvvtrrJLI/AAAAAAAAAR0/Vasf… regards mira

3 13

Question regarding duplicated shapes
by Gerd Petermann 12 Jan '14

12 Jan '14

Hi all, while debugging the shape merger I found many duplicated shapes in Finland, and I am not sure how mkgmap should handle them. Example: http://www.openstreetmap.org/way/105723026 is tagged landuse=farm and is the role=inner member of multipolygon relation http://www.openstreetmap.org/relation/1504949 which has only one role=outer way which also is tagged landuse=farm. Way http://www.openstreetmap.org/way/105719041 is a copy of way 105723026, but with reverse order of points. It is tagged natural=scrub mkgmap r2960 with the default style and --preserve-element-order adds three shapes: one for the outer way with type 0x4e one for way 105719041 with type 0x4f one for way 105723026 with type 0x4e As a result, the natural=scrub is not shown in GPSMapEdit. My shape merger first merges the outer way and the inner way and then adds the natural=scrub later. Now GPSMapEdit shows the area. My understanding is that something goes wrong in the MultiPolygonRelation code. Why is way 105723026 added with type 0x4e? Gerd

2 2

wrong rendering of direction with oneway=-1?
by Minko 12 Jan '14

12 Jan '14

I notice that mkgmap-r2946 renders the direction of arrows in the reverse direction compared with previous versions. This is only the case with oneway=-1, oneway=yes is pointing in the same direction as expected. Before the merge (mkgmap-r2815) it was rendered ok. Is there something changed or is it a bug? See OFM https://www.dropbox.com/s/6wn24e97iu1l20r/oneway-1.jpg OSM http://www.openstreetmap.org/way/253023406 BTW routing is still as expected, only the drawing is now in the opposite direction! My style rules: http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/Styles/ # display direction arrows highway=* & (oneway=yes | bicycle:oneway=yes ) & (cycling!=twoway) & bicycle!=no [0x10007 resolution 24 continue with_actions] highway=* & (oneway=yes | bicycle:oneway=yes ) & (cycling=twoway) [0x10008 resolution 24 continue with_actions] highway=* & (oneway=-1 | bicycle:oneway=-1 ) & (cycling!=twoway) & bicycle!=no [0x10010 resolution 24 continue with_actions] highway=* & (oneway=-1 | bicycle:oneway=-1 ) & (cycling=twoway) [0x10011 resolution 24 continue with_actions] In my typ file it still shows as expected: oneway=yes is rendered as Type=0x10010 is ---> oneway=-1 is rendered as Type=0x10007 is <--- http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/10010.typ In gpsmapedit I dont see errors either, both lines are produced as expected.

4 9

Commit: r2960: Documentation: Some more small fixes
by svn commit 11 Jan '14

11 Jan '14

Version mkgmap-r2960 was committed by wanmil on Sat, 11 Jan 2014 Documentation: Some more small fixes --Ataro A

1 0