<div dir="ltr">Well yes in that case they must. However for overhanging rocks the hgt files are incompatible. All sources we use for phyghtmap or srt2osm or other tools rely on 2D models to show the altitude. So for what we have right now - contourlines shall never cross.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 26 Apr 2021 at 18:22, Thomas Morgenstern <<a href="mailto:webmaster@img2ms.de">webmaster@img2ms.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<font face="Arial">I think , your wish, never cross contourlines, <font face="Arial">shows not the reality. In fact there are some
rocks, cliffs with <font face="Arial">90 ° declination. For
exampel: the c<font face="Arial">liffs near Los Gigantes
(tenerife) <font face="Arial">and the Baranco de<font face="Arial">l Inferno (tenerife) . In such sit<font face="Arial">uations, the <font face="Arial">contourlines
m<font face="Arial">ust touch each other. And <font face="Arial">how to procede</font>, if the rocks
h<font face="Arial">a</font>ng over ? Contourlines
must cross !?<br>
<font face="Arial">thomas</font><br>
</font></font></font></font></font></font></font></font></font><br>
<div>Am 26.04.2021 um 11:02 schrieb Felix
Hartmann:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">I'm not fully sure of the exact location anymore
- not too far away from N47° 31.285' E12° 55.889' however. And
using Basecamp map details at lowest (this will allow you to
see the problems much easier).</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 26 Apr 2021 at 16:40,
Thomas Morgenstern <<a href="mailto:webmaster@img2ms.de" target="_blank">webmaster@img2ms.de</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"> <font face="Arial">@ Felix : please,
can you post coordinates of your <font face="Arial">s</font>creen<font face="Arial">s</font>hots ?. i will look at my own
contourlines at this position.<br>
<font face="Arial">thomas</font><br>
</font><br>
<div>Am 26.04.2021 um 10:15 schrieb Felix Hartmann:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>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.<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 26 Apr 2021 at
15:45, Gerd Petermann <<a href="mailto:gpetermann_muenchen@hotmail.com" target="_blank">gpetermann_muenchen@hotmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
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)<br>
<br>
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.<br>
If two or more almost parallel lines meat this worst
case you see the obvious errros where contour lines
overlap.<br>
<br>
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.<br>
<br>
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.<br>
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.<br>
<br>
Maybe it is possible to do this with a separate
program or a special method in mkgmap which just
treats contour lines<br>
- take generated contour data as input<br>
- 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.<br>
- maybe re-iterate if the rerendering caused
overlapping contour lines where original lines where
not overlapping<br>
<br>
Gerd<br>
<br>
<br>
<br>
________________________________________<br>
Von: mkgmap-dev <<a href="mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk" target="_blank">mkgmap-dev-bounces@lists.mkgmap.org.uk</a>>
im Auftrag von Felix Hartmann <<a href="mailto:extremecarver@gmail.com" target="_blank">extremecarver@gmail.com</a>><br>
Gesendet: Montag, 26. April 2021 08:55<br>
An: Development list for mkgmap<br>
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153,
Issue 40 Resolution 23 raster problems<br>
<br>
Thanks Andrzej for the patch.<br>
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...<br>
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).<br>
<br>
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.<br>
<br>
On Mon, 26 Apr 2021 at 03:41, Andrzej Popowski <<a href="mailto:popej@poczta.onet.pl" target="_blank">popej@poczta.onet.pl</a><mailto:<a href="mailto:popej@poczta.onet.pl" target="_blank">popej@poczta.onet.pl</a>>>
wrote:<br>
Hi Gerd,<br>
<br>
I don't observe any significant differences in
compilation. But to make<br>
it more optimized, we can put SizeFilter before
DouglasPeuckerFilter. I<br>
have attached a second patch here.<br>
<br>
There is a difference in results. See pictures with
DouglasPeuckerFilter<br>
after RoundCoordsFilter and new version with
DouglasPeuckerFilter<br>
before. This is for 22-bit resolution, so effects are
probably more clear.<br>
<br>
--<br>
Best regards,<br>
Andrzej<br>
<br>
_______________________________________________<br>
mkgmap-dev mailing list<br>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank">mkgmap-dev@lists.mkgmap.org.uk</a><mailto:<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank">mkgmap-dev@lists.mkgmap.org.uk</a>><br>
<a href="https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
<br>
<br>
--<br>
Felix Hartman - Openmtbmap.org & VeloMap.org<br>
<br>
_______________________________________________<br>
mkgmap-dev mailing list<br>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank">mkgmap-dev@lists.mkgmap.org.uk</a><br>
<a href="https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>Felix Hartman - Openmtbmap.org &
VeloMap.org<br>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
mkgmap-dev mailing list
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank">mkgmap-dev@lists.mkgmap.org.uk</a>
<a href="https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" target="_blank">https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a></pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>Felix Hartman - Openmtbmap.org & VeloMap.org<br>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Felix Hartman - Openmtbmap.org & VeloMap.org<br></div><br></div></div></div></div></div></div>