June 2013 - mkgmap-dev - The mkgmap lists

[Patch v2] improve routing with --link-pois-to-ways
by GerdP 15 Jun '13

15 Jun '13

Hi, see also http://gis.19327.n5.nabble.com/improvements-for-routing-tp5765242.html This 2nd version eliminates possible missinterpretations of CoordPOI when a POI (e.g. a barrier) from one road is merged into another. Attached is version 2 of the patch: coordPOI_v2.patch <http://gis.19327.n5.nabble.com/file/n5765499/coordPOI_v2.patch> The compiled binary is here: http://files.mkgmap.org.uk/download/134/mkgmap.jar Those users that use --link-pois-to-ways: Please test with enabled logging and check all warnings containing the string "CoordPOI". Let me know when you think that the result is worse compared to r2648. Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Patch-v2-improve-routing-with-link-pois-to-w… Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

Commit: r2647: Remove static 'style' field which is likely causing random test failures.
by svn commit 14 Jun '13

14 Jun '13

Version 2647 was committed by steve on Fri, 14 Jun 2013 Remove static 'style' field which is likely causing random test failures.

2 1

tests passing on trunk?
by Greg Troxel 14 Jun '13

14 Jun '13

I have a 2 year old Mac Book Pro, running 10.7. I recently updated and installed Java 7 (from Oracle). /usr/libexec/java_home prints: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home and I've set JAVA_HOME to that. With r2644, and a clean checkout (removing even ignored files), "ant dist" works fine and the output looks normal. Then, running 'ant test' gets me 8 failures and 13 errors out of 291 tests. So, am I using a reasonable jdk version? are these test faailures of concern (they seem to be) does this work ok for others? Thanks, Greg

3 9

Comments in TYP file
by Roger Calvert 14 Jun '13

14 Jun '13

Recent versions of TYPViewer (https://sites.google.com/site/sherco40/) allow comment lines of the form Comment= in the Polygon, Polyline or POI sections of the TXT file. These are not transferred to the TYP file. These cause a warning in the TYP compiler integrated in mkgmap, and are ignored. Should this warning be suppressed ? Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------

2 1

Commit: r2646: Allow for TRE size differences caused by version number in tests.
by svn commit 14 Jun '13

14 Jun '13

Version 2646 was committed by steve on Fri, 14 Jun 2013 Allow for TRE size differences caused by version number in tests. The TRE section size contains the svn version number. This varies depending on whether your checkout is modified or not. So allow the size to differ by a couple of characters before throwing a failure.

1 0

Commit: r2645: Add the dependancy obtain-test-input-files to the test target.
by svn commit 14 Jun '13

14 Jun '13

Version 2645 was committed by steve on Fri, 14 Jun 2013 Add the dependancy obtain-test-input-files to the test target.

1 0

improvements for routing
by Gerd Petermann 14 Jun '13

14 Jun '13

Hi, I found a few issues in r2644, mainly with the link-pois-to-ways option, but also with short arcs that created when splitting loops. As discussed before, this option is used to handle nodes with barrier=* or traffic_calming=* which are so-called CoordPOI. 1) the removeShortArcsByMergingNodes() method may replace a) a CoordPOI with a normal node. This typically just leads to some roads where the POI doesn't influence routing. b) a normal node or a CoordPOI with a(nother) CoordPOI. In the worst case this might lead to a high speed road having a small part tagged with access=no, foot=yes, eg. see http://www.openstreetmap.org/browse/way/37535681 It is likely that the last node with highway=crossing is replaced by the middle node which has barrier=cycle_barrier This happens quite often because nodes with barrier=* are typically close to a node that connects roads. 2) If a CoordPOI replaces a normal node, the highwayCount might be < 2 so that later this node is not to connect the roads, leaving some roads with bollards unconnected. Sample: http://www.openstreetmap.org/browse/way/4087549 It is likely that this road gets unconnected, and the mkgmap:set_unconnected_type feature will not help here because the road is "disconnected" after the check. I did not find a simple fix for all issues, sometimes the CoordPOI has to be ignored, but a lot of routing errors (esp. for pedestrians) disappear with the attached patch. The compiled binary is here: http://files.mkgmap.org.uk/download/133/mkgmap.jar You should enable logging for the StyledConverter to see new messages regarding CoordPOI. Gerd

1 1

Chinese / Japanese question on the OSM help site
by SomeoneElse 11 Jun '13

11 Jun '13

This question was asked a couple of days ago: https://help.openstreetmap.org/questions/23157/chinese-in-pinyin-on-japan-m… The questioner has tried a couple of potential canned download locations to no avail. Perhaps someone knows a download site that already contains data in the format that they are looking for, or could help them create it? Cheers, Andy

1 0

Routing Error Hannover
by chris66 11 Jun '13

11 Jun '13

Hi, Garmin will do strange loops when routing this way: http://osrm.at/3yV (OSRM is routing correctly here). Default mkgmap style. V2606 Options: description=OSM_CityMap series-name=OSM_CityMap family-name=OSM_CityMap country-name=Deutschland country-abbr=DEU family-id=66 product-id=1 mapname=66240001 latin1 # make-opposite-cycleways # link-pois-to-ways # add-pois-to-areas remove-short-arcs=5 (does not help) no-merge-lines (override default, but does not help) location-autofill=bounds,nearest bounds=c:\apps\mymap\bounds # ignore-maxspeeds (no influence) index route net tdbfile gmapsupp

3 6

Question about bicycle routing
by Philip Homburg 10 Jun '13

10 Jun '13

I noticed in the past that bicyle routing was sometimes a bit weird, but I just assumed that things were not properly tagged. Recently, it seemed to get worse and worse, and spend some time investigating what was going on. I experimented with BaseCamp on OSX and a GPSmap 62s. And mkgmap r2643 What I'm seeing is that Garmin actually tries avoid anything that is marked with highway=cycleway. The rule for this is: highway=cycleway {add access = no; add bicycle = yes; add foot = yes} [0x07 road _class=0 road_speed=1 resolution 23] Now if I remove the 'access=no', then it just works. Experimenting a bit more, adding a 'add motorcar=no' causes it to misbehave again. Does anybody know what is going on?

3 4