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

[Jochen Topf]

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.)

Osmarender is complex as it is and gets more complex every day. 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.

And while, in this case, the rendering engine itself doesn't have to be
changed, the rules file does. 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.

Jochen
-- 
Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/  +49-721-388298