Hi Felix, the WrongAngleFixer takes care about filtering at resolution 24. It calls the DouglasPeucker filter with maxErrorDistance = 0.05. See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4172
Maybe try to play with the value 0.05. WrongAngleFixer tries to produce a result that is closer to the OSM data than simple rounding to Garmin raster and removes points which don't improve the rendered image if they are not needed for routing. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecar...@gmail.com> Gesendet: Freitag, 30. April 2021 16:42 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems Are you sure it would be needing that much more memory? If there is a big penalty this simplification could only be done for lower resolutions, which contain much less data. Even if its only 13-20 that would be a huge improvement. 21 could need some love too but not as important, while 22 is usually still quite performant on GPS devices. 13-16 or 17 is usually basemap only anyhow. Maybe we could create static basemaps in the same way that we have the sea and boundary files? Yes if a new highway is built at some point it should show up in the overview map - but as this one is really only for orientation, I really feel it's okay to be updated only twice per year or so. Garmins maps in this aspect are clearly superior. On Fri, 30 Apr 2021 at 21:50, Gerd Petermann <gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote: Hi all, attached is my proposed change based on the simplify3.patch by Andrzej and the idea to use that only for contour lines. I see no simple way to implement major improvements for the rendering of lower resolutions. Basically we need the WrongAngleFixer to work with a given resolution. So, something like a loop over each level (starting with the highest) + collect the elements that should be rendered at this level + use method like WrongAngleFixer for the corresponding resolution so that distortions caused by rounding are reduced + add code to detect parallel lines which should be deduplicated + store the objects, each only valid for this one level Finally do the sub division splitting, the merging of lines and shapes in each sub div and the binary encoding of the map. If possible, the merging and the Douglas-Peucker-Filter (or whatever) should be done before splitting into sub divs. I assume Garmins program is doing it that way because the data structures suggest that they fist calculate all the elements of all levels before it starts the splitting into sub divs. I guess this would produce nicer looking maps at lower resolutions. It would also require more heap memory (100% would be my guess) and more compilation time unless we find clever tricks to avoid that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecar...@gmail.com<mailto:extremecar...@gmail.com>> Gesendet: Donnerstag, 29. April 2021 14:39 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems here is what I mean - zig zagging like crazy if you look at it with lowest detail which is really helpful to see this problem. Those highways should be just straight. Oh yes - because the highways are two separate lanes they never have holes. Those holes with the patch are best visible on highway primary and secondary. Actually for highways maybe mkgmap could even include an algo to fix the double highway and just put it once into the map if it overlaps. So step a) remove zig zagging. Step two - remove any double highway if within 3-4 garmin units away from each other as long as we do not create a hole by this (at intersections). Every style has minimum width for highways of at least 3-4 units, if not 6-7, so drawing two highways on top of each other is waste of resources. Actually this applies to all roads but will be mainly important for highways as they are nearly always entered into OSM with both directions as a separate line. On Thu, 29 Apr 2021 at 20:30, Felix Hartmann <extremecar...@gmail.com<mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com>>> wrote: Yes - I also support Gerd that it doesn't work well for polygons. Now for lines it's another story. a) I love that lines are a bit straighter and looking better vs increasing douglas peucker. b) Sadly though there are bits and pieces of roads missing. If that is fixed I would be all supportive to use this for all lines. But not before those missing bits reappear. How to check for it - just use lowest detail level in Basecamp. Oh yeah and mkgmap without that patch also has a zig zagging problem. Maybe we would need a separate algorithm to check for zig zagging and make sure this does not happen. I really think we could need an algorithm that just checks for zig zagging from resolution 22 and lower and base it on the principle that 90% of all those zig zags are unwanted therefore just straighten lines if there is a zig zag. So nothing to do with this patch - but a general really needed improvement for mkgmap. (mkgmap is lacking a bit vs Garmin owns map at lower resolutions. At resolution 24 mkgmap produces fantastic maps, but garmins own maps are definitely better at lower resolutions regarding problems like zig zagging or reducing detail). Avoiding those zig zags would make the maps pan and load much faster on devices. I use a high DP value of 5.4 because zoomed out further I feel this is needed. But the zig zagging occurs anyhow, or because of it? I really feel some little tweaks here could be a huge improvement for practical use on devices. We do not need exactness when zoomed out far - but we need the map to look nice. If a line is 1 or 2 points away from reality doesn't matter from resolution 17-21 and matters not too much for resolution 22. Only 23 and 24 should be more or less exact. (maybe for driving on highways with a car this is different - but is anyone actually using mkgmap created maps for this? I think nearly everyone uses google maps or smartphone. Garmin maps are mainly for outdoors or city maybe. But not for automobile use. Some people but not many motorcycle maybe. So the main importance for lower resolution is nice visual display and fast, not if a road misses some tiny turn or is 100m left or right. And with a car we have lock on road exactly for that. So visually it will be on the road anyhow even if the road is moved 1 or 2 garmin units to one side. On Wed, 28 Apr 2021 at 22:59, Gerd Petermann <gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>> wrote: Hi all, my observations at resolution 22: I think the patch re-introduces rendering problems at T-shaped crossings, sometimes they look like t-shapes at lower resolutions. Sample: https://www.openstreetmap.org/node/260418111 It seems to filter more small polygons, even with --min-size-polygon=0. I think it tends to make polygons smaller, not sure why. It sometimes reduces wrong zig-zagging, but only for ways with many points. In cities, where roads are often split into many small parts it sometimes makes things worse. It probably helps for the special case contour lines and therefore I suggest to limit it to them. Maybe the code to find the best place for a rounded coord should also consider to remove the point if that would give the best result. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>> im Auftrag von Gerd Petermann <gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>> Gesendet: Mittwoch, 28. April 2021 15:21 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems Hi Felix, I expect (more) small missing parts of complex shapes like forests or waterway areas (those without mkgmap:skipSizeFilter=true) and more obvious differences between shapes and lines, e.g. if a style renders outlines of buildings. The maps are very different at res 22, so it is hard to say if there are more improvements then worsenings. I've experimented with different orders of filters in the past. It's difficult to test because the changes heavily depend on the Styte AND the mapped objects AND the mappers preferences. For example, if landuse areas are glued to highways or not, if landuse areas are glued to other landuse areas or if there nodes are just very close. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecar...@gmail.com<mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com>>> Gesendet: Mittwoch, 28. April 2021 14:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems Oh I thought it was mainly meant for contourlines. Did not know you intend it to be used in general. I am not really sure how and where to check for quality. On Wed, 28 Apr 2021 at 20:13, Gerd Petermann <gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>> wrote: Hi Felix, your screen shots only show contour lines but the patch works on all types of lines and polygons. So, please also check the results with other maps. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <extremecar...@gmail.com<mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com>><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com>>>> Gesendet: Mittwoch, 28. April 2021 04:54 An: Development list for mkgmap; Andrzej Popowski Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems forgot 1.3 value - that is good enough (and this location is not the most difficult, but there are very few places that are worse. So I feel it's good enough as if it's fine here - there are very very few other places that are still problematic. On Wed, 28 Apr 2021 at 10:50, Felix Hartmann <extremecar...@gmail.com<mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com>><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com>>><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com>><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com>>>>> wrote: Thanks for that patch, the improvement is not as big as from the previous patch - but there is some. I analysed it a bit more - and I think there needs to be one more change - actually in general and not only for contourlines. We need different values for the douglas peucker algorithm depending on resolution! Right now we can only set one value, and that is multiplied for each resolution? Based on the current state I would like to have resolution 24= 0.0 or maybe actually have it active at 24 as well trying a value of 0.3 or so. Where there any problems with autorouting or why is it not possible to use it at resolution 24 as well? 23=1.3 22=2.6 21=3.9 20-11=5.4 Especially if we produce a map without resolution 24, then resolution 23 needs to have much lower DP value than the subsequent resolutions. Using 1.3 for resolution 23 makes the quality IMHO good enough to be used for an contourlines only map for GPS devices and skipping resolution 24 altogether. For Desktop use resolution 24 may still make sense for contourlines - but even then the difference is only in very steep areas. Attached some screenshots at resolution 24, and at 23 with different DP values and one of patch2. On Tue, 27 Apr 2021 at 23:16, Andrzej Popowski <po...@poczta.onet.pl<mailto:po...@poczta.onet.pl><mailto:po...@poczta.onet.pl<mailto:po...@poczta.onet.pl>><mailto:po...@poczta.onet.pl<mailto:po...@poczta.onet.pl><mailto:po...@poczta.onet.pl<mailto:po...@poczta.onet.pl>>><mailto:po...@poczta.onet.pl<mailto:po...@poczta.onet.pl><mailto:po...@poczta.onet.pl<mailto:po...@poczta.onet.pl>><mailto:po...@poczta.onet.pl<mailto:po...@poczta.onet.pl><mailto:po...@poczta.onet.pl<mailto:po...@poczta.onet.pl>>>>> wrote: Hi, some more experiments, see attached patch. I have tried to optimize rounding of coordinates for lowest distance to line. This is not good for polygons, because can creates gaps between adjacent polygons. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@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>><mailto:mkgmap-dev@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>>><mailto:mkgmap-dev@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>><mailto:mkgmap-dev@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>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@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>><mailto:mkgmap-dev@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>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@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>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@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>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev