I plan to release the next set of tiles@home rules files using this approach. <br><br>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>
<br>> </rule><br>><br>> This paints the one-way markers over the top of all the highways after they<br>> have all been drawn. Works very nicely and avoids using the <addclass><br>> 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>