- mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] TYP files and character encoding
by Ticker Berkin 17 Jan '20

17 Jan '20

Hi Gerd Here is typCodePage_v4 that uses try () in both CharsetProbe and compile, getting rid of Utils.closeFile(). The patch includes the change in typCodePage-test.patch My javac doesn't seem to have an option to detect unused imports, but when I run it with -Xlint I get a variety of errors - I've attached the log. Ticker On Fri, 2020-01-17 at 11:13 +0000, Gerd Petermann wrote: > Hi Ticker, > > I use Eclipse with customized settings in Preferences -> Java > ->Compiler-> Error/Warnings as well as the SonarLint plugin. > > My understanding is that the InputStream is only closed if everything > goes well. The nature of unit tests is that they produce special > cases". > The try-with-ressources was introduced to handle this. > Maybe you can post a v4 which uses try-with-ressources in class > CharsetProbe (as the unpatched version does)? > > Gerd > > > ________________________________________ > Von: Ticker Berkin <rwb-mkgmap(a)jagit.co.uk> > Gesendet: Freitag, 17. Januar 2020 11:54 > An: Gerd Petermann > Betreff: Re: AW: AW: [mkgmap-dev] TYP files and character encoding > > Hi Gerd > > I have another patch almost ready for the StandardCharset utf8 / try > (with-resources) etc, but this is quite wide-ranging and unrelated to > the need for the typCodePage patch. > > I wanted to get the typCodePage patches committed first so that I can > get on with mapnik.txt patches and also improve some bits of > TypCompiler as the last part of the utf8 patch. > > My compilation system doesn't warn about unused imports - what > options/tool do you use for this? > > Concerning the close, the FileInputSteam is closed, which should > release any OS file handle; it's just the InputSteamReader & > BufferedReader that arn't, but these are just java data structures. > > Ticker > > On Fri, 2020-01-17 at 10:27 +0000, Gerd Petermann wrote: > > Hi Ticker, > > > > ah, seems I got another post wrong. I thought you'd work on a > > typCodePage_v4.patch which would use try-with-ressources. > > With typCodePage_v3.patch and typCodePage-test.patch I still see > > some warnings for TypCompiler: > > - unused imports > > - br is not closed (line 232) > > > > Gerd > > > > ________________________________________ > > Von: Ticker Berkin <rwb-mkgmap(a)jagit.co.uk> > > Gesendet: Freitag, 17. Januar 2020 10:17 > > An: Gerd Petermann > > Betreff: Re: AW: [mkgmap-dev] TYP files and character encoding > > > > Hi Gerd > > > > Yes. Sorry - I didn't explain it at all well. This needs to be > > applied > > at the same time as typCodePage_v3.patch from 14-Jan > > > > Ticker > > > > On Fri, 2020-01-17 at 08:48 +0000, Gerd Petermann wrote: > > > Hi Ticker, > > > > > > I don't understand this patch. Do I have to use it in combination > > > with another one? > > > > > > Gerd > > > > > > ________________________________________ > > > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im > > > Auftrag > > > von Ticker Berkin <rwb-mkgmap(a)jagit.co.uk> > > > Gesendet: Freitag, 17. Januar 2020 00:02 > > > An: Development list for mkgmap > > > Betreff: Re: [mkgmap-dev] TYP files and character encoding > > > > > > Hi Gerd > > > > > > I've just noticed that a change to a function profile stopped a > > > test > > > from compiling, so here is a patch for that > > > > > > Ticker

2 2

Commit r4425: Fix problems introduced with changes in the NET-no-NOD branch reg. routable maps at resolution 23 (merge in r4360):
by svn commit 17 Jan '20

17 Jan '20

Version mkgmap-r4425 was committed by gerd on Fri, 17 Jan 2020 Fix problems introduced with changes in the NET-no-NOD branch reg. routable maps at resolution 23 (merge in r4360): - Don't use --levels option given on command line when reading the style or processing the --check-styles option, only use it for warning when --routable is combined with --levels=0:23[,...] - New: When the style contains an options file that uses resolution 23 for level 0 the --check-styles option will report all lines which add objects with a minimum resolution of 24. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4425

1 0

Commit r4424: see r4423, forgot changed unit test
by svn commit 17 Jan '20

17 Jan '20

Version mkgmap-r4424 was committed by gerd on Fri, 17 Jan 2020 see r4423, forgot changed unit test http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4424

1 0

Commit r4423: improve *.typ file handling (Patch typCodePage_v4.patch by Ticker Berkin with small modifications)
by svn commit 17 Jan '20

17 Jan '20

Version mkgmap-r4423 was committed by gerd on Fri, 17 Jan 2020 improve *.typ file handling (Patch typCodePage_v4.patch by Ticker Berkin with small modifications) - revert changes from r4395 - implement various BOM checks - don't warn if codePage in *.typ differs from --code-page option - don't stop if strings cannot be written with the codepage given, just log a warning and ignore the string http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4423

1 0

Level number too large
by Andrzej Popowski 16 Jan '20

16 Jan '20

