It sounds like tile@home needs to trim data at the tile border, and then close open ways along the border of the tile...<br>Just my uneducated opinion.<br><br>Dale<br><br><div class="gmail_quote">On Thu, Nov 26, 2009 at 7:31 PM, David ``Smith'' <span dir="ltr"><<a href="mailto:vidthekid@gmail.com">vidthekid@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Wed, Nov 25, 2009 at 4:13 PM, Dale Puch <<a href="mailto:dale.puch@gmail.com">dale.puch@gmail.com</a>> wrote:<br>

> Oops I spoke too soon.  There is a relation.<br>
> <a href="http://www.openstreetmap.org/browse/relation/304245" target="_blank">http://www.openstreetmap.org/browse/relation/304245</a><br>
> I still think this is the probable source of the problem though.  Perhaps<br>
> someone with more experience with relations could take a look?<br>
<br>
</div>I believe the problem is in how Tiles@Home works.  Just enough data<br>
(in theory) is downloaded to the client to render one tile at zoom 12<br>
(and all the equivalent tiles at lower zoom levels) and then<br>
Osmarender renders the map tiles.  I believe the problem is that when<br>
some members of a multipolygon intersect this tile and some don't,<br>
only those members are downloaded.  Without also downloading every<br>
other member in the relation, most computer rendering algorithms will<br>
fail to draw the feature correctly, because only part of the polygon<br>
is loaded.<br>
<br>
On a related note: when a member of a multipolygon relation also<br>
represents a different feature (such as a road) sometimes the tags of<br>
that feature are treated as if they apply to the whole relation in<br>
Osmarender.  I've been meaning to file a trac ticket about that one...<br>
<font color="#888888"><br>
--<br>
David "Smith"<br>
a.k.a. Vid the Kid<br>
a.k.a. Bír'd'in<br>
<br>
Does this font make me look fat?<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Dale Puch<br>