[mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems

Mon Apr 26 09:15:15 BST 2021

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 at 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 at lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecarver at 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 at poczta.onet.pl
> <mailto:popej at 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 at lists.mkgmap.org.uk<mailto:mkgmap-dev at 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 at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20210426/b1526153/attachment-0001.html>