On Mon, Sep 21, 2009 at 8:21 AM, d f <fac63te...@yahoo.com> wrote: > It was more an off the top of my head comment really. > Would having it independent make it easier for the renderers? >
I think the important question is, does it add information? Probably so. A bridge really is more than just a collection of ways. It might be significantly larger than the ways on it. A bridge should probably have its own geometry. And if a bridge has its own geometry (polygon or line and width) and a layer tag you don't even need the relation, do you? Anything in the area of the bridge with the same layer is located on the bridge. The only issue I see is when when a bridge only consists of a single way, it'd be a pain to add *another* way, with the same geometry, to represent the bridge. So the renderers would have to special case this. Maybe.... Okay, I have a proposal. I can bet some people are going to hate me for it, but I'm going to propose it anyway... amenity=bridge (or would it be landuse=bridge?), to be attached to a way or polygon. layer tag is used to indicate the layer. If a bridge is equivalent to a single way, you can attach amenity/landuse=bridge to the way (after splitting) instead of creating a separate way. bridge=yes could, and probably should, still be attached to the way. It will indicate that the way is *on* (over?) a bridge, not that the way *is* a bridge. No relations, unless you want to add them as redundant information to make it easier to calculate which ways are on which bridges (but this can be obtained from the geometry, the layer tag, and the bridge tag). Would it affect routers? Would a route be described as "cross this bridge, > then turn left in 200 metres"? > I doubt most routers are going to bother with information that isn't part of the way or the nodes directly on the way. It would certain save time splitting the ways. > The way should probably still be split, at least to add the layer tag, and arguably to add the bridge=yes, which indicates that the way is indeed on a bridge.
_______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
