- mkgmap-dev - The mkgmap lists

Commit r4437: perform some basic checks for invalid type/subtype in polish (.mp) input
by svn commit 04 Feb '20

04 Feb '20

Version mkgmap-r4437 was committed by gerd on Tue, 04 Feb 2020 perform some basic checks for invalid type/subtype in polish (.mp) input http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4437

1 0

Commit r4436: Correction: Invalid NOD data was written for roads with > 250 points (after merge) and no connections to other roads or housenumbers (extra bit was not set properly).
by svn commit 04 Feb '20

04 Feb '20

Version mkgmap-r4436 was committed by gerd on Tue, 04 Feb 2020 Correction: Invalid NOD data was written for roads with > 250 points (after merge) and no connections to other roads or housenumbers (extra bit was not set properly). This is likely to happen in "empty" areas like parts of Africa or Canada, unlikely in dense areas like Germany. Problem was introduced in the NET-no-NOD branch. In tiles where this problem occured the img size will grow a little bit. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4436

1 0

Need help with build scripts
by Gerd Petermann 03 Feb '20

03 Feb '20

The attached patch changes the build process so that the mkgmap\resources\help\en\options is generated. It uses a slightly modified version of Mike Baggaleys program to compute this file with mkgmap\doc\options.txt as input. My problem: Up to now the generated file is in the svn repo and Eclipse uses this file when compiling mkgmap while ant dist first builds the file and then creates a copy of it and uses this copy to build mkgmap.jar. My problems so far: - if someone edits mkgmap\resources\help\en\options he will lose his edits when he runs ant - if someone uses Eclipse to debug or develop mkgmap the file is not build, probably the same problem in other IDEs Any hints how to solve this? Gerd

2 1

Commit r4435: reduce line distortion:
by svn commit 03 Feb '20

03 Feb '20

Version mkgmap-r4435 was committed by gerd on Mon, 03 Feb 2020 reduce line distortion: - in some cases a junction of a routable line and a non-routable line was split. E.g. when a footway ends on barrier=fence line. - POIs for barrier=* nodes are less often somewhere next to the way instead of on the way. This is not done when a straight highway would zig-zag so that the barrier is on the way. In that case the highway stays straight and the barrier node is still placed next to the way. See also http://gis.19327.n8.nabble.com/distorted-lines-again-tp5957394.html http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4435

1 0

distorted lines again
by Gerd Petermann 02 Feb '20

02 Feb '20

Hi all, as Eric pointed out (1) in rare cases connected ways are rendered as unconnected ways. Reason is an error in WrongAngleFixer which treats roads and lines one after the other. Another problem I found are POIs which created with the --link-pois-to-ways option (nodes with barrier=* or highway=*) . Sometimes the POIs are rendered a few meters away from the way. In opposite to the problem reported by Eric this seems to happen quite often. I've attached my test file with a few special cases that I found and the grid of Garmin points for this area as well as a screenshot from GpsMapEdit. I am working on a better handling of these special cases. I've already found a solution reg. the rendering, still testing the effects on routing... ciao, Gerd (1) http://gis.19327.n8.nabble.com/Connected-ways-rendered-as-Unconnected-ways-…

1 0

Commit r4434: remove :: from pre-formatted section in documentation
by svn commit 31 Jan '20

31 Jan '20

Version mkgmap-r4434 was committed by gerd on Fri, 31 Jan 2020 remove :: from pre-formatted section in documentation http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4434

1 0

Splitter Build Failure
by News 30 Jan '20

30 Jan '20

I recently clean reinstalled my PC (openSuSE Leap 15.1) and today was the first time I tried to build splitter and received the following errors BUILD FAILED /home/miscellaneous/Maps/tile-splitter/splitter/build.xml:95: Can't get http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.2.0/ivy-2.2.0.jar to /home/miscellaneous/Maps/tile-splitter/splitter/lib/build/ivy-2.2.0.jar I changed the line in build.xml to use https instead of http and I then got past this error and received the following error snippet [ivy:retrieve] :::::::::::::::::::::::::::::::::::::::::::::: [ivy:retrieve] :: UNRESOLVED DEPENDENCIES :: [ivy:retrieve] :::::::::::::::::::::::::::::::::::::::::::::: [ivy:retrieve] :: xpp3#xpp3;1.1.4c: not found [ivy:retrieve] :::::::::::::::::::::::::::::::::::::::::::::: [ivy:retrieve] :::: ERRORS [ivy:retrieve] SERVER ERROR: HTTPS Required url=http://repo1.maven.org/maven2/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.pom [ivy:retrieve] SERVER ERROR: HTTPS Required url=http://repo1.maven.org/maven2/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.jar So it seems that maven.org is only accepting https connections but I can't find where to correct the above error Any suggestions? Thanks Paul

4 6

Commit r4433: improve documentation (Patch by Mike Baggaley)
by svn commit 30 Jan '20

30 Jan '20

Version mkgmap-r4433 was committed by gerd on Thu, 30 Jan 2020 improve documentation (Patch by Mike Baggaley) TODO: add program to compile help/en/options from doc/options.txt during the build process http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4433

1 0

documentation improvement patch
by Mike Baggaley 30 Jan '20

30 Jan '20

Hi Gerd, I have attached a patch to improve the documentation of the command line. I did it some time ago and had forgotten about it, but the discussion on whether to change default options prompted me to come back to it. The change is purely to the documentation, no code changes. Please review and if it meets with your approval, commit. Thanks, Mike

6 28

A highway is not always and not by all styles Rendered ON a bridge.
by AnkEric 29 Jan '20

29 Jan '20

In my "own" style (Bicycle / Hiking - map) sometimes (only sometimes!) a highway is not Rendered ON a bridge. The "missing" highway is not visible, but it is routable! <http://gis.19327.n8.nabble.com/file/t344065/MKGMAP_highway_not_rendered_on_…> Both default-Style and OFM-Style are OK: <http://gis.19327.n8.nabble.com/file/t344065/MKGMAP_OFM_highway_IS_rendered_…> My uneducated guess: - the highway (having [layer=1]) is rendered on a layer below the bridge (also having [layer=1]). - 2x OK-bridge is not crossing a waterway (so [layer=1] is sometimes considered to be not required, needless) - 1x NOT-OK-bridge IS crossing a [waterway=canal]. [layer=1] on bridge IS required and therefore (???) NOT rendered oké ??? MKGMAP_highway_not_rendered_on_bridge.osm <http://gis.19327.n8.nabble.com/file/t344065/MKGMAP_highway_not_rendered_on_…> / Eric (AnkEric) -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

2 2