January 2020 - mkgmap-dev - The mkgmap lists

precompiled sea
by Mike Baggaley 18 Mar '20

18 Mar '20

Hi, I have not used precomp sea before and am struggling to compile the sea tiles. Using the following process I get a map with no sea: Used osmfilter to extract just the coastline data Used splitter on the coastline data Used mkgmap on the splitter data with a simple style that just processes coastline and with --generate-sea=multipolygon. I can see some img files created in my sea folder Used splitter again on the original data Used mkgmap again with --precomp-sea and --generate-sea=multipolygon Am I doing something wrong? Regards, Mike

3 13

Connected ways rendered as Unconnected ways due to Garmin low resolution
by AnkEric 19 Feb '20

19 Feb '20

Hi All, Minor, but irritating and hard to find issue. I have searched in Archive for "Unconnected ways", but I cannot find any relevant postings on the subject. Issue: in JOSM we can and should map accurately. A roundabout is a circle (Create Circle), a building is a rectangle (Orthogonalize Shape). Looking at the Map in https://www.openstreetmap.org/ it's perfect, in OsmAnd it's rather oké, but MkgMap on Garmin Device (or BaseCamp) is a "sloppy" polygon. More important: connected highways are sometimes (sometimes!) rendered as not connected. Therefore routing is not possible because of "Unconnected ways". These exceptions are hard to find (for me it is). Validation Tools (JOSM, Osmose, OSMI, Keep Right) won't find these errors because on OSM it's oké. One example: <http://gis.19327.n8.nabble.com/file/t344065/MKGMAP_NOT_Connected_highways.p…> To resolve (IF I do find an exception): - and/or: Simplify ways, most specific for a roundabout (8 nodes is preferred to 16 nodes). - and/or: Move the Connecting node (which is Unconnected on the Map) very slightly. Small, minor move is always enough to resolve. Also: Rendering can resolve. If the issue does occur on a bicycle map (highways are rendered by narrow lines) than the issue will not occur if the width of a highway is rendered larger (on a Motorcar/general map). I'm prepared for an answer like: "This is Garmin, not MkgMap!" Or is something like "snap to grid" an option for MkgMap to resolve by a work-around? Or improved logging of exceptions? If I can find these "errors" I can resolve! Most annoying (for me): my attempts to improve card quality leads to "routing errors". / Eric (AnkEric) -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

2 5

Error in memory calculation
by Gerd Petermann 07 Feb '20

07 Feb '20

Hi Ticker, please try this command with openjdk 11 or 13 64Bit: java -Xms4G -Xmx10G -jar mkgmap.jar f:\osm\dummy.osm f:\osm\dummy.osm f:\osm\dummy.osm This is what I get: Time started: Fri Jan 31 17:12:53 CET 2020 Setting max-jobs to 1 Number of MapFailedExceptions: 0 To reduce the run time, consider increasing the amnount of memory available for use by mkgmap by using the Java -Xmx flag to set the memory to more than 41000 MB, providing this is less than the amount of physical memory installed. Number of ExitExceptions: 0 Time finished: Fri Jan 31 17:12:54 CET 2020 Total time taken: 1 second Seems that MemoryPoolMXBean.getPeakUsage() returns other values than Oracles JRE. Gerd

4 9

Branch is_in ready for a first test
by Gerd Petermann 05 Feb '20

05 Feb '20

Hi all, the branch version r4408 implements the style function is_in with three parameters tag-key,tag-value,method - tag-key can be something like landuse or natural or amenity - tag-value would be the expected value for that tag-key - method has to be "any" or "all". Example usage in lines: # no cycling within a cemetery highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add bicycle=dismount} Before any style rule is evaluated the function evaluates the list of all ways found in the input file. When a way matches the given tag (key+value) and is closed and complete the shape geometry is stored in a spatial index. With the current implementation this index is created for appearance of the is_in function in a style rule (subject to optimization) When the style function is called it retrieves the stored shape(s) which intersect the boundary of the element. If none is found "false" is returned. If there are multiple such shapes the are merged where possible, so that overlapping or touching shapes are combined to a single shape which may include holes. The list of (outer) shapes is then tested one after the other until one shape is found which either contains the element completely or - when "any" is used as method - partially. If none is found the value "false" is returned. If a match is found and the combined shapes have holes, a final test is done to find out if the element is within the hole. If method "any" is used and the shape is completey within one hole "false" is returned. If method "all" is used and the shape is partly within one hole "false" is returned. If we get here true is "returned" I've also slightly changed the behaviour of the LocationHook and the ResidentialHook. The results should be a bit more predictable now as searches are done with higher precsion. Still, both try to find a nearby boundary(shape) if none is found at the exact position. The ResidentialHook is now automatically disabled when the style doesn't use mkgmap:residential anywhere. TODO: - various possible special cases need more testing - maybe add more methods for cases where parts of the tested element touch the boundary of the shape. - tuning - unit tests As always with branch version the binary can be found at the bottom of the download page. http://www.mkgmap.org.uk/download/mkgmap.html I've tested this with the example file posted before, accept for b18 all cases work as expected. Gerd

8 34

Re: [mkgmap-dev] Squaring off of land outlines
by Mike Baggaley 05 Feb '20

05 Feb '20

