May 2018 - mkgmap-dev - The mkgmap lists

Commit r4189: img_io_5.patch by Ticker Berkin
by svn commit 14 May '18

14 May '18

Version mkgmap-r4189 was committed by gerd on Mon, 14 May 2018 img_io_5.patch by Ticker Berkin http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4189

1 0

Use both addr:city and admin_level as city for address search
by Lorenzo Mastrogiacomi 14 May '18

14 May '18

Usually (in Italy) the municipality name is used as city in composing the address but it often happens that within the municipality there are other main towns which names are used instead. I want this addresses to be searchable with both the municipality name (admin_level=8) and the city name when it differs (tagged with addr:city=*). I use the default style with little modifications and added this rules in the points file. On top, first create a "fake" object only for searching, which will be matched by default rules in address file, so these will have admin_level8 as mkgmap:city. addr:city=* & 'addr:city'!='mkgmap:admin_level8' [0x3200 continue with_actions] Then set mkgmap:city with the addr:city value to have this as city for the following matches. addr:city=* & 'addr:city'!='mkgmap:admin_level8' { set mkgmap:city='${addr:city}' } I also added modified the rule at the bottom to avoid "fake" objects to get a name and show on the map. !(addr:city=* & 'addr:city'!='mkgmap:admin_level8' & mkgmap:city!=*) & name=* { name '${name}' } This seems to work pretty well but it looks rather complicated. I wonder if there is a better way to do this. Any thoughts? These are my options: --style-file=$style_reg \ --latin1 \ --country-name=Italia \ --country-abbr="$abbr" \ --region-name="$nome_reg" \ --area-name="$nome_reg" \ --family-name="OpenStreetMap: Mappe regionali ital.img" \ --description="$nome_reg" \ --series-name="$serie" \ --precomp-sea=${MYPATH}/sea/ \ --generate-sea \ --bounds=${MYPATH}/bounds/ \ --max-jobs \ --route \ --drive-on=detect,right \ --process-destination \ --process-exits \ --location-autofill=is_in,nearest \ --index \ --split-name-index \ --housenumbers \ --add-pois-to-areas \ --link-pois-to-ways \ --preserve-element-order \ --verbose \ --name-tag-list=name,name:it,loc_name,reg_name,nat_name \ --draw-priority=$priority \ --reduce-point-density=3.2 \ --make-opposite-cycleways \ --gmapsupp Lorenzo

3 5

Commit r4188: Fix problem with JRE 10 and newer:
by svn commit 13 May '18

13 May '18

Version mkgmap-r4188 was committed by gerd on Sun, 13 May 2018 Fix problem with JRE 10 and newer: The ZipFile constructor throws NoSuchFileException instead of FileNotFoundException when a file doesn't exist. As a result mkgmap prints missleading error messages like "failed to get size for file N52E002.hgt from f:\srtm3\N52E002.hgt.zip" Now mkgmap first checks if the file exists before trying to open it as a ZipFile. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4188

1 0

openjdk 8 vs openjdk 10
by Bernd Weigelt 13 May '18

13 May '18

