<div dir="ltr">Well I think we already list all lines which cannot be reversed in the 

<span style="color:rgb(80,0,80)">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...</span><div><span style="color:rgb(80,0,80)"><br></span></div><font color="#500050">For </font>

<span style="color:rgb(80,0,80)">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. </span>

<span style="color:rgb(80,0,80)">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. </span></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 17 May 2021 at 15:46, Gerd Petermann <<a href="mailto:gpetermann_muenchen@hotmail.com">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 Felix,<br>
<br>
I don't understand what the problem is.<br>
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.<br>
Do we still agree about that?<br>
<br>
Is about the rules for oneway=-1 reg. left/right? Those lines clearly have a direction, don't they?<br>
<br>
Gerd<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, 17. Mai 2021 08:09<br>
An: Development list for mkgmap<br>
Betreff: Re: [mkgmap-dev] 4179<br>
<br>
This in referring the the commit message. I think mkgmap in that case simply should not reverse the lines at all.<br>
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.<br>
<br>
On Mon, 17 May 2021 at 13:43, Gerd Petermann <<a href="mailto:gpetermann_muenchen@hotmail.com" target="_blank">gpetermann_muenchen@hotmail.com</a><mailto:<a href="mailto:gpetermann_muenchen@hotmail.com" target="_blank">gpetermann_muenchen@hotmail.com</a>>> wrote:<br>
Hi Felix,<br>
<br>
"this is only needed ..."  what exactly refers "this" to?<br>
<br>
oneway=-1 requires a reversing of roads because the IMG format doesn't allow to store the information that it is a reversed oneway.<br>
<br>
The current code checks the oneway tag first. It does this since r2944, see <a href="https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=2944" rel="noreferrer" target="_blank">https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=2944</a><br>
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.<br>
<br>
Gerd<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><mailto:<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><mailto:<a href="mailto:extremecarver@gmail.com" target="_blank">extremecarver@gmail.com</a>>><br>
Gesendet: Montag, 17. Mai 2021 04:52<br>
An: Development list for mkgmap<br>
Betreff: [mkgmap-dev] 4179<br>
<br>
Hi Gerd<br>
<br>
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.<br>
<br>
I think this is only needed if the linetype is listed under --line-types-with-direction<br>
If not listed here nor routable oneway=-1 is as irrelevant as oneway=yes<br>
<br>
I do not understand why we would have different handling of onway=yes and oneway=-1<br>
Reversing the road should not be needed because it does not matter for the layout, nor for the routing.<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><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" 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>