[OSM-dev] [OSM-talk] 1) Messy Overlapping 2) Messy Layers 3) Bridges 4) Trunk/primary 5) Forum

80n 80n80n at gmail.com
Sun Feb 11 15:39:53 GMT 2007


On 2/11/07, Jochen Topf <jochen at remote.org> wrote:
>
> On Sun, Feb 11, 2007 at 02:57:11PM +0000, 80n wrote:
> > >Generally there is no need for the core=yes element. As far as I can
> see
> > >the problem only occurs in T-shaped junctions (or topological similar)
> > >where the through road has a "lower classification" than the ending
> road.
> > >So if there is a primary road ending at a T-junction and the
> > >unclassified road goes through the same junction, you'll see the ugly
> > >round knob in the junction. But it certainly is computationally
> possible
> > >to find those T-junction cases and re-order the drawing of the ways.
> > >
> > >Problem is: This gets messy once we are not only looking at one
> junction
> > >but at a whole road network, and it gets really messy once we take
> layers
> > >into account. But I don't see how the core=yes helps here. It only
> makes
> > >things more complicated. Certainly for the person doing the tagging.
> >
> >
> > Ben's solution is to tag a short section of the unclassified road as
> > core=yes.  This causes it to be re-rendered after the core of other more
> > major roads have been rendered.
> >
> > The approach is not dissimilar to the way that layers work, except its
> only
> > within the road rendering section.
> >
> > It's elegant because it keeps the rendering engine simple, the results
> are
> > better and the presence of an extra tag is non-invasive.  Other
> renderers
> > can ignore it and osmarender can ignore it when a better solution is
> found.
> >
> > I think I'd prefer the tag to be renderCoreLast=yes as this makes it a
> > little clearer than just core=yes.
> >
> > It's unwise to be critical of people who are doing innovative things
> with
> > osmarender rules files unless we actually have something better to
> offer.  I
> > know Ben has a very fine eye for detail and cares a lot about the
> appearance
> > of his maps.  He has done something interesting here to solve a small
> > problem that we have not yet paid attention to in osmarender.
>
> Actually I have thought about this problem a lot and so-far failed to
> find a fix that I am happy with. Having an extra tag doesn't fix the
> problem in the general case (as I have explained) and it makes Osmarender
> more complicated. I fail to see why thats supposed to be an improvement.
> (And its a hack that masks part of the problem, which could lead to less
> incentive to solve the real problems.)


So Ben's solution is the best that is known at the moment, right?


Osmarender is complex as it is and gets more complex every day.


Actually it isn't very complex at all.  Most of the complexity (and most of
its limitations) are cleverly delegated to SVG and CSS.


There is a
> real danger here of producing a rendering software thats un-supportable,
> because every time you change something, one hack or another stops
> working. All those hacks always have side effects, so it makes sense to
> look at them really really closely, before they are introduced into the
> software.


Yes, I am not entirely happy with the <addclass> element which mixes the
processing of the rules engine with that of the instruction processor.  Up
to now these have been kept separate to keep things simple.  Mixing them in
the <addclass> element has increased the complexity of osmarender4
unncessarily IMHO.


And while, in this case, the rendering engine itself doesn't have to be
> changed, the rules file does.


That is the whole purpose of having a rules file - separate the skills - so
that people with an eye for rendering can create rules files that do what
they need with tags that they need.  This is an entirely appropriate way to
do this.

That might not be quite as problematic as
> changing the engine, but it also adds to the complexity. Already the
> engine and the rule file are too much intertwined to understand one
> without the other. In a way, changes to the rules file are even worse,
> because you need many rules files for the slippy map (for each zoom level)
> while you only need one core engine.


So solve that problem then!  Separate out the style section of the rules
file from the rendering order.  Then you can have one rendering order for
all levels and a different style section for each zoom level.



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/20070211/d9389ff1/attachment.html>


More information about the dev mailing list