- mkgmap-dev - The mkgmap lists

Line simplification in phyghtmap
by Gerd Petermann 13 Jul '18

13 Jul '18

Hi all, Adrian Dempwolf contacted me. He has added two options for line simplification. Maybe you want to test them. Ciao Gerd

2 2

Error in index
by Gerd Petermann 12 Jul '18

12 Jul '18

Hi all, I am back from my cycling tour. I've observed a problem with my self compiled gmapsupp, the device doesn't find most of the restaurant POIs. Search for e.g. shops or hotels worked fine, just POI with 0x2a?? seem to cause trouble. Search takes very long and shows only a few far away restaurants. I wonder if anybody else has the same problems? Gerd

6 10

DEM contrast option?
by jan meisters 09 Jul '18

09 Jul '18

I just made my first map with the new DEM-option and I´m impressed. Pretty easy. But I wonder why DEM shading looses contrast in higher resolutions in BaseCamp: My Style has background poly 4a and 4b (both transparent), however they are not mentioned in polygons. I wouldn´t know how to tag them anyway. And even with a completely blanked typ-file the difference is visible: HGT´s are 3“ data from viewfinderpanaramas.org To keep the contrasted DEM up to higher resolutions/zooms I played with all DEM-options from help, and also with transparencies, but that had no effect - the softer shading remains. I see the switch in Basecamp somewhere between assumed resolutions 20 and 22. How is this switch defined? Is there a value to adjust this? Jan

3 6

Need some information about routing
by Manfred Haiduk 07 Jul '18

07 Jul '18

Hi all I've stumbeled about a small routing problem. I do create two types of maps, one is called "myland" with nearly all informations to be found in OSM, the other is called "mystreet" which do mainly show all streets but less information about the surrounding. The two 'lines' files in the appropriate styles are nearly same, except that for the street map all the ways not suitable for automotive driving are not rendered. My question is, using the same destination in either map, the routing is slightly different in my Garmin 276Cx. For example, routing in the land map uses some grade1 tracks within a forest, the street map does not. But the tracks are to be find in both maps. Anyone an idea, why this is computed differently in the device ? See also attached pictures -- Mit freundlichen Grüßen ##################################################### Manfred Haiduk, Zum Fischbach 9, 52393 Hürtgenwald e-mail mhaiduk(a)t-online.de #####################################################

3 4

problem in basecamp with mkgmap POI indexing
by truecrhirst 11 Jun '18

11 Jun '18

hi i am using the mkgmap option --make-poi-index to try to index POI in a polish format to img files but after installing the end file "img" to garmin basecamp when search for a poi basecamp does not found the place except if the actual view of the map is on top of that place but out of that area can't found poi names -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

2 1

I would like a maxways parameter and associated code to limit the number of ways in a tile
by Randolph J. Herber 31 May '18

31 May '18

Dear Sirs: I have been trying to build a World map for use in Garmin's Mapsource. I have encountered cases where tiles had too many ways (also polygons and relations) for Mapsource to handle, even though the tile had a sufficiently small numbers for Mapsource. This is because the area had a large number of ways with only begin and end nodes. I can constrain the number of ways, etc., by constraining the number of nodes severely. This causes many more tiles. Above 2025 tiles in a map, Mapsource appears to fail. This code should parallel the code for maxnodes. Randolph J. Herber

3 8

Commit r4193: change prediction for std values
by svn commit 31 May '18

31 May '18

Version mkgmap-r4193 was committed by gerd on Thu, 31 May 2018 change prediction for std values More or less a copy of the changes in Frank Stinners program BuildDEMFile dated 2018-05-30. The algo looks even more complex now and even Frank says he's not happy with it, but it seems to be closer again to that used by Garmin. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4193

2 1

Re: [mkgmap-dev] DEM/Contourlines causing grey (empty) squares at the border of maps
by Felix Hartmann 31 May '18

31 May '18

