<html>
<head>
</head>
<body class='hmmessage'><div dir='ltr'>

<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr">Hi Mike,<br><br><div><hr id="stopSpelling"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:#1F497D;">Hi <span class="ecxSpellE">Gerd</span>, I added the following to the lines file in my style and it works fine there if I remove the --make-opposite-<span class="ecxSpellE">cycleways</span> option, allowing just cycling and walking against the flow. However, it doesn’t seem to work correctly if I add it to the default style (it allows cars to go the wrong way along the one-way street).</span><div class="ecxWordSection1"><p class="ecxMsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:#1F497D;">&nbsp;</span></p><p class="ecxMsoNormal" style="text-autospace:none;"><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;;">highway=* &amp; (oneway=yes | oneway=-1 | oneway=true | oneway=1 | oneway=reverse) &amp; (oneway:bicycle=no | cycleway=opposite | cycleway=opposite_lane | cycleway=opposite_track) {delete oneway; delete cycleway; set access=no; delete foot; delete vehicle; delete motor_vehicle; delete motorcar; delete goods; delete hgv; delete psv; delete emergency; delete taxi; delete bus; add bicycle=yes; set highway=cycleway} [0x10 road_class=0 road_speed=1 resolution 24 continue]</span></p><p class="ecxMsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:#1F497D;">&nbsp;</span></p><p class="ecxMsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:#1F497D;">I can’t see why this might be happening. Has anyone any ideas (the attached patch is what I changed)?</span></p><br>I think that is the problem I was discussing with Minko. The order in which routable ways are added <br>by the style matters, although we don't know exactly why.<br>With the --make-opposite-cycleways the cycle way is added after the "normal" way,<br>with your change below it is added before.<br>Garmin algos seem to use only one way in some cases, esp. at the beginning of a route.<br><br>Further thoughts: <br>1) Your new patch also removes the special handling for mkgmap:synthesised in inc/access<br>-#limit artificial cycleways to to resolution 24<br>-mkgmap:synthesised=yes &amp; mkgmap:bicycle=yes { set mkgmap:highest-resolution-only = true }<br>This is okay for your case, but I should mention that the tag<br>mkgmap:synthesised is also evaluated within mkgmap to avoid some<br>meaningless warnings in e.g. the roundabout checks.<br>In other words: A style that adds&nbsp; multiple routable ways for one OSM way<br>should try to&nbsp; setmkgmap:synthesised=true <br>when options like --check-roundabouts or --check-roundabout-flares are used.<br><br>I think we might as well set that a corresponding flag in mkgmap when it detects <br>that more than one routable way was added (with res 24) for one OSM way.<br><br>2) Maybe we can replace the&nbsp; --make-opposite-cycleways option by <br>a new special tag like mkgmap:add_cycleway=[before|after] ?<br><br>Gerd<br><br><br><br><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;;"></span><br></div></div></div>
                                               </div></body>
</html>