[Tagging] Feature Proposal - RFC - Directional node
zverik at textual.ru
Tue Aug 9 15:11:23 BST 2011
> Fundamentally, I think we need to remember that OSM is not intended to
> be a true representation of the world, but rather a logical
So why do we have tags for road signs and trees and colours then?
> The direction that a bench, or a sign faces is not significant from
> the perspective of a map. When you get to the object, you'll see its
> direction, and you don't need to know the object's orientation to get
Of course. When you get to the road you'll see its surface and lane count,
and you don't need to know those attributes to get there. OSM offers many
perspectives. From the perspective of routing the direction of road sign is
important. From the perspective of 3D rendering physical attributes and
rotation are important. OSM has stopped being just a map the moment someone
specified building levels count.
> The problem with a direction tag is that then suddenly every object
> has a direction relation, and we make editing the map far more
"The problem with a name attribute is that then suddenly every object has a
name tag, and we make editing the map far more complex." This is not a
proposal's problem, but with relations in general, I guess? Why editing
them should be harder than editing tags? Should we reduce their count to
mininum, creating alternative ways to map turn restrictions, destination
signs, surveillance cameras, public transport routes?
> A simple tag seems the right solution in the rare circumstance where
> that's needed.
So, is it "rare" of "every object has a direction"? Is a simple tag really
that simple — making users to guess an angle in degrees, removing a
connection between a road sign and a road? I see zero uses of "compass" tag
in taginfo and less than fifty correct numeric values for "direction". And
a lot of proposals and questions in talk pages about specifying direction
for point features, mostly ending with a very bad and unmaintainable
More information about the Tagging