Brilliant! A big improvement! It still doesn't exactly match the land polygon, but that doesn't matter for my purposes. I suggest changing the to do list so it says use the same algorithm for shapes, lines and sea. I also suggest adding a sentence to the style manual in the explanation of mkgmap:skipSizeFilter - the description doesn't explain the purpose or what the effect is of passing the size filter. Thanks for your assistance, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 January 2020 19:03 To: Mike Baggaley <mike(a)tvage.co.uk> Subject: AW: [mkgmap-dev] Squaring off of land outlines Hi Mike, some small rather small sea polygons are filter by the size filter. Change the statememnt for sea polygons to this: natural=sea {add mkgmap:skipSizeFilter=true; name '${name}'} [0x32 resolution 14] See also the corresponding rule in the default style: natural=sea {add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2} [0x32 resolution 10] Gerd ________________________________________ Von: Mike Baggaley <mike(a)tvage.co.uk> Gesendet: Dienstag, 28. Januar 2020 19:39 An: 'Gerd Petermann' Betreff: RE: [mkgmap-dev] Squaring off of land outlines Thanks Gerd. I has been considering trying to find the problem myself, but I'm not familiar with the writing sections of code, and they are complicated to get to grips with. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 January 2020 16:16 To: Mike Baggaley <mike(a)tvage.co.uk>; 'Development list for mkgmap' <mkgmap-dev(a)lists.mkgmap.org.uk> Subject: AW: [mkgmap-dev] Squaring off of land outlines Hi Mike, okay, I'll have a closer look now. Gerd ________________________________________ Von: Mike Baggaley <mike(a)tvage.co.uk> Gesendet: Dienstag, 28. Januar 2020 16:51 An: 'Gerd Petermann'; 'Development list for mkgmap' Betreff: RE: [mkgmap-dev] Squaring off of land outlines Hi Gerd, the problem I have is not the one in the to do list. If I add the polygon fill for natural=coastline, this does produce a different outline than the one for the line, but both are reasonable approximations and neither contains unexpected artefacts. The sea generation approximation is wildly different and contains unwanted artefacts. Please see the attached image that contains land in brown, sea in blue and an area of white that is not filled by either. I believe this is a bug in the sea generation code. I would expect sea generation to use the same algorithm as for filled areas so that holes are not left. I'm not too worried about the line being slightly different. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 January 2020 14:59 To: Mike Baggaley <mike(a)tvage.co.uk>; 'Development list for mkgmap' <mkgmap-dev(a)lists.mkgmap.org.uk> Subject: AW: [mkgmap-dev] Squaring off of land outlines Hi Mike, See last point in the todo list: http://www.mkgmap.org.uk/dev/todo I think what you see is exactly the result of the two different algos. I can only suggest to omit the rendering of polygon outlines at resolutions below 24. ________________________________________ Von: Mike Baggaley <mike(a)tvage.co.uk> Gesendet: Dienstag, 28. Januar 2020 15:23 An: 'Gerd Petermann'; 'Development list for mkgmap' Betreff: RE: [mkgmap-dev] Squaring off of land outlines Hi Gerd, I have produced a small sample which demonstrates the problem. It contains one very small island. I have cut down the style to a bare minimum with just two resolutions: 24 and 14 containing just sea and a coastline outline. At resolution 24 the sea and coastline are coincident. At 14, they are wildly different. The coastline at low resolution includes a spur which is a complication. The ideal sea boundary would be the same as the coastline, but with the spur removed (or perhaps the spur should not be on the coastline either). I have included the style, typ file, command line in a batch file and osm data in the attached zip. Please let me know if you need anything else. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 January 2020 08:26 To: Mike Baggaley <mike(a)tvage.co.uk>; 'Development list for mkgmap' <mkgmap-dev(a)lists.mkgmap.org.uk> Subject: AW: [mkgmap-dev] Squaring off of land outlines Hi Mike, I can try to find out what's wrong but I would need a lot more details about your map creation process. Could be an error in mkgmap or in the OSM data or in the --levels option or in the --min-size-polygon option or --polygon-size-limits or ... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike(a)tvage.co.uk> Gesendet: Montag, 27. Januar 2020 19:07 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] Squaring off of land outlines HI Gerd, I don't have an old map, but this has been happening for some time - I am not sure whether it has always done this, but thought it would be worth trying a few old versions to see whether it is bug that got introduced, or is one that has always been there. It looks similar to the problem reported on Feb 18 2017 with "Terraced/pixellated coastline with --precomp-sea" as the title. I am not using --precomp-sea, but the problem I am getting is also in the sea outline. NopMap indicated that his problem was fixed in r3819, however, I have downloaded the source to that version and compiled it, and it exhibits the same problem for me. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 27 January 2020 08:36 To: 'Development list for mkgmap' <mkgmap-dev(a)lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Squaring off of land outlines Hi Mike, I am not aware of a folder that keeps all older releases or an error that would be related to this. Are you sure that you didn't change mgkmap options like --levels or the style or the typ file? Do you still have a map which looks better? In that case you should find the string mkgmap in the img file, e.g. "mkgmap-r4431" Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike(a)tvage.co.uk> Gesendet: Montag, 27. Januar 2020 01:43 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] Squaring off of land outlines Hello, I am getting squaring off of the outline between land and sea at low zoom levels (less than 16) - see attached BaseCamp images of Gran Canaria at resolution 16 and at resolution 14 displayed at the same size. Obviously some reduction in accuracy is expected at lower zoom level, but not these artefacts. I'm not sure when this started happening but believe it was some time ago. I can't seem to find the old releases to try previous versions, http://svn.mkgmap.org.uk/mkgmap/releases/ just shows me an empty folder. Can you point me to the correct download folder that contains the previous jar files, and/or let me know if this is a known problem, and if so whether there is a workaround? Thanks, Mike _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

5 13

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 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