- mkgmap-dev - The mkgmap lists

Commit r4448: fix possible NPE introduced with r4432
by svn commit 13 Feb '20

13 Feb '20

Version mkgmap-r4448 was committed by gerd on Thu, 13 Feb 2020 fix possible NPE introduced with r4432 FileNotFoundException was ignored. May result in a NullPointerException when input file is not in the expected format. e.g. with java -jar mkgmap.jar . http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4448

1 0

rounding hyper-accurate elevations ${ele}
by J J 12 Feb '20

12 Feb '20

I was slightly surprised when I discovered the altitude "241.934997558594" on my map. This is actually the hyper-accurate information from the database: https://www.openstreetmap.org/node/32969675 (there's any more such examples). Since I do not know the reason for this value, I don't want to change the database. Does mkgmap provide a function similar to Math.round() or should I simply use ${ele|part:".:1"} to skip the decimals?

3 3

Garmin Lines Visibility
by nwillink 12 Feb '20

12 Feb '20

Hi All Following from Jorics' response to Gerd have done some more research regarding lines on Basecamp: *Lines with non extended types* it seems that the highest line type is 0x3F Strangely Mapsource shows a repeat of lines 0 to 3F starting from 0x40 This looks like mkgmap allows such types but Garmin seems to set a 'flag' of some kind and regards 0x40 as 0x0 etc Not Visible : 0x17 , 0x 2c , 0x30 - 0x3F Not customisable Labels: 0x20 - 0x22 *Extended Lines* Not Visible : 0x10200 - 102FF , 1080e , 0812 - 1081f, 10b05-10b1f , 12e00 -anything higher No Labels : 0x10906 - 1091f , 10b02-10b04 <http://gis.19327.n8.nabble.com/file/t339487/lines.jpg> -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

5 7

Re: [mkgmap-dev] Error in memory calculation
by Mike Baggaley 11 Feb '20

11 Feb '20

>So, this is really a very special case. It happened for John Thorne who is >using several rather small *.mp files as input, but I think it can also >occur for others when the first input file is a typ file in *.txt format. I can't see any reason for typ file compilation to be included in the list of files to be processed as separate tasks, as the time taken is negligible. If typ files were processed immediately, then there would not be an issue with typ compilation being used for the calculation of a memory requirement which is unsuitable for subsequent img file generation. Regards, Mike

2 2

Problems with mails
by Gerd Petermann 11 Feb '20

11 Feb '20

Hi all, this is a test. I received an error message for my last responses to the list from my (?) mail provider: Generierender Server: HE1EUR02HT004.mail.protection.outlook.com mkgmap-dev(a)lists.mkgmap.org.uk Remote Server returned '550 5.7.520 Message blocked because it contains content identified as spam. AS(4567)' Gerd

1 0

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

Re: [mkgmap-dev] [mkgmap-svn] Commit r4439: merge from trunk r4437
by jan meisters 07 Feb '20

07 Feb '20

After running r4439 I found a new folder in my working directory named e/, inside some gpx files. What is the need of these? Attached examples result from rendering RegBez. Koeln <http://download.geofabrik.de/europe/germany/nordrhein-westfalen/koeln-regbe…>. Jan > Am 06.02.2020 um 17:44 schrieb svn commit <svn(a)mkgmap.org.uk>: > > Version mkgmap-r4439 was committed by gerd on Thu, 06 Feb 2020 > BRANCH: is-in > merge from trunk r4437 > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4439 > _______________________________________________ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-leave(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn

2 1

Re: [mkgmap-dev] Error in memory calculation
by Gerd Petermann 05 Feb '20

05 Feb '20

Hi Manfred, mkgmap contains code to estimate a suitable value for max-jobs if this parameter isn't set. This code fails and the result is that it believes that a first thread needed all available memory. This doesn't happen when the -Xms parameter in my sample call is removed, and it also doesn't happen with JRE 1.8 (both from OpenJDK and Oracle). I've not yet started to look at the details returned in class java.lang.management.MemoryPoolMXBean Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von DD8KQ <dd8kq(a)gmx.de> Gesendet: Mittwoch, 5. Februar 2020 21:16 An: mkgmap-dev(a)lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Error in memory calculation Hi Gerd i'm not sure what you are looking for. In my build environment i'm using java 1.8.0_241 (64 bit) and as my laptop have 32 Gb of memory availiable my command line to build is like this : java -Xmx30000m -XX:-UseGCOverheadLimit -ea -jar -Dlog.config=logging.properties "c:\Program Files (x86)\KartenTools\mkgmap\mkgmap.jar" .... and depending on which map i want to build, the occupied memory runs up nearly to 30Gb Am 05.02.2020 um 14:05 schrieb Ticker Berkin: > Hi Gerd > > I don't have a 64bit environment or that much memory. In my normal > environment, I get: > > $ java -Xms1500M -Xmx1540M -jar ../mkgmap.trunk/mkgmap.jar \ > dummy.osm dummy.osm dummy.osm > Time started: Wed Feb 05 12:56:28 GMT 2020 > Setting max-jobs to 4 > Number of MapFailedExceptions: 0 > Number of ExitExceptions: 0 > Time finished: Wed Feb 05 12:56:29 GMT 2020 > Total time taken: 1 second > > -Xmx1540M is the maximum value that allows Java to start up on my > machine. > > With a newer version I loaded in October, but it didn't have any > obvious advantages: > > $ /opt/jre1.8.0_231/bin/java -Xms1500M -Xmx1540M \ > -jar ../mkgmap.trunk/mkgmap.jar \ > dummy.osm dummy.osm dummy.osm > Time started: Wed Feb 05 12:58:29 GMT 2020 > Setting max-jobs to 4 > Number of MapFailedExceptions: 0 > Number of ExitExceptions: 0 > Time finished: Wed Feb 05 12:58:30 GMT 2020 > Total time taken: 1 second > > Ticker > > On Fri, 2020-01-31 at 16:15 +0000, Gerd Petermann wrote: >> 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 > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- ##################################################### Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhaiduk(a)t-online.de dd8kq(a)gmx.de ##################################################### _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

3 3

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