May 2018 - mkgmap-dev - The mkgmap lists

mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
by Felix Hartmann 14 Nov '19

14 Nov '19

Would it be possible to have the mkgmap:set_unconnected_type=... differentiate between conncected on both sides for lines and only connected on one side? For example I would like to delete all service=driveway shorther than 100m length if they are connected only on one side to another routable line - if they are in between I would like to keep them. (in some countries - e.g. Switzerland and France) often highway=service&service=driveway leads not only to a house but also connects e.g. to a highway=track or highway=path. -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich

5 44

DEM/Contourlines causing grey (empty) squares at the border of maps
by Felix Hartmann 13 Jul '18

13 Jul '18

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

2 11

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

Garmin Basecamp 4.7.0 on Windows breaks MapInstall sending .img format maps
by Felix Hartmann 27 May '18

27 May '18

It's nothing mkmap can fix - just a note if you're wondering: On Windows MapInstall you cannot send ANY map in the classic .img format anymore. Also genuine Garmin maps are arriving as overview map only. Actually it would be cool if garmin could use overview maps on devices too, so far they were basecamp/mapsource only. Sending .gmap format maps works without problems. -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich

1 0

osmupdate
by lig fietser 24 May '18

24 May '18

Since recently I cannot update my osm maps anymore with osmupdate. Error: Could not get the newest daily timestamp from the Internet. Anyone familiar with this isssue and how to fix this?

3 10

osmconvert64
by Manfred Haiduk 22 May '18

22 May '18

Hi all, does anyone have an idea, why osmconvert64 seems to do not work anymore ? I have used this to build bounds files on my one (if the input file ist small enough) but today with a fresh loaded pbf file from "http://download.geofabrik.de/" this line "c:\Program Files (x86)\KartenTools\osmconvert64.exe" .\input\nordrhein-westfalen-latest.osm.pbf -o=.\input\nordrhein-westfalen-latest.o5m only produces an empty output ? Did i miss something ? Some month ago it was working .... -- Mit freundlichen Grüßen ##################################################### Manfred Haiduk, Zum Fischbach 9, 52393 Hürtgenwald e-mail mhaiduk(a)t-online.de #####################################################

4 5