actually using the area.poly created by mkgmap splitting the switzerland.osm.pbf by geofabrik did work (the resulting map is much bigger then however) - so the poly file does seem to have something to do with it.... On 30 April 2018 at 19:09, Felix Hartmann <extremecarver(a)gmail.com> wrote: > Hallo Peter, > Eher würden mich die Copernicus Daten der EU interessieren - hier bin ich > aber noch nicht richtig dahintergekommen wie ich die konvertieren soll. > > Also die hier: https://www.eea.europa.eu/data-and-maps/data/ > copernicus-land-monitoring-service-eu-dem > Oder sind dass genau jene die du mit OpenDEM meinst? > > die besten Daten sind IMHO derzeit: http://data. > opendataportal.at/dataset/dtm-germany > Aber die sind nur sehr begrenzt verfügbar. > > > > Die Quelle: > http://dwtkns.com/srtm30m/ > > scheint mir irgendwie auf die alten SRTM1v2.0 Daten Zugriff zu haben, oder > irre ich mich und es ist die v3.0?? > > On 30 April 2018 at 18:59, Peter Danninger <peter(a)danninger.eu> wrote: > >> Servus Felix, >> >> Ich hab auch mit diversen .hgt-Dateien experimentiert, >> für meine Javascript-Anwendung: >> http://peter.myds.me/HDS/Tipps_Tricks/GPS/GPXclean/GPXclean.html >> http://peter.myds.me/HDS/Tipps_Tricks/GPS/GPXclean/GPXcleanAdvanced.html >> >> Mein Ergebnis der .hgt-Tests: >> >> OpenDEM 1sec (Europa): sehr gut >> USGS_NASA 1sec: (sehr) gut >> Viewfinderpanoramas 1sec: relativ gut *) >> Viewfinderpanoramas 3sec: weniger gut *) >> >> *) aber ganz im Norden keine Alternative ??? >> >> Falls Du mit USGS_NASA-Dateien bzw. OpenDEM-Dateien >> testen willst .... fragen .... >> >> Ich habe ALLE .hgt getestet auf "void", "tooLow", >> "tooHigh", und fehlerhafte Werte auf Basis der >> Nachbarwerte korrigiert. >> >> Beispiel für den Alpenraum: >> >> // Alpen: korrigierte Dateien wegen zu niedrigem Höhenwert (< -5m) >> // >> // "N45E010.hgt", "N45E011.hgt", "N45E012.hgt", "N45E013.hgt", >> // "N45E014.hgt", "N44E008.hgt", "N44E009.hgt", "N44E010.hgt", >> // "N44E011.hgt", "N44E012.hgt", "N44E013.hgt", "N44E014.hgt", >> // "N43E005.hgt", "N43E006.hgt", "N43E007.hgt", "N43E009.hgt", >> // "N43E010.hgt", "N43E011.hgt", "N43E012.hgt", "N43E013.hgt" >> >> >> LG Peter >> >> >> Am 30.04.2018 um 17:19 schrieb Felix Hartmann: >> >>> But Europe continent map seems to be broken too... so it's not that >>> simple... I really don't know why alps is working and switzerland broken. >>> I'll try if the broken maps work if I exclude viewfinderpanoramas 1" data >>> and only use 3" data. >>> >>> On 30 April 2018 at 15:22, Felix Hartmann <extremecarver(a)gmail.com >>> <mailto:extremecarver@gmail.com>> wrote: >>> >>> I'm not fully sure it's because of the poly file - but it's clearly >>> not based on wrong/broken input data. I created the Alps and >>> Switzerland equally, and all of Switzerland is part of the Alps map >>> too. Alps work, Switzerland does not. Strangely though changing the >>> style-file a little - it may mean a map does not have the problem - >>> so I think it's maybe only partly related to the poly file? >>> >>> On 30 April 2018 at 15:04, Felix Hartmann <extremecarver(a)gmail.com >>> <mailto:extremecarver@gmail.com>> wrote: >>> >>> Hi Gerd - can you find a pattern here? >>> Folllowing are the polygons of 10 broken (out of a sample of 94 >>> rather "small" countries) poly files. >>> https://openmtbmap.orgbroken_contours.zip >>> <https://openmtbmap.orgbroken_contours.zip> >>> >>> it's >>> Germany, Bavaria, Czech, Finland, Niedersachsen, >>> Nord-Rhein-Westfalen, Poland, Paraguay, Romania >>> Switzerland, Sweden >>> >>> The remaining 84 countries work fine in Basecamp (leaves about >>> 60 countries which are usually pretty big and I did not care to >>> check as it means zooming in to 30km, sometimes 50km and pan >>> around all borders of the map in Basecamp to spot if it's >>> working or not). >>> >>> On 27 April 2018 at 09:27, Gerd Petermann >>> <gpetermann_muenchen(a)hotmail.com >>> <mailto:gpetermann_muenchen@hotmail.com>> wrote: >>> >>> Hi Felix, >>> >>> a convex polygons doesn't seem to solve it. I tried with the >>> attached and still see those problems :-( >>> >>> Gerd >>> >>> ________________________________________ >>> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk >>> <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag >>> von Gerd Petermann <gpetermann_muenchen(a)hotmail.com >>> <mailto:gpetermann_muenchen@hotmail.com>> >>> Gesendet: Freitag, 27. April 2018 08:53:28 >>> An: Development list for mkgmap >>> Betreff: Re: [mkgmap-dev] DEM/Contourlines causing grey >>> (empty) squares at the border of maps >>> >>> Hi Felix, >>> >>> I think it is the shape of the poly that matters. Triangular >>> shapes seem to be problematic. Pattern in DEM would be >>> something like >>> UUUUUUUUUUUUU >>> UUUUUUVUUUUUU >>> UUUUUVVUUUUUU >>> UUUUVVVUUUUUU >>> UUUVVVVVUUUUU >>> with U for undefined and V for knwon height. >>> >>> If you use the (rectilinear) area.poly created by splitter >>> when splitting the geofabrik OSM files you will not see this >>> pattern as often. >>> Maybe it would be enough to change the poly so that it is >>> convex, not concave: >>> https://en.wikipedia.org/wiki/Concave_polygon >>> <https://en.wikipedia.org/wiki/Concave_polygon> >>> >>> And yes, I can confirm the missing altitude values with gray >>> squares. >>> >>> Gerd >>> >>> ________________________________________ >>> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk >>> <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag >>> von Felix Hartmann <extremecarver(a)gmail.com >>> <mailto:extremecarver@gmail.com>> >>> Gesendet: Freitag, 27. April 2018 08:42:52 >>> An: Development list for mkgmap >>> Betreff: Re: [mkgmap-dev] DEM/Contourlines causing grey >>> (empty) squares at the border of maps >>> >>> I guess if the poly is a bit bigger - it would not happen? >>> Could you try by enlarging the poly 2km to the outside? Not >>> using a poly at all would be really big or am I wrong? Which >>> normal poly do you mean? The area.poly created while >>> splitting the geofabrik osm files? Or the area.poly created >>> while splitting the phyghtmap osm.pbf contourlines file? >>> >>> I also noticed that while any of that grey square is visible >>> in Basecamp - Basecamp does not show altitude in the lower >>> left corner anymore. >>> >>> On 27 April 2018 at 07:40, Gerd Petermann >>> <gpetermann_muenchen(a)hotmail.com >>> <mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_m >>> uenchen(a)hotmail.com >>> <mailto:gpetermann_muenchen@hotmail.com>>> wrote: >>> Hi Felix, >>> >>> hmm, yes, that really looks bad. At the moment I only have >>> work-arounds: >>> 1) Add additional DEM layers so that the error only shows up >>> in smaller rectangles. >>> 2) Don't use --dem-poly, I think this causes the trouble. Or >>> maybe try the poly file created for the normal tiles. >>> >>> I guess that the encoder still doesn't work 100% correctly, >>> but I have no idea how to fix that and Frank Stinner seems >>> to have stopped his work on >>> https://github.com/FSofTlpz/Garmin-DEM-Build >>> <https://github.com/FSofTlpz/Garmin-DEM-Build> >>> >>> Gerd >>> >>> ________________________________________ >>> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk >>> <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgma >>> p-dev-bounces(a)lists.mkgmap.org.uk >>> <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag >>> von Gerd Petermann <gpetermann_muenchen(a)hotmail.com >>> <mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_m >>> uenchen(a)hotmail.com >>> <mailto:gpetermann_muenchen@hotmail.com>>> >>> Gesendet: Donnerstag, 26. April 2018 20:53:21 >>> An: Development list for mkgmap >>> Betreff: Re: [mkgmap-dev] DEM/Contourlines causing grey >>> (empty) squares at the border of maps >>> >>> Hi Felix, >>> >>> I'll have a closer look tomorrow. IIRC this also happens >>> with Garmin maps. >>> >>> Gerd >>> >>> ________________________________________ >>> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk >>> <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgma >>> p-dev-bounces(a)lists.mkgmap.org.uk >>> <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag >>> von Felix Hartmann <extremecarver(a)gmail.com >>> <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail. >>> com >>> <mailto:extremecarver@gmail.com>>> >>> Gesendet: Donnerstag, 26. April 2018 20:23:11 >>> An: Development list for mkgmap >>> Betreff: Re: [mkgmap-dev] DEM/Contourlines causing grey >>> (empty) squares at the border of maps >>> >>> well maybe it's more common - like in 1/5 maps if the >>> include 1" DEM data - only happens if map includes DEM. >>> >>> On 26 April 2018 at 20:20, Felix Hartmann >>> <extremecarver(a)gmail.com >>> <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail. >>> com >>> <mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail >>> .com >>> >>> <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail. >>> com >>> <mailto:extremecarver@gmail.com>>>> wrote: >>> In some cases at the borders of maps - there appear grey >>> rectangles in Basecamp and Mapsource (well do not mind >>> Mapsource much - it's very outdated) - this only appears if >>> using a DEM/contourline overview... >>> >>> Sorry as Basecamp is windows only - only windows >>> installer/Mac OSX gmap file here: >>> https://openmtbmap.org/mtbbayern.exe >>> <https://openmtbmap.org/mtbbayern.exe> >>> or >>> https://openmtbmap.org/mtbbayern_macosx.7z >>> <https://openmtbmap.org/mtbbayern_macosx.7z> >>> >>> Without contourlines the map works fine (mapsetx.tdb...) >>> Contourlines map alone also does not work (mapsetz.tdb...) >>> >>> >>> So the bug is clearly in the transparent DEM/contourlines >>> map. Sometimes simply rendering the contourlines map again >>> and the bug is gone... >>> >>> >>> Seems to be not that common but also not that rare (maybe in >>> 1 out of 20 maps) >>> >>> -- >>> Felix Hartman - Openmtbmap.org & VeloMap.org >>> Schusterbergweg 32/8 >>> 6020 Innsbruck >>> Austria - Österreich >>> >>> >>> >>> -- >>> Felix Hartman - Openmtbmap.org & VeloMap.org >>> Schusterbergweg 32/8 >>> 6020 Innsbruck >>> Austria - Österreich >>> _______________________________________________ >>> mkgmap-dev mailing list >>> mkgmap-dev(a)lists.mkgmap.org.uk >>> <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@li >>> sts.mkgmap.org.uk >>> <mailto:mkgmap-dev@lists.mkgmap.org.uk>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> >>> _______________________________________________ >>> mkgmap-dev mailing list >>> mkgmap-dev(a)lists.mkgmap.org.uk >>> <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@li >>> sts.mkgmap.org.uk >>> <mailto:mkgmap-dev@lists.mkgmap.org.uk>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> >>> >>> >>> >>> -- >>> Felix Hartman - Openmtbmap.org & VeloMap.org >>> Schusterbergweg 32/8 >>> 6020 Innsbruck >>> Austria - Österreich >>> _______________________________________________ >>> mkgmap-dev mailing list >>> mkgmap-dev(a)lists.mkgmap.org.uk >>> <mailto:mkgmap-dev@lists.mkgmap.org.uk> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> >>> >>> _______________________________________________ >>> mkgmap-dev mailing list >>> mkgmap-dev(a)lists.mkgmap.org.uk >>> <mailto:mkgmap-dev@lists.mkgmap.org.uk> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> >>> >>> >>> >>> >>> -- Felix Hartman - Openmtbmap.org & VeloMap.org >>> Schusterbergweg 32/8 >>> 6020 Innsbruck >>> Austria - Österreich >>> >>> >>> >>> >>> -- Felix Hartman - Openmtbmap.org & VeloMap.org >>> Schusterbergweg 32/8 >>> 6020 Innsbruck >>> Austria - Österreich >>> >>> >>> >>> >>> -- >>> Felix Hartman - Openmtbmap.org & VeloMap.org >>> Schusterbergweg 32/8 >>> 6020 Innsbruck >>> Austria - Österreich >>> >>> >>> _______________________________________________ >>> mkgmap-dev mailing list >>> mkgmap-dev(a)lists.mkgmap.org.uk >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> >>> >> > > > -- > Felix Hartman - Openmtbmap.org & VeloMap.org > Schusterbergweg 32/8 > 6020 Innsbruck > Austria - Österreich > -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich

2 4

Re: [mkgmap-dev] I would like a maxways parameter and associated code to limit the number of ways in a tile
by Gerd Petermann 28 May '18

28 May '18

Hi Randolph, sorry, I've checked again the stack trace and noticed that the problem is in the overview map, not in a single file. So, for this case the solution is probably to change the style so that less data is written to the overview map. Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen(a)hotmail.com> Gesendet: Montag, 28. Mai 2018 07:46:11 An: Randolph J. Herber Betreff: AW: AW: [mkgmap-dev] I would like a maxways parameter and associated code to limit the number of ways in a tile Hi Randolph, The --max-nodes option is just a way to estimate the size of the RGN file (which has the 16M limit). The actual size of the file depends on your style, the mkgmap options and the way how a given area is mapped. It doesn't depend on the number of ways. I think the common method to solve this problem is to modify the split-file (areas.list) created by splitter. You create the file with the wanted --max-nodes value and try to run mkgmap. For those tiles that are too big you edit the areas.list so that the tile is divided into two parts. The resulting areas.list is used with the --split-file option and should work for quite a while. I think I also added the --num-tiles option to assist with this: You feed splitter with the too-large tile and option --num-tiles=2 and it creates two new tiles. Not sure how to do that in a script, but I think someone might have that. Hope that helps? Gerd ________________________________________ Von: Randolph J. Herber <army.bronze.star(a)gmail.com> Gesendet: Mittwoch, 23. Mai 2018 15:00:01 An: Gerd Petermann Betreff: Re: AW: [mkgmap-dev] I would like a maxways parameter and associated code to limit the number of ways in a tile Hi, Gerd, That is correct. It is also a gross simplification. I have read the code enough to learn what the error message actually means. A tile is written like a MS-DOS FAT16 file system within the .img file. If any component exceeds a limit on the size for that type of component, then this error occurs. By far, the most common reason is too many nodes, where the limit is a little less than 16MiB. But, it can occur for too many ways or relations as well. It is hard to reach too many relations without exceeding too much node data or too much way data as well. The condition arises when an area has a large fraction of its ways with 2 or 3 nodes in a way. An example is in the 5 millennia old areas near Cairo, Egypt. The too many ways condition can be addressed by forcing down the number of nodes using --maxnodes. This, though, can cause another problem of too many tiles in a Garmin map set as Mapsource itself has a limit on the number of tiles it can handle in a single mapset of about 2025 tiles. With a --maxways parameter, the few tiles with the short ways can be divided by that parameter without requiring a --maxnodes=500000 parameter with a resultant too many tiles when making a mapset for Africa as a whole. Randolph J. Herber On 5/23/2018 3:25 AM, Gerd Petermann wrote: Hi Randolph, the message just means that the map is too large. This means too many bytes, not too many lines or points. Gerd ________________________________________ Von: Randolph J. Herber <army.bronze.star(a)gmail.com><mailto:army.bronze.star@gmail.com> Gesendet: Dienstag, 22. Mai 2018 14:48:28 An: Gerd Petermann Betreff: Re: [mkgmap-dev] I would like a maxways parameter and associated code to limit the number of ways in a tile Hi, Gerd, You are correct. The actual failure occurs in mkgmap. The output of one apparently working program can cause problems in another following program. In the map data, the problem occurs in the Cairo-Port Said area while making a full world map. If I remember correctly, the message resembles: uk.me.parabola.imgfmt.MapFailedException: There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. at uk.me.parabola.imgfmt.app.BufferedImgFileWriter.ensureSize(BufferedImgFileWriter.java:275) at uk.me.parabola.imgfmt.app.BufferedImgFileWriter.put(BufferedImgFileWriter.java:238) at uk.me.parabola.imgfmt.app.trergn.Polyline.write(Polyline.java:144) at uk.me.parabola.imgfmt.app.trergn.RGNFile.addMapObject(RGNFile.java:140) at uk.me.parabola.imgfmt.app.map.Map.addMapObject(Map.java:265) at uk.me.parabola.mkgmap.build.MapBuilder$ShapeAddFilter.doFilter(MapBuilder.java:1497) at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:58) at uk.me.parabola.mkgmap.filters.LinePreparerFilter.doFilter(LinePreparerFilter.java:148) at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:58) at uk.me.parabola.mkgmap.filters.RemoveEmpty.doFilter(RemoveEmpty.java:61) at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:58) at uk.me.parabola.mkgmap.filters.RemoveObsoletePointsFilter.doFilter(RemoveObsoletePointsFilter.java:138) at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:58) at uk.me.parabola.mkgmap.filters.PolygonSplitterFilter.doFilter(PolygonSplitterFilter.java:50) at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:58) at uk.me.parabola.mkgmap.build.LayerFilterChain.startFilter(LayerFilterChain.java:73) at uk.me.parabola.mkgmap.build.MapBuilder.processShapes(MapBuilder.java:1256) at uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.java:891) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:802) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:286) at uk.me.parabola.mkgmap.combiners.OverviewBuilder.writeOverviewMap(OverviewBuilder.java:191) 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) Note that the error occurs in PolyLine and not in anything about nodes. Randolph On 5/22/2018 2:39 AM, Gerd Petermann wrote: Hi Randolph, I think it would be a lot of work to change splitter like that, and probably it would require a lot more resources. I'd be interested in the original error message from MapSource and the tile that produces it, maybe the error is somewhere in mkgmap. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Randolph J. Herber <army.bronze.star(a)gmail.com><mailto:army.bronze.star@gmail.com><mailto:army.bronze.star@gmail.com><mailto:army.bronze.star@gmail.com> Gesendet: Dienstag, 22. Mai 2018 00:45:49 An: mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] I would like a maxways parameter and associated code to limit the number of ways in a tile Dear Sirs: My definition of "ways" was requested. Splitter first scans nodes (points of various kinds), then ways (forming lines, paths and polygons) and finally relations (container polygons for any or all of nodes, ways or relations). I was using "ways" in the same sense that I understand that splitter uses "ways" in its messages. I hope this helps. --maxnodes sets a soft upper limit on the number of nodes in a map tile. I am requesting a similar in concept --maxways to set a soft limit on the number of ways in a map tile. Randolph J. Herber On 5/21/2018 12:27 PM, Andrzej Popowski wrote: Hi Randolph, what do you mean by "ways"? Any line, road with an address, road used for routing? I don't remember if I ever spotted similar problem. On the other side, I think splitter can be better tuned for current mkgmap. I get impression, that splitter is designed to make a good work with simple maps and doesn't account for addresses, routing nodes od DEM data. It would be nice, if there were more options, than maxnodes. For my maps, I split OSM data in two stages. First I prepare artificial data, that I believe represent better actual size of compiled tiles. I extract addresses as points and highways as simple 2-points lines (I do it with modified osmfilter). Then I make splitter to calculate all tiles using as an input following data: - OSM source - 0-2 times extracted addresses - 6-10 times extracted highways - 1-2 times contour lines I believe, that additional points form address account for some NET size, points form highways for additional NOD size and duplicated contour lines for DEM size. It needs some tuning for different areas, but I think I get a bit more uniform sizes of img than with direct splitting. On second stage I use prepared areas.list to split real data. Basically I do something like this: osmfilter.exe data.o5m --keep= --keep-ways=highway=* -o=net.o5m osmfilter.exe data.o5m --keep= --keep-nodes=addr:housenumber=* -o=adr.o5m splitter.jar --stop-after=split --max-nodes=3000000 data.o5m net.o5m net.o5m net.o5m net.o5m net.o5m net.o5m net.o5m net.o5m adr.o5m adr.o5m contour.pbf contour.pbf splitter.jar --split-file=areas.list data.o5m contour.pbf It would be helpful, if I could do it in a single pass. Maybe splitter could filter internally specific nodes - these which would end as routing nodes or address information and add some multiplier when counting these nodes for splitting? Assuming this is easy to implement, otherwise my procedure is good enough. _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