Hi got these message when i use openjdk10 to create the map. openjdk 8 is patchlevel 161, which has errors in JavaFX, so i changed to openjdk 10 for tests Both files didn't exist, because they are complete in the north sea II: building basemap Time started: Sat May 12 09:14:02 CEST 2018 SCHWERWIEGEND (HGTReader): /home/bernd/map_build/tiles/65030345.o5m: failed to get size for file N52E003.hgt from /home/bernd/map_build/hgt/COPERNICUS/ N52E003.hgt.zip SCHWERWIEGEND (HGTReader): /home/bernd/map_build/tiles/65030345.o5m: failed to get size for file N52E003.hgt from /home/bernd/map_build/hgt/COPERNICUS/ N52E003.zip SCHWERWIEGEND (HGTReader): /home/bernd/map_build/tiles/65030345.o5m: failed to get size for file N52E003.hgt from /home/bernd/map_build/hgt/VIEW1/ N52E003.hgt.zip SCHWERWIEGEND (HGTReader): /home/bernd/map_build/tiles/65030345.o5m: failed to get size for file N52E003.hgt from /home/bernd/map_build/hgt/VIEW1/N52E003.zip SCHWERWIEGEND (HGTReader): /home/bernd/map_build/tiles/65030345.o5m: failed to get size for file N52E003.hgt from /home/bernd/map_build/hgt/VIEW3/ N52E003.hgt.zip SCHWERWIEGEND (HGTReader): /home/bernd/map_build/tiles/65030345.o5m: failed to get size for file N52E003.hgt from /home/bernd/map_build/hgt/VIEW3/N52E003.zip SCHWERWIEGEND (HGTReader): /home/bernd/map_build/tiles/65030398.o5m: failed to get size for file N55E007.hgt from /home/bernd/map_build/hgt/COPERNICUS/ N55E007.hgt.zip SCHWERWIEGEND (HGTReader): /home/bernd/map_build/tiles/65030398.o5m: failed to get size for file N55E007.hgt from /home/bernd/map_build/hgt/COPERNICUS/ N55E007.zip SCHWERWIEGEND (HGTReader): /home/bernd/map_build/tiles/65030398.o5m: failed to get size for file N55E007.hgt from /home/bernd/map_build/hgt/VIEW1/ N55E007.hgt.zip SCHWERWIEGEND (HGTReader): /home/bernd/map_build/tiles/65030398.o5m: failed to get size for file N55E007.hgt from /home/bernd/map_build/hgt/VIEW1/N55E007.zip SCHWERWIEGEND (HGTReader): /home/bernd/map_build/tiles/65030398.o5m: failed to get size for file N55E007.hgt from /home/bernd/map_build/hgt/VIEW3/ N55E007.hgt.zip SCHWERWIEGEND (HGTReader): /home/bernd/map_build/tiles/65030398.o5m: failed to get size for file N55E007.hgt from /home/bernd/map_build/hgt/VIEW3/N55E007.zip Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Time finished: Sat May 12 09:53:36 CEST 2018 Total time taken: 39 minutes 33 seconds This ist the output from openjdk8 with the same tiles from splitter, openjdk 8 is much faster and there are no messages II: building basemap Time started: Sat May 12 10:28:36 CEST 2018 Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Time finished: Sat May 12 10:56:13 CEST 2018 Total time taken: 27 minutes 36 seconds Bernd

2 2

status of patches and overlaps branch
by Gerd Petermann 08 May '18

08 May '18

Hi all, a few patches were not yet committed: expr-func2.patch area_size.patch If I here no complains I'll commit them on Friday. I'd also like to hear if the changes in the overlaps branch helped anyone. The coding is more or less done, I droped my plans regarding self overlapping ways because they are hard to create and thus very unlikely. If nobody sees improvements, I don't plan to merge this branch to trunk, else I'll add some unit tests. Gerd [1] http://gis.19327.n8.nabble.com/Error-in-my-style-with-Version-mkgmap-r4136-… [2] http://gis.19327.n8.nabble.com/Example-of-logging-Echotags-to-file-tp591439…

3 3

Commit r4186: mdr20.patch: The mdr20 index did not contain enough entries when same combination of road name + city + region + country appear in different tiles.
by svn commit 06 May '18

06 May '18

Version mkgmap-r4186 was committed by gerd on Sun, 06 May 2018 mdr20.patch: The mdr20 index did not contain enough entries when same combination of road name + city + region + country appear in different tiles. As a result, some housenumbers are not found for those roads. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4186

1 0

problem with address search with *mp sources
by Andrzej Popowski 06 May '18

06 May '18

