Hi Felix, for mkgmap it would be best if the generated contour line nodes where exactly on positions in the Garmin res 23 or maybe even res 22 positions. In that case the rounding in mkgmap would not change the generated lines. I have no idea if any generator is able to do that, it probably adds some complexity to the calculations. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 23. April 2021 17:47 An: john@the-thorns.org.uk; Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems the problem is at some points - that the lines interchange at resolution 23. I know the main problem is phyghtmap. Groundtruth and gnuplot with b-spline interpolation can do this much better. But at resolution 24 still never lines intersect, at resolution 23 they do. (the commenting of the wrong angle fixer didn't seem to help or change anything - I have to compare tomorrow again however. Just locked myself out of my compile server somehow entering the password wrong too often). Yes very steep and 10m equidistance which is not suited for such steep slopes - but it's possible to create much better contourlines (as seen from the contourlines on kleineisel.de<http://kleineisel.de> - they never intersect also at resolution 23). On Fri, 23 Apr 2021 at 21:38, John Thorn <johnrthorn@gmail.com<mailto:johnrthorn@gmail.com>> wrote: I don't think this can be improved. As I understand it, internally Garmin devices hold coordinates in the number of bits specified in the level. So 24 bits has a resolution of 2.4 metres, 23 bits has a resolution of 4.8 meters and so on. If you look carefully, all the vertices of the lines lie on a square grid. Having said that, that must be a very steep slope - unless something else is creating the granularity. On Fri, 23 Apr 2021 at 12:06, <mkgmap-dev-request@lists.mkgmap.org.uk<mailto:mkgmap-dev-request@lists.mkgmap.org.uk>> wrote: Send mkgmap-dev mailing list submissions to mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> To subscribe or unsubscribe via the World Wide Web, visit https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev or, via email, send a message with subject or body 'help' to mkgmap-dev-request@lists.mkgmap.org.uk<mailto:mkgmap-dev-request@lists.mkgmap.org.uk> You can reach the person managing the list at mkgmap-dev-owner@lists.mkgmap.org.uk<mailto:mkgmap-dev-owner@lists.mkgmap.org.uk> When replying, please edit your Subject line so it is more specific than "Re: Contents of mkgmap-dev digest..." Today's Topics: 1. Resolution 23 raster problems (Felix Hartmann) ---------- Forwarded message ---------- From: Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> Cc: Bcc: Date: Fri, 23 Apr 2021 18:01:15 +0800 Subject: [mkgmap-dev] Resolution 23 raster problems Any ideas why this is happening? Some of the contourlines intersect each other at resolution 23 - I especially used reduce-point-density=1.0 to try to stop it. java -jar -Xmx47000M /home/contourlines/mkgmap.jar --keep-going --dem-poly=/home/contourlines/bounds/bayern.poly --series-name=openmtbmap-cntrs-DBY-23-Apr-2021 --dem=/home/contourlines/hgt/VIEW1/,/home/contourlines/hgt/SRTM1v3.0,/home/contourlines/hgt/VIEW3/,/home/contourlines/hgt/SRTM3v3.0/ --dem-dists=5520 --max-jobs=7 --reduce-point-density=1 --transparent --style-file=srtm24 --latin1 95260000.osm.pbf Is there any way to improve this? Look at the screenshots - the small one is resolution 23, the big one 24. If using 10m interval contourlines this is pretty obviously not ideal. Resolution 24 could be nicer - but I guess this is more a problem of phyghtmap (while groundtruth can produce higher quality), but resolution 23 really becomes confusing vs 24...: [Simplification_23.PNG] [Oiginal_24.PNG] If pictures don't show https://openmtbmap.org/23.PNG https://openmtbmap.org/24.PNG -- 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 _______________________________________________ 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

Hi Andrzej, at resolution 24 we only do simplification which doesn't have visual effects. Your patch might help. I tried that once and found the improvement too small compared to the increased run time. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Sonntag, 25. April 2021 17:47 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems Hi, maybe 10m contours are too dense for this area? Please try attached patch. I have moved D-P simplification before rounding of coordination. This should preserve shape of the line a bit better. I'm not sure if this is a safe modification, but it seems to works. I haven't found, where is done simplification of lines at resolution 24. Angle fixer probably works on roads only or I don't understand this code correctly. -- Best regards, Andrzej

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> 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 https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- Felix Hartman - Openmtbmap.org & VeloMap.org

yes - for contourlines it would be great if the algo could check that lines never cross - and if moving one direction vs the other means not touching vs touching - then move the other direction. So it would need to loop at for each line, at the next 2 lines. The big advantage would be for contourlines only maps (which makes most sense IMHO, as you don't need to update contourlines except if there is newer better data which is rare) that you can create them with resolution 23 as highest resolution instead of 24. Saving about 50% of the space. Old Garmin devices scroll notably slower with resolution 24 contourlines vs 23, even more of course if 10m equidistance instead of 20m equidistance is used. As 0x20, 0x21 and 0x22 are always contourlines - those lines could easily be distinguished (there is one second set of contour line types in newer garmin maps, I don't know if that matters, and cant remember the types right now). If this treatment is a lot slower - then it should have a command option, so whoever integrates the contourlines has the choice of chosing it. Because for separate contourlines even doubling or tripling compilation times do not matter much. On Mon, 26 Apr 2021 at 15:45, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:

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

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- Felix Hartman - Openmtbmap.org & VeloMap.org