1 0

mkgmapr4191 and earlierer produces corrupt preview+tdb in some cases
by Thomas Morgenstern 28 May '18

28 May '18

Hi, i create my maps in 2 steps: first: I create all osm-tiles from download.geofabrik as OSM. img-tile (containing 1-Sec DEM) and Contourlines from different soures as Contourline. img-tile. This works good, no problems. Second: I combine the ready OSM.img tiles and contourline.img tiles to the mapset. I use command : java -jar mkgmap.jar -family-id=3100 -route ..... -dem=\\HGT\1SecHGT\ -overview-levels=5:15,6:15 *-overview-dem-dist=*110000 -gmapi \500*.img \400*.img . The resulting TestKarte.gmap seems to bee good in Mapsource and Basecamp. 3D-VIEW works. *But really the tdb and preview-files are corrupt. Especially the preview contains wrong 0x4a and 0x4b. The borders of contourline.img should bee always 1°x1° degree. But the are always smaller. The osm-tiles has wrong borders too. It looks for me, as if the borders are randomly. This prevent Mapsource and Mapinstall to send tiles to the GPS, respektivly the sended tiles are to small at GPS. *I maked a little investigation and found out, that the option *-overview-dem-dist=110000 *causes the error. Without this option all works fine. But the preview has no DEM. I am not a java coder and can not find out, what goes wrong. Maybee the spezialists can find out it. Here is my test-equipment : 2 osm.img (500*), 2 Contourline.img (400*) . as source and the resulting TestKarte. gmap as Test.rar Download : https://d100635.odilo.greatnet.de//data/public/75d14fa5dd1b9abbb7acf7af8b3c… The HGTs are N46E011.hgt and N46E012.hgt. Screenshot Mapsource : http:\\img2ms.de\Bilder\Wrong0x4a.jpg Thanks Thomas

2 2