Well I think we already list all lines which cannot be reversed in the line--types-with-direction, in addition to that roads with oneway cannot be reversed at level 0 (but at all other levels - in my opinion). lines that are not routable but have a oneway attribute, and are not listed - do not need to be evaluated for oneway at all IMHO. So also not needed to reverse oneway=-1 for them. But yes it likely does not matter much if afterwards they are reversed anyhow... For line--types-with-direction it would be best to give a resolution limit for each type, so if resolution is lower than associated lines can be reversed. If no resolution given then assume they can be reversed. That is still the trickiest one. E.g. line--types-with-direction=0x0a(22), 0x10100(24) - 24 meaning any associated way can be reversed from resolution 23 onwards in order to be merged. If no resolution is given assume they can be reversed at any resolution. On Mon, 17 May 2021 at 15:46, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I don't understand what the problem is. I think we agreed that the oneway tag should not influence the direction flag for non-routable lines. Only the mkgmap:has-direction tag or the --types-with-direction list should be evaluated. Do we still agree about that?
Is about the rules for oneway=-1 reg. left/right? Those lines clearly have a direction, don't they?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 17. Mai 2021 08:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] 4179
This in referring the the commit message. I think mkgmap in that case simply should not reverse the lines at all. I did not know that --allow-reverse-merge will be able to reverse them again. But yes I think mkgmap could skip reversing such lines. Meaning only look at oneway status for lines that are on the line--types-with-direction list or routable. Doing that in style is rather complicated, and likely using quite a lot of CPU cycles too.
On Mon, 17 May 2021 at 13:43, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
"this is only needed ..." what exactly refers "this" to?
oneway=-1 requires a reversing of roads because the IMG format doesn't allow to store the information that it is a reversed oneway.
The current code checks the oneway tag first. It does this since r2944, see https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=2944 It's probably not needed for lines without a direction and it might safe a few cpu cycles to avoid that reversing. Anyhow, with --allow-reverse-merge the order of points in lines without direction might be reversed again.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 17. Mai 2021 04:52 An: Development list for mkgmap Betreff: [mkgmap-dev] 4179
Hi Gerd
oneway tag no longer influences the direction flag of non-routable lines. Note that oneway=-1 still means line is reversed and oneway=yes is set.
I think this is only needed if the linetype is listed under --line-types-with-direction If not listed here nor routable oneway=-1 is as irrelevant as oneway=yes
I do not understand why we would have different handling of onway=yes and oneway=-1 Reversing the road should not be needed because it does not matter for the layout, nor for the routing. -- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org