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

Mon Apr 26 13:55:32 BST 2021

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.

On Mon, 26 Apr 2021 at 18:22, Thomas Morgenstern <webmaster at img2ms.de>
wrote:

> I think , your wish,  never cross contourlines, shows not the reality. In
> fact there are some rocks, cliffs with 90 ° declination. For exampel: the
> cliffs near Los Gigantes (tenerife) and the Baranco del Inferno
> (tenerife) . In such situations, the contourlines must touch each other.
> And how to procede, if the rocks hang over ? Contourlines must cross !?
> thomas
>
> Am 26.04.2021 um 11:02 schrieb Felix Hartmann:
>
> 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).
>
> On Mon, 26 Apr 2021 at 16:40, Thomas Morgenstern <webmaster at img2ms.de>
> wrote:
>
>> @ Felix : please, can you post coordinates of your screenshots ?. i will
>> look at my own contourlines at this position.
>> thomas
>>
>> Am 26.04.2021 um 10:15 schrieb Felix Hartmann:
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> mkgmap-dev mailing listmkgmap-dev at lists.mkgmap.org.ukhttps://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
>
>

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