June 2015 - mkgmap-dev - The mkgmap lists

process-exits and Oregon 600
by michael lohr 05 Jun '15

05 Jun '15

A few weeks ago I upgraded from Oregon 450 to Oregon 600, and since then exithints are not shown anymore. Instead the generic name of either the 1st or 3rd bit of the exit is displayed (I'd still have to check which of both).My mkgmap settings are unchanged and the exits are correcetly named in the img files, so it seems like a device problem. Any ideas anyone how to fix that? Regards, Micha

5 23

Commit: r3607: - exit-from-link-v1.patch : use also primary_link ways in options --process-exits and --process-destination
by svn commit 05 Jun '15

05 Jun '15

Version mkgmap-r3607 was committed by gerd on Fri, 05 Jun 2015 - exit-from-link-v1.patch : use also primary_link ways in options --process-exits and --process-destination Update and improve documentation of the options

1 0

Exception with location-autofill option on r3605
by Paco Tyson 04 Jun '15

04 Jun '15

Hi all, I've updated mkgmap from r3596 to r3605 to try the house number improvements. Nothing else in my toolchain changed. mkgmap returns the following exception 6 times, I can't explain why they appear as nothing in the change logs is related to this option (location-autofill: is-in,nearest) : [java] java.lang.IllegalArgumentException: is-in is not a known sub option for option location-autofill: is-in,nearest [java] at uk.me.parabola.mkgmap.build.LocatorUtil.parseAutofillOption(LocatorUtil.java:75) [java] at uk.me.parabola.mkgmap.build.Locator.<init>(Locator.java:52) [java] at uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryLocationPreparer.<init>(BoundaryLocationPreparer.java:57) [java] at uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryQuadTree.<init>(BoundaryQuadTree.java:107) [java] at uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil.loadQuadTreeFromStream(BoundaryUtil.java:493) [java] at uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil.loadQuadTrees(BoundaryUtil.java:176) [java] at uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryGrid.init(BoundaryGrid.java:103) [java] at uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryGrid.<init>(BoundaryGrid.java:66) [java] at uk.me.parabola.mkgmap.reader.osm.LocationHook.end(LocationHook.java:98) [java] at uk.me.parabola.mkgmap.reader.osm.OsmReadingHooksChain.end(OsmReadingHooksChain.java:79) [java] at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:63) [java] at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:130) [java] at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) [java] at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) [java] at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:255) [java] at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:251) [java] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [java] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [java] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [java] at java.lang.Thread.run(Thread.java:744) The produced files are corrupt. Cheers, Paco

3 3

Commit: r3606: - don't process roads with less than two points
by svn commit 04 Jun '15

04 Jun '15

Version mkgmap-r3606 was committed by gerd on Thu, 04 Jun 2015 - don't process roads with less than two points - add test to catch invalid data in RoadPoint

1 0

Patch to fix 'allow to' typo in splitter documentation
by Sebastiaan Couwenberg 04 Jun '15

04 Jun '15

While updating the Debian package for splitter release 423, the lintian QA tool reported a typo in the documentation. The attached patch fixes the issue. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1

2 2

[Patch v1] improve handling of exits
by Gerd Petermann 03 Jun '15

03 Jun '15

Hi all, attached patch changes mkgmap so that a) the process-exits and process-destination options are also checking highway=primary roads and also those cases were a link divides into two or more further link roads. b) the exit_to tag on a highway=motorway_junction node is ignored when the road is e.g. a highway=trunk and all connected roads are trunk_links. Typically, the exit_to tag contains then a list of hints, but it is not clear which hint is meant for which way. I've uploaded a binary based on r3598: http://files.mkgmap.org.uk/download/266/mkgmap.jar @Dave: Please note the changes in the default style. It would be great if you could test this patch and maybe suggest a better description of the two options. Gerd

3 6

Re: [mkgmap-dev] process-exits and Oregon 600
by Bernd Weigelt 03 Jun '15

03 Jun '15

Hi Gerd As i am remember, WanMil presumed to use 0x07 as the second part, i use this in my style Bernd Hier sollte eigentlich eine Signatur stehen. -----Original Message----- From: GerdP <gpetermann_muenchen(a)hotmail.com> To: mkgmap-dev(a)lists.mkgmap.org.uk Sent: Mi., 03 Juni 2015 18:10 Subject: Re: [mkgmap-dev] process-exits and Oregon 600 Hi Michael, michael lohr wrote > Finally found the reason: my style assigns generic names to unnamed > roads, so the segments of a motorway_link were named "GENERIC_NAME", > "EXIT_HINT", "GENERIC_NAME". As soon as a name is present on either the > 1st or the 3rd segment the Oregon would use this name for routing (btw, > contrary the my previous posts: the Oregon 450 also behaves like that). > > Which brings up this question: why not assign the exit_hint to all 3 > segments in the first place? My understanding is that the style should be able to use a different type (not 0x08 / 0x09) for that small 2nd part, so that Garmin uses the name of it as a hint. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/process-exits-and-Oregon-600-tp5845444p58469… Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

