It is a bug.  The seams are a rendering artifact and should definitely not be worked-around by adjusting the tagging.<br><br>On Tue, Mar 11, 2008 at 10:21 PM, Dermot McNally <<a href="mailto:dermotm@gmail.com">dermotm@gmail.com</a>> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The matter of renderer quirks and whether you should work around them<br>

arose on another thread but didn't really go places. One principle<br>
that was strongly backed was "fix the renderer, don't tamper with the<br>
data". But before filing any bug reports I want to check the mood<br>
among those of you hacking on the renderers, particularly<br>
osmarender...<br>
<br>
As of one of the major version bumps in osmarender, the way that<br>
"normal" (definition below) bridges were rendered changed. Consider<br>
the following ascii art to be a rendered bridge:<br>
<br>
 0<br>
 0<br>
 0<br>
 0<br>
 0<br>
|1|<br>
|1|<br>
|1|<br>
|1|<br>
|1|<br>
 0<br>
 0<br>
 0<br>
 0<br>
 0<br>
<br>
IOW, we have the bridge portion itself, which is a way having layer=1<br>
and bridge=yes. Abutting it are ways not having either of these,<br>
therefore implicitly at layer=0. Previously, this would be rendered as<br>
a continuous road of whatever type with "bridge-marks" alongside the<br>
part so-tagged. Brilliant. However, for a while now, an unsightly seam<br>
has been getting shown at the transition.<br>
<br>
This has led at least one mapper to get creative (IMHO unreasonably<br>
so) with the layer attribute. For example, to work around the seams in<br>
the above case, you might do the following:<br>
<br>
 0<br>
 0<br>
 1<br>
 1<br>
 1<br>
|1|<br>
|1|<br>
|1|<br>
|1|<br>
|1|<br>
 1<br>
 1<br>
 1<br>
 0<br>
 0<br>
<br>
This troubles me, though. Firstly, it's less "correct" in the layering<br>
it implies. Secondly, you still get your seam, it just moves away from<br>
the bridge boundary.<br>
<br>
So is there any reason we can't get rid of these seams? Their presence<br>
is a temptation to adopt workarounds. Those workarounds have already<br>
cost me a lot of effort reinstating good data destroyed as a result of<br>
rework that would never have been performed if the seams hadn't been<br>
showing.<br>
<br>
Do they serve any purpose? Is it hard to avoid them?<br>
<br>
Thanks,<br>
Dermot<br>
<br>
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk" target="_blank">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk</a><br>
</blockquote></div><br>