[OSM-dev] Osmarender - addclass problem

80n 80n80n at gmail.com
Thu Jun 21 12:13:57 BST 2007


On 6/20/07, 80n <80n80n at gmail.com> wrote:
>
> Jochen
> I've just noticed a possible problem with the <addclass> instruction in
> Osmarender.
>
> The sequence in which subordinate rules are processed within an <addclass>
> instruction are not strictly honoured.  Consider the following example:
>
> <addclass k="oneway" v="1|yes|true" class="oneway">
>     <rule e="way" k="highway" v="secondary">
>         <line class='highway-secondary' />
>     </rule>
>     <rule e="way" k="highway" v="primary">
>         <line class='highway-primary' />
>     </rule>
> </addclass>
>
> Normally you would expect all secondary ways to be rendered and then all
> primary ways.  However, with the introduction of the <addclass> instruction
> the rendering order becomes:
>
> 1 one-way secondary
> 2 one-way primary
> 3 two-way secondary
> 4 two-way primary
>
> So when you have a two-way secondary that meets a one-way primary the
> rounded end of the secondary road is rendered over the primary rather than
> under it.
>
> You can see an extreme example of this here, where lots of residential
> roads meet a main road:
> http://www.informationfreeway.org/?lat=51.46575646757731&lon=-0.29377692535288097&user=80n&zoom=17&layers=0B00F00
>
> Any ideas about how to fix this?


OK, I solved this by using a slightly different approach:

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

    <rule e="way"  k="oneway" v="1|yes|true" class="oneway">
        <rule e="way" k="highway" v="*">
             <line class="oneway"/>
        </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.

Is <addclass> actually used for any other purpose?  If not, I'd like to
propose that it be deprecated - it's implementation requires the xsl
set:difference extension which AFAIK isn't implemented in Firefox
(transformiix).  It's not guaranteed to be available in other xsl engines
either so it would be one less dependency to worry about.



Etienne
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070621/e7a665c3/attachment.html>


More information about the dev mailing list