1 0

Splitter problem: losing a track segment
by Alexandre Loss 02 Jun '15

02 Jun '15

Hi guys, I'm facing a problem in one of my maps, that is probably might be happening in other places where I didn't see yet. The problem can be seen in the figure below taken from MapSource. There is a gap in a track on the border of the tiles: [image: Imagem inline 2] So I started to analyze the problem step-by-step till find that the problem was generated by Splitter (last version). To simplify your analysis, I edited my .osm file before running Splitter and remove all objects (nodes, lines, poi, etc.) not related to the problem, leaving only the line where the problem happens. The result was the file "93352150-Ribeirao_Preto.osm" attached, containing only this: <?xml version="1.0" encoding="UTF-8"?> <osm version="0.6" generator="TSuite 6.6.0.4">  <node id="576" lat="-21.9388623" lon="-48.3347007" visible="true" version="1"/> <node id="805" lat="-21.8877920" lon="-48.2932640" visible="true" version="1"/> <node id="806" lat="-21.8674906" lon="-48.2767485" visible="true" version="1"/> <node id="804" lat="-21.8661147" lon="-48.2756044" visible="true" version="1"/> <way id="803" visible="true" version="1"> <nd ref="576"/> <nd ref="805"/> <nd ref="806"/> <nd ref="804"/> <tag k="highway" v="trunk"/> <tag k="name" v="SP-255 DANIELLE"/> <tag k="ref" v="SP-255"/> <tag k="addr:city" v="BOA ESPERANÇA DO SUL"/> <tag k="addr:state" v="SP"/> <tag k="addr:country" v="Brasil"/> </way>  </osm> Then I ran Splitter on this file and the result was the file "93352150.osm" (attached and compacted), whose content are the lines bellow: <?xml version='1.0' encoding='UTF-8'?> <osm version='0.5' generator='splitter' upload='false'> <bounds minlat='-21.895751953125' minlon='-50.262451171875' maxlat='-20.401611328125' maxlon='-47.548828125'/> <node id='805' lat='-21.8877920' lon='-48.2932640'/> <node id='806' lat='-21.8674906' lon='-48.2767485'/> <node id='804' lat='-21.8661147' lon='-48.2756044'/> <way id='803'> <nd ref='576'/> <nd ref='805'/> <nd ref='806'/> <nd ref='804'/> <tag k='highway' v='trunk'/> <tag k='name' v='SP-255 DANIELLE'/> <tag k='ref' v='SP-255'/> <tag k='addr:city' v='BOA ESPERANÇA DO SUL'/> <tag k='addr:state' v='SP'/> <tag k='addr:country' v='Brasil'/> </way> </osm> Note that in the "93352150.osm" file is missing the node 576 definition (i.e.: <node id="576" lat="-21.9388623" lon="-48.3347007" visible="true" version="1"/>). And this is the cause of the lost segment. I'm running Splitter in the following way: java -jar splitter.jar --split-file=93352150-Ribeirao_Preto.list --max-areas=1024 --mixed=true --keep-complete=false --resolution=15 --output=xml 93352150-Ribeirao_Preto.osm The above .list file is attached. If this is not a Splitter error, please, let me know what I'm doing wrong. Thanks. Alexandre

3 7

Commit: r3605: merge the housenumber2 branch
by svn commit 02 Jun '15

02 Jun '15

Version mkgmap-r3605 was committed by gerd on Tue, 02 Jun 2015 merge the housenumber2 branch Major changes: - improved evaluation of addr:* tags, esp. the support for addr:place and the support for addr:housenumber without addr:street, img data is optimized to make sure that address search finds a place close (< 40m) to the address. - internal: implementation of "number nodes" and support for multiple cities / zip codes for one road - implementation of special tags mkgmap:execute_finalize_rules=true and mkgmap:numbers=false Minor change: - the (duplicated) closing point of a polygon is no longer overweighted when calculating the center of an area, this has an effect on the placement of POI generated with --add-pois-to-areas Impact on performance: - around 10 % more run time, maybe more for areas with many streets (tiles in large cities) - increased img file size (amount depends on the data, for areas with many addr:place tags like Czech Republic expect > 10%)

1 0

Commit: r3602: --add-pois-to-areas: use the position of a role=label node in an mp-relation
by svn commit 01 Jun '15

01 Jun '15

Version mkgmap-r3602 was committed by gerd on Mon, 01 Jun 2015 --add-pois-to-areas: use the position of a role=label node in an mp-relation If a role=label node is found and it has the same name as the relation, use it (also in preference to a role=admin_centre node)

1 0