Hi, when compiling a map from *.mp sources, address search doesn't work as expected in Mapsource. I have prepared a set of data for testing: http://files.mkgmap.org.uk/download/433/test-index.zip I can't get correct results, when searching for address: house number: 75 street: KARTUSKA city: GDANSK It looks like a whole set of numbers is missing in search index for KARTUSKA. I think that some street names are missing too, but I haven't tested much. I have found that map created by mkgmap r3909 works correctly but r3970 gives problems. Somewhere between these releases was introduced a bug. Maybe it was because of merging optimize-index branch with release r3968? -- Best regards, Andrzej

2 3

Description is too long (max 50)
by Felix Hartmann 06 May '18

06 May '18

Exception in thread "main" java.lang.IllegalArgumentException: Description is too long (max 50) at uk.me.parabola.imgfmt.sys.ImgHeader.setDescription(ImgHeader.java:336) at uk.me.parabola.imgfmt.sys.ImgHeader.createHeader(ImgHeader.java:168) at uk.me.parabola.imgfmt.sys.ImgFS.createInitFS(ImgFS.java:372) at uk.me.parabola.imgfmt.sys.ImgFS.createFs(ImgFS.java:123) at uk.me.parabola.imgfmt.sys.ImgFS.createFs(ImgFS.java:102) at uk.me.parabola.imgfmt.app.map.Map.createMap(Map.java:99) at uk.me.parabola.mkgmap.combiners.OverviewBuilder.writeOverviewMap(OverviewBuilder.java:182) at uk.me.parabola.mkgmap.combiners.OverviewBuilder.onFinish(OverviewBuilder.java:104) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:678) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128) at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:143) at uk.me.parabola.mkgmap.main.Main.main(Main.java:114) I'm pretty sure that the --description value is well below 50 characters. However the area-name was 54 characters. Is the area-name also not allowed to be bigger? Also maybe the family name was 51 or 52 characters long. Or is this bug somewhere else? -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich

2 3

Commit r4185: tags5.patch: Improve the RuleIndex.
by svn commit 06 May '18

06 May '18

Version mkgmap-r4185 was committed by gerd on Sun, 06 May 2018 tags5.patch: Improve the RuleIndex. Attached patch reduces again the number of evaluated rules, but should still evaluates all necessary rules. The old index still returned too many rules. Let's look at the example that I added as unit test. Set of rules: 0: a=* {set b=1} 1: b=1 {set c=1} 2: d=2 {set c=2} 3: c=* {set a=2} 4: c=1 {set d=2} 5: c=2 {set d=1} 6: d=1 [0x10401 resolution 24] 7: d=2 [0x10402 resolution 24] Assume we have no index and an element with only one tag a=1. We check each rule: Rules 0 matches and sets b=1 Now 1 matches and sets c=1 Rule 2 doesn't match. Rule 3 matches and sets a=2 Rule 4 matches and sets d=2 Rule 5 doesn't match. Rule 6 doesn't match. Rule 7 matches. The index is used to reduce the number of evaluated rules. In the best case it should return rules 0,1,3,4, and 7 for the given element. But the current code returns all rules because it thinks that rule 4 can set d=2 and therefore rule 2 might be triggered (which is wrong). The patch changes the index to recognizes the order of the rules which change tags and therefore returns only the needed rules. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4185

1 0

Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?
by Frank Stinner 05 May '18

05 May '18

For my opinion your data sources are very interesting. This is a short look to the alps, the tile E40N20 from https://land.copernicus.eu/. There seem's to be a little problem at the near of some coastlines, but we have on the other hand a high resolution of 25m. I belive, a bigger problem is the coordinate reference system. Copernicus data have EPSG:3035, garmin use EPSG:4326. It would be fine, if mkgmap could be read geotiffs and calculate with different coordinate reference systems. This would perhaps collect the interpolation for changing the coordinate reference system and for the garmin map. On the other hand: this is a lot of mathematical stuff. I'm not a java hacker and i don't know, if there are usable geografic librarys for this work. At the moment we have to translate the tiffs from EPSG:3035 to EPSG:4326, then the segmentation in 1°x1° tiffs an at last the conversion to hgt files. This should not be a very great problem with gdal-tools or so, but it is additional work. Frank

5 13