Hi All, since something is wrong with downloads on mkgmap site, I have compiled version 4419. I guess this is the latest official release. Now with some old maps I get a new error: Error in style: Error: Level number too large, max=0 I guess this is a conflict between arguments: levels=0:24 and style with declarations like: .... [... level 3] In my opinion, this should be no error, as it wasn't in older versions of mkgmap. It is harmless and quite useful, that style defines higher levels then a particular map compiled with the style. I have attached a patch, but I'm not sure what I'm really changing. Please look at it. -- Best regards, Andrzej

2 9

Commit r4420: The ivy/maven repository is now https only
by svn commit 15 Jan '20

15 Jan '20

Version mkgmap-r4420 was committed by steve on Wed, 15 Jan 2020 The ivy/maven repository is now https only http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4420

1 0

Elevation data just partially accessable by Basecamp
by Karl-Heinz Kühnlein 14 Jan '20

14 Jan '20

Hi all, I recently tried to add DEM data to my OSM maps for Garmin. At a first look all was fine, hill shading and 3D viewing was amazing in any case. Then I had issues that Basecamp (4.7.1) can only access elevation data when the map is on an USB stick as an image. Here elevation data is display besides the Lat/Lon for the coursor position and created tracks have elevation data. When I generate these maps in .gmap format or install (large) maps by registry (gmaptool 0973) the DEM data seems to be included in the map, because Hill Shading as well as 3D Viewing works fine, but in Basecamp created tracks do not have elevation information and the coursor position (bottom left corner) shows only Lat/Lon but no elevation. I created a small map (50 km radius) to figure out working with DEM data. This map works well on USB stick as image and even when installed by registry. When generated in .gmap format it shows the mentioned issues. I also created larger maps (whole Germany, whole Alps) which only worked with full access to elevation data on USB stick, coursor elevation displayed and track elevation data included. But same issue when installed by registry or .gmap format. What's wrong here? Are there size limitations for DEM data? Is there a difference between image on USB and the other installation options? Thank you for any hint to solve this issue and by the way for your great job on developing this software! Kind Regards Kalle Environment: mkgmap 4398, Basecamp 4.7.1 mkgmap options: fly-for-fun.de/mkgm1267/02_run_mkgmap.bat style/typ: fly-for-fun.de/mkgm1267/kk-style.7z maps: fly-for-fun.de/mkgm1267/KK_MiFra_DEM.gmap.7z fly-for-fun.de/mkgm1267/kk_MiFra_DEM.img

4 22

is_in test cases v4
by Gerd Petermann 13 Jan '20

13 Jan '20

Hi all, I've added a few more special cases and changed b18 to expected=? The case with w45 (spike in landuse=residential polygon) is not yet working, but I assume I will simply ignore it. Gerd

2 1

Re: [mkgmap-dev] [mkgmap-svn] Commit r4417: Improve IsInFunction:
by Ticker Berkin 13 Jan '20

13 Jan '20

Hi Gerd This looks to be much better than my solution (FeatureKind vs. isLineRule) Ticker On Sun, 2020-01-12 at 16:28 +0000, svn commit wrote: > Version mkgmap-r4417 was committed by gerd on Sun, 12 Jan 2020 > BRANCH: is-in > Improve IsInFunction: > partly revert 4412: We need the information about the source before > the style is compiled in RuleSet.compile() > This is quite tricky: > RuleSet.compile() deduplicates instances of a function with the > toString() result. So, if we want different instances of this > function we must make sure that they don't produce the same result in > toString(). > - Handle more edge cases like element equals hole > > > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4417 > _______________________________________________ > 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

1 0

Re: [mkgmap-dev] MKGMAP lost precision.
by Gerd Petermann 09 Jan '20

09 Jan '20

Hi John, please use r4406 or later, see also http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4405 http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4406 Should have seen this problem before, seems I looked only at routing / search issues before committing r4360 :( Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen(a)hotmail.com> Gesendet: Mittwoch, 8. Januar 2020 18:56 An: john(a)the-thorns.org.uk Betreff: AW: MKGMAP lost precision. Hi John, thanks for reporting. I can reproduce the error but I do not yet see where it is. Looks like mkgmap is dropping on point in each shape. Will have a closer look tomorrow. Gerd ________________________________________ Von: John Thorn <johnrthorn(a)gmail.com> Gesendet: Mittwoch, 8. Januar 2020 18:04 An: Gerd Petermann Betreff: MKGMAP lost precision. Hi Gerd, I decided it was time to install a more recent version of MKGMAP. I have been running 4286 but downloaded 4398. My maps contain the Microsoft/Bing building outlines for the US so I am using Level0=24. With 4286 the result is good (screenshot 704) with 4398 the rectangles have become triangles as if precision is being lost (705). I am compiling from .MP files and a typical building is : [POLYGON] ; RhodeIsland.geojson 161666 EndLevel=3 Type=0x13 Data0=(41.682688,-71.277508),(41.682688,-71.277476),(41.682596,-71.277476),(41.682596,-71.277366),(41.682748,-71.277366),(41.682748,-71.277508),(41.682688,-71.277508) [END] Regards, John

1 0