March 2014 - mkgmap-dev - The mkgmap lists

Commit: r3109: correct SeaGenerator and some Boundary tools
by svn commit 13 Mar '14

13 Mar '14

Version mkgmap-r3109 was committed by gerd on Thu, 13 Mar 2014 correct SeaGenerator and some Boundary tools use high precision in Way.clockwise() and Way.containsPointsOf() This reduces the number of messages like " Converting anti-island starting at ... into an island as it is surrounded by water" The routines are not used to calculate precompiled sea data or precompiled boundary data, but they are used in tools like BoundaryCoverageUtil, BoundaryDiff, BoundaryFile2Gpx and to debug boundary data, so there is no need to create new precompiled data because of this change.

1 0

Bug: Address search and opposite cycleway
by Thorsten Kukuk 12 Mar '14

12 Mar '14

Hi, I was wondering why I couldn't find sometimes addresses even if they where entered correct in OSM. By pure luck I found now the reason, it looks like if a way has the tag "cycleway=opposite", the address information is put on the wrong way. Look at Sandwall 17 or 19 in Wyk auf Foehr (http://www.openstreetmap.org/#map=17/54.68666/8.56960) With my own and with the default mkgmap style, you will not find the address with "Sandwall 17", but with "Sandwall (Cycleway) 17". I think for address search, the "(Cylceway)" streets should be ignored. 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)

3 10

Commit: r3108: Do not strip street names when matching house numbers to roads.
by svn commit 12 Mar '14

12 Mar '14

Version mkgmap-r3108 was committed by wanmil on Wed, 12 Mar 2014 Do not strip street names when matching house numbers to roads. This was a relict from the time before the mergeroads branch was merged. Street names are now taken as they are. Text in brackets are no longer removed from street names.

1 0

new branch NOD127
by Gerd Petermann 11 Mar '14

11 Mar '14

Hi all, I've created a new branch NOD127 : http://www.mkgmap.org.uk/download/mkgmap-NOD127-r3086.zip This is used to test the latest findings regarding the NOD file format. Most of it is understood now, thanks to Steve and his display tool :-) Changes in r3086 compared to trunk r3081: - nodes are grouped by classes and additional arcs are written to connect nodes. This seems to improve routing, at least it is much closer to what real maps contain. - avoid roundabouts works in Basecamp (only with "shorter distance") - avoid toll roads works as expected, is trunk it has to be switched on to allow routing on major roads A few open questions remain at this point: - the carpool bit seems to have no effect, it is likely that there is a bit in the NOD header that has to be switched on or off to change that, but we don't know where. - some original maps contain extra info for route restrctions, we don't know yet what they mean. Gerd

6 32

Infinite loop splitter
by Minko 10 Mar '14

10 Mar '14

Hi, I was trying to update my Benelux map but the splitter refused to finish the process. Normally, splitter is finished in 2 minutes, now it gets in an infinite loop with Full GC. What can be the cause for this, a corrupt download of the europe extract?

6 23

splitter and srtm2osm
by Michał Rogala 10 Mar '14

10 Mar '14

Hi! Did anyone manage to merge SRTM (srtm2osm output file) with any OSM map using splitter? Splitter complaints that IDs in srtm.osm file are not sorted. osmosis has a bug (exception: 'cannot represent XX as char') and I can't use it to sort srtm.osm file. Is there any way that I can force splitter to merge both files with unsorted ID's? Thanks in advance for any help :) Michal Rogala

3 3

Commit: r3093: Fix a possible assertion when building the street index.
by svn commit 08 Mar '14

08 Mar '14

Version mkgmap-r3093 was committed by steve on Sat, 08 Mar 2014 Fix a possible assertion when building the street index. All cases where sorted names are compared with equals() need to be changed to use Collator.compare() with the SrtCollator from Sort. This patch fixes just a few cases to fix an observed assertion error.

1 0

mkgmap SVN r3087 does not create valid gmapsupp.img files for Garmin etrex
by Andreas Tille 07 Mar '14

07 Mar '14

Hi mkgmap developers, I revitalised the mkgmap packaging for Debian which was orphaned for some time. I was lucky to build r2981 and create valid gmapsupp.img files for my etrex 30 and my etry Vista HCx. (I picked this SVN revision some time ago and was able to solve some trouble building the package thanks to the help of Debian GIS team.) Today I fetched the latest SVN release r3087 but the resulting gmapsupp.img does not load on both Garmin devices of mine. To make sure it is not the build process I also fetched your prebuilded JAR file ... with the same failure. I wonder what information you might need to track down the issue. I could offer to do some bisecting to verify intermittent versions if this might help. Kind regards and thanks for creating OSM software Andreas. -- http://fam-tille.de

3 2

Commit: r3092: reduce severity level of message for moved via point
by svn commit 07 Mar '14

07 Mar '14

Version mkgmap-r3092 was committed by gerd on Fri, 07 Mar 2014 reduce severity level of message for moved via point

1 0

New turn restriction warnings after high-prec-coord merge
by Carlos Dávila 07 Mar '14

07 Mar '14

Current trunk outputs a lot of warnings of the type below: Turn restriction http://www.openstreetmap.org/browse/relation/66916 (at http://www.openstreetmap.org/?mlat=39.698722&mlon=-5.969887&zoom=17) no_left_turn 'via' coord redefined from http://www.openstreetmap.org/?mlat=39.698722&mlon=-5.969887&zoom=17 to http://www.openstreetmap.org/?mlat=39.698722&mlon=-5.969887&zoom=17 If I got this right, it warns about a movement in the via node coordinates, but the "from" and "to" coordinates reported are the same. Can these coordinate changes affect routing? If not, is it necessary this type of warning?

2 1