[OSM-talk] Layer transitions

Jochen Topf jochen at remote.org
Wed Aug 12 19:36:54 BST 2009


On Wed, Aug 12, 2009 at 07:18:03PM +0200, Pieren wrote:
> On Wed, Aug 12, 2009 at 7:04 PM, Martin
> Koppenhoefer<dieterdreist at gmail.com> wrote:
> > 2009/8/12 Jochen Topf <jochen at remote.org>:
> >> in real life bridges don't start in the *middle* of junctions
> >> so there *is* a little bit of non-bridge roads between the junction and
> >> the bridge.
> >
> > +1
> >
> 
> That's a stange argument. In real life, traffic signals are also not
> in the middle of junctions. So you add nodes per traffic signal on
> each way arriving at intersection ? In real life, oneway streets do
> not have oneway road sign on the middle of junctions, so you split
> your way to be sure that oneway is really starting at the right
> centimeter in the street ?

Modelling the real world is always a compromise. When mapping a oneway road
we do it from the junction, because it doesn't really matter where the sign
is exactly for the road to be oneway, also routers would get very confused
otherwise. But if the oneway sign is a few meters into the road, say after
an entrance to a parking lot that should be reachable, I'd split the road
there.

A traffic signal is something that probably belongs more to the junction than
the road, so it sort of makes sense there. But of course I can also move the
traffic signals somewhat down the road, if I want to have all the details, say
if there is a fan-out and only one branch has the traffic signal. I have never
tagged traffic signals myself, so I am not the expert on that.

But a bridge often needs a ramp, even if its a small one, so there is some
space there where the road is not a bridge yet. So I do think there is a
difference to the examples you mentioned.

But, again, the real world is always more complex than any rule people come up
with. I'll mostly go with the most practical compromise: Easy to map and easy
to use in current software. That often leads to inconsistencies, but
inconsistent is not necessarily bad. And if we get better software or more
detailed data or want to support new uses, we'll change things around.

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





More information about the talk mailing list