[OSM-talk] Layer transitions

Lambert Carsten lhc.osm at solcon.nl
Fri Aug 7 08:39:49 BST 2009


On Friday 31 July 2009 17:25:19 Richard Mann wrote:
> I saw some strange rendering effects when a side road was straight onto a
> bridge. The bridge was layer=1, so the side road was rendered on top of the
> main road. That's why all the ways approaching a junction should be on the
> same layer. You can either achieve this by inserting a short way between
> the bridge and the junction, or by altering the layer of the thing that is
> bridged (ie making the stream layer=-1)
Recently we have been discussing this problem on the Dutch talk list regarding 
bridges. Keepright doesn't like T-juntions  with different layers and tags 
these as 'not so obvious' errors.

The reasoning that we map the centre of the road is faulty. That reasoning 
implies that we need to split up the road because the sidewalk does not 
either continue to the centre of  the crossing road.

Adding a little piece of road so the junction can be on one layer just does 
not make sense. In Amsterdam there are lots of bridges and canals.
The canals there are physically not on the same layer as the road and bridges. 
But for practical reasons we only add layer tags where ways cross without 
connecting (bridge over water). This 'T-junction rule' is causing just about 
every bridge to have small extra bits added. Or have roads that do not cross 
anything tagged as layer=1.
On the discussion list the argument is made that we don't need a layer tag for 
bridges and tunnel (except of course when there are more than two ways 
above/under each other) and I agree with that. So simply removing the layer 
tag on most tunnels and bridges would resolve the layer issue. However I am 
not sure if it is generally accepted that it is wrong to tag a bridge or 
tunnel with a layer attribute.

The renderers already seem to have a problem with the names of roads when they 
are split up into bits. Adding these extra little bits will just make things  
worse. It seems to me that those rendering problems (at least with bridges) 
would be much better solved by looking at whatever the bridge is crossing and 
use that to decide how to render a bridge that creates a T-connection with a 
way. And if Keepright can see that a bridge or tunnel is connected to a 
T-junction why can't a renderer come to the same conclusion and render 
differently? 

>
> Richard
>
> On Fri, Jul 31, 2009 at 11:01 AM, "Marc Schütz" <schuetzm at gmx.net> wrote:
> > > to make my question more precise, please have a look at this tunnel
> > > that crosses a railway track (the railway is a subway that runs at
> > > ground level):
> >
> > http://www.openstreetmap.org/edit?lat=48.1325961&lon=16.3109488&zoom=19&w
> >ay=29205957
> >
> > > The tunnel tag implies layer=-1
> >
> > No, it doesn't.
> >
> > > and that leads to a junction of ways on
> > > different layers on both ends of the tunnel.
> >
> > Which wouldn't be a problem either. Layer is only relevant for defining
> > the relative order of intersecting (crossing) objects. If the objects
> > don't intersect, or have a common node, their layers don't imply anything
> > about their relative or absolute height.
Absolutely!

In any case, PLEASE let us get rid of this 'rule' that a T-junction has to be 
on the same layer.

> >
> > > On the western end of the tunnel the adjacent way ends, this should be
> > > no problem with the layers; on the eastern end there is a T junction.
> > >
> > > Do you think, this tunnel is OK the way it is or should someone add a
> > > small piece of way on layer 0 at the eastern end next to the T-junction
> > > to avoid a T-junction of different layers?
> >
> > It is ok as it is.
> >
> > Regards, Marc
> >
> > --
> > Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3
> > - sicherer, schneller und einfacher!
> > http://portal.gmx.net/de/go/atbrowser
> >
> > _______________________________________________
> > talk mailing list
> > talk at openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk






More information about the talk mailing list