[mkgmap-dev] Commit 4710

Thu May 13 08:52:29 BST 2021

I kinda feel by default even oneway=yes should only mean do not change
direction for level 0. If someone uses a style to have arrows showing the
oneway, then only for that arrow line (defined by tag) the direction cannot
be reversed. Yes the problem of DP filter rests - I feel this does not
matter for resolution 24 and even 23, but if you display arrows for
resolution 22 or higher then a tag should not merge the underlying lines.
Besides rivers (then also many styles do not have an arrow for rivers, or
you could decide to show the arrows only at resolution 24 and 23) few lines
will be objection dependent.

I will try out now if there is any change in routing - but I will
only write again if there unexpectedly is. The sharp angles changed routing
for the better for my maps by quite a lot. So maybe with now some less
lines being merged, there actually will be a little change for the worse
back to the old behavior. Not sure..

On Thu, 13 May 2021 at 14:07, Gerd Petermann <
gpetermann_muenchen at hotmail.com> wrote:

> Hi Felix,
>
> yes, size increases if your style sets mkgmap:has-direction=true. I just
> want to make sure that the direction flag is treated correctly first.
> As already discussed we might introduce a new option or tag to tell mkgmap
> the min. level at which the direction has to be kept. You suggested to
> ignore direction at level > 0, I think it might depend on the style and
> TYP. I'll play with the OFM style to find out more.
>
> The change should not affect routing at all (none of the changes in the
> low-res-opt branch should).
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecarver at gmail.com>
> Gesendet: Donnerstag, 13. Mai 2021 02:59
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Commit 4710
>
> fix error in LineMergeFilter reg. lines with direction
> The line merger should not merge lines if one has the direction flag set
> and the other has not. Problem exists also in trunk.
>
>
> Hmm fixing this stopped all the nice size optimization. Map size got much
> bigger again.
> I did not find any place where this mattered. Routing was also not
> affected badly. Maybe I did not look good enough?
>
> I do not see why not to merge them. As long as it`s not the opposite it
> seems fine...
> Map size increase/decrease is around 1.5% with my style. So thats quite a
> big difference.
> --
> 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/20210513/70814da1/attachment.html>