[OSM-dev] Osmarender - addclass problem

80n 80n80n at gmail.com
Fri Jun 22 13:28:12 BST 2007


I plan to release the next set of tiles at 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.

Etienne

On 6/22/07, Jochen Topf <jochen at remote.org> wrote:
>
> On Thu, Jun 21, 2007 at 12:13:57PM +0100, 80n wrote:
> > 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">
>                                              ~~~~~~~~~~~~~~~
>                                              I guess this is a
>                                              cut-and-paste error
> >        <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.
>
> You're probably right. Your new approach looks better.
>
> Jochen
> --
> Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/
>   +49-721-388298
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070622/fb5ba098/attachment.html>


More information about the dev mailing list