I plan to release the next set of tiles@home rules files using this approach.   If there are no issues arising after a few weeks of use, I'll mark the <addclass> instruction as deprecated and remove it in some (far) future version of Osmarender.

<br><br>Etienne<br><br><div><span class="gmail_quote">On 6/22/07, <b class="gmail_sendername">Jochen Topf</b> <<a href="mailto:jochen@remote.org">jochen@remote.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On Thu, Jun 21, 2007 at 12:13:57PM +0100, 80n wrote:<br>> On 6/20/07, 80n <<a href="mailto:80n80n@gmail.com">80n80n@gmail.com</a>> wrote:<br>> ><br>> >Jochen<br>> >I've just noticed a possible problem with the <addclass> instruction in

<br>> >Osmarender.<br>> ><br>> >The sequence in which subordinate rules are processed within an <addclass><br>> >instruction are not strictly honoured.  Consider the following example:<br>> >

<br>> ><addclass k="oneway" v="1|yes|true" class="oneway"><br>> >    <rule e="way" k="highway" v="secondary"><br>> >        <line class='highway-secondary' />

<br>> >    </rule><br>> >    <rule e="way" k="highway" v="primary"><br>> >        <line class='highway-primary' /><br>> >    </rule><br>

> ></addclass><br>> ><br>> >Normally you would expect all secondary ways to be rendered and then all<br>> >primary ways.  However, with the introduction of the <addclass> instruction<br>

> >the rendering order becomes:<br>> ><br>> >1 one-way secondary<br>> >2 one-way primary<br>> >3 two-way secondary<br>> >4 two-way primary<br>> ><br>> >So when you have a two-way secondary that meets a one-way primary the

<br>> >rounded end of the secondary road is rendered over the primary rather than<br>> >under it.<br>> ><br>> >You can see an extreme example of this here, where lots of residential<br>> >roads meet a main road:

<br>> ><a href="http://www.informationfreeway.org/?lat=51.46575646757731&lon=-0.29377692535288097&user=80n&zoom=17&layers=0B00F00">http://www.informationfreeway.org/?lat=51.46575646757731&lon=-0.29377692535288097&user=80n&zoom=17&layers=0B00F00

</a><br>> ><br>> >Any ideas about how to fix this?<br>><br>><br>> OK, I solved this by using a slightly different approach:<br>><br>>    <rule e="way" k="highway" v="secondary">

<br>>        <line class='highway-secondary' /><br>>    </rule><br>>    <rule e="way" k="highway" v="primary"><br>>        <line class='highway-primary' />

<br>>    </rule><br>><br>>    <rule e="way"  k="oneway" v="1|yes|true" class="oneway"><br>                                             ~~~~~~~~~~~~~~~<br>                                             I guess this is a

<br>                                             cut-and-paste error<br>>        <rule e="way" k="highway" v="*"><br>>             <line class="oneway"/><br>>        </rule>

>    </rule> > > This paints the one-way markers over the top of all the highways after they > have all been drawn.  Works very nicely and avoids using the <addclass> > instruction which, personally, I've never been very happy with.

<br>><br>> Is <addclass> actually used for any other purpose?  If not, I'd like to<br>> propose that it be deprecated - it's implementation requires the xsl<br>> set:difference extension which AFAIK isn't implemented in Firefox

<br>> (transformiix).  It's not guaranteed to be available in other xsl engines<br>> either so it would be one less dependency to worry about.<br><br>You're probably right. Your new approach looks better.<br>

<br>Jochen<br>--<br>Jochen Topf  <a href="mailto:jochen@remote.org">jochen@remote.org</a>  <a href="http://www.remote.org/jochen/">http://www.remote.org/jochen/</a>  +49-721-388298<br><br></blockquote></div><br>