[mkgmap-dev] Commit 4710

Thu May 13 12:16:27 BST 2021

I just looked it up. It must have been 4709 with best routing for me
(unlikely but maybe it could have been 4708), while 4711 is a bit worse
(but better than before the first changes that made an impact on routing).
Both from low-res-opt branch.
I haven't tried trunk for quite a while.

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

> Hi Felix,
>
> please tell me exactly which versions you tested reg. routing.
> Note that the branches do not yet contain the latest changes in trunk.
>
> 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 11:28
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
>
> Well I just got to test routing - and the current version is a degradation
> vs the intermediate version from yesterday for my maps. The current version
> routes better than before, but worse than the intermediate version.
>
> As for the list - it is a bit more complicated inside the style but
> doable. I really do not know what happens to those ways where I first set a
> direction for an downhill only way with higher priority, then remove the
> direction for a way that can be used in both directions at lower priority.
> Maybe sometimes also doing this the other way around. A list with type and
> max resolution used would be much easier for writing your style. Instead of
> adding 60-100 lines with the filter it would be done with 10 or so.  Canals
> should not have a direction, they do not flow. Sidewalk=left, right is the
> same as for the various cylceway,cycletrack options - those are really not
> reversible. The underlying way could be reversed however - and I guess they
> are only used for level 0.
> Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only.
> Cliffs are also only high resolution. For me rivers are the only thing
> which really go into lower resolutions.
>
> On Thu, 13 May 2021 at 16:03, Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>
> wrote:
> Hi Felix,
>
> FYI:
> I just found out that the current code to detect if the style sets
> mkgmap:has-direction=true doesn't work. Seems I didn't test this :(
> The change in r4710 changed only the LineMerger in the branch. Even with
> r4711 LineMerger only merges roads in maps without NET, at least that's
> what's intended.
>
> My understanding is that r4703 changed routing, possibly also r4704. The
> merge from trunk also changed routing in the branches (r4706 and r4707).
>
> I'm now fixing the detection code, next I'm trying to figure out how to
> configure the details reg. direction handling.
>
> Gerd
>
>
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>
> Gesendet: Donnerstag, 13. Mai 2021 09:52
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
>
> 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<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> 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<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto: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<mailto:mkgmap-dev at lists.mkgmap.org.uk
> ><mailto: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<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/20210513/2a1cc35e/attachment.html>