Hi all, the major problem with resolution 23 and lower is the rounding to garmin units without looking at the distortions (WrongAngleFixer does that for res 24) At res 23 we have to draw the lines using a "bed of nails" where the nails have ~5m distance to each other. If the original line "meanders" horizontally close to the nails there is no big problem, nodes are probably rounded to a straight line. If the same line is moved by ~2.5 m up or down we often hit the worst case scenario where one node is rounded to the north and the next is rounded to the south. This produces visible zig-zagging. If two or more almost parallel lines meat this worst case you see the obvious errros where contour lines overlap. The logic in WrongAngleFixer tries to detect this and sometimes decides to round to a different place to reduce zig-zagging. The problem is that this has to be done looking at all lines, not just one, at least with normal OSM data where we have intersections. For contourlines it would be best if the generator would only calculate nodes which are exactly at the positions of the Garmin nails, but that is probaby not easy. The special case here is that it doesn't really matter where the nodes are, we just need "good looking" lines and that each node is only used by one contour way. Maybe it is possible to do this with a separate program or a special method in mkgmap which just treats contour lines - take generated contour data as input - rerender each way with resolution 23 nodes so that the line looks almost like before. This means it may add nodes somewhere and remove others. - maybe re-iterate if the rerendering caused overlapping contour lines where original lines where not overlapping Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 26. April 2021 08:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems Thanks Andrzej for the patch. It produces better results in about 2/3 of cases, and worse in about 1/3 of cases for resolution 23. So overall it's an improvement, and at least for compiling contourlines I didn't notice a significant difference in compile time. I could test this more in detail also against normal map data if needed... Using --simplifyContoursEpsilon= in phyghtmap helps a bit too, especially for resolution 24. However it runs super slow. It's like 1-30 times as much time, if not more (except for a value of 0.0 which is not changing the maps at all, and just making the .pbf file 10% smaller). This doesn't solve phyghtmap not using b-spline interpolation. That would improve even more (at least up to resolution 23, for resolution 22 maybe this patch matters more). In general if using 20m equidistance I feel in most cases it's good enough to compile contourlines only starting from resolution 23, much faster, less data just of course in very steep areas problematic. For 10m equidistance however it kinda means also going for resolution 24, else the improvement from 20m to 10m is more of a nuisance. On Mon, 26 Apr 2021 at 03:41, Andrzej Popowski <popej@poczta.onet.pl<mailto:popej@poczta.onet.pl>> wrote: Hi Gerd, I don't observe any significant differences in compilation. But to make it more optimized, we can put SizeFilter before DouglasPeuckerFilter. I have attached a second patch here. There is a difference in results. See pictures with DouglasPeuckerFilter after RoundCoordsFilter and new version with DouglasPeuckerFilter before. This is for 22-bit resolution, so effects are probably more clear. -- Best regards, Andrzej _______________________________________________ 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