<br><br><div class="gmail_quote">On Tue, Mar 6, 2012 at 1:43 AM, Pieren <span dir="ltr"><<a href="mailto:pieren3@gmail.com">pieren3@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Mar 6, 2012 at 10:03 AM, Ross Scanlon <<a href="mailto:info@4x4falcon.com">info@4x4falcon.com</a>> wrote:<br>
> Definitely not how to map an intersection.  AU list have had several<br>
> discussions on this and it's junk mapping.<br>
<br>
</div>I still believe that mapping each lane is easier than using verbose<br>
and encrypted tags (probably that need some special tools on editors<br>
to handle the lanes together).<br>
But you are right, drawing intersections like here is a nightmare and<br>
is not reflecting the reality : the intersection is only a square<br>
where lanes are not painted on the ground. It should be modeled in the<br>
same way in OSM: just a highway polygon (tagged intersection=yes?)<br>
where the lanes are connected. And routing engines should solve the<br>
path inside the square themselves like road-users...</blockquote><div><br></div><div>This seems like a real step backwards.  Granted, lane encoding sucks badly right now in general, but having sparse but accurate data is probably better than something that both renders awfully, is labor intensive to implement and exceptionally difficult to back out of.  The problem is looking for a solution, but not one that greatly complicates things and makes even bigger problems.</div>
</div>