[Tagging] Comments wanted: Placement
imagic.osm at gmail.com
Fri Dec 21 12:06:06 GMT 2012
2012/12/21 Ronnie Soak <chaoschaos0909 at googlemail.com>:
> We don't force anybody to use a certain style. But we still say: If
> you don't use the style we use, your work will neither be rendered nor
> used by other consumers.
That's not fully correct (in this context): it will be rendered and it
will be used - but under wrong assumptions.
> Well, let's say we just use use a very mild form of force, ok?
> I think everybody who is willing to use your additional tag would also
> be willing to follow a certain 'convention' when it comes to the
> placement of the way.
> The only task would be to design that convention in a way that works
> well with all the roads that doesn't follow it.
Currently most people draw the OSM-way in the middle of the road. In
that case no extra tag is necessary. In my understanding your
requirement is fulfilled - isn't it?
> 'Line between directions' for single-way highways will probably only
> be off by half a lane in most instances. The same for 'middle of
> middle lane' (odd lanes) or 'line between middle lanes' (even lanes)
> on two-way highways.
Correct. But the course of the road/lane will be incorrect. If you
look at your lane assist and it shows you that the road makes a
slight/sharp/whatever left/right curve and you look at the road ahead
and it is completely straight you might get a little bit irritated.
And while you are irritated you miss your exit. Great! My point: the
position of the road as a whole is not so important (I don't say it is
not important, I say it is not so(!) important). Much more important
is the geometry and the layout of it. People should be able to
recognize the road from the display of the lane assist. (I'm
struggling a little bit with my "near-to-perfect" english; I hope it's
understandable what I wrote)
> I see that without an extra tag, a consumer can't decide if the way
> follows the convention or not. But that is the reason we kept the
> possible error at a minimum.
>> Neither the lanes-key nor any lane connection scheme can solve this.
>> Again - for example - look at the second image of "Motorway exit". It
>> is assumed that you know the lane count and the lane connectivity, but
>> without the information about the placement of the OSM-way in section
>> 3 a consumer has no mean determining the course of the lanes.
> I remember a proposal (or at least a discussion) where the lanes=* key
> had values for 'starting lane left' or 'ending lane right' etc. This,
> together with the lanes count before and after and a consistent
> convention on where the way is placed in reference to the lanes is
> enough to give you a rendering of which lanes continue and which end.
> (I think this was shot down because it needs so much splitting of the
> ways. But so does placement=*.)
Can't really imagine how that should look like. And there is one good
reason NOT to use the lanes key. It is defined and used (mostly) for
the number of lanes for motorized(!) general(!) traffic. What about
all the other lanes? The concept of that key is a little bit flawed in
>>> Imho introducing a tag that says how other tags work will make it more
>>> complicated for for data contributors, especially if this is
>>> introduces to other schemes where
>>> more than one possibility of tagging exists (public transportation,
>>> house numbers, etc.). It also has the chance of getting out of sync if
>>> some one changes the original tag (or in your case the relative
>>> position of the way)
>>> but doesn't change the meta-tag accordingly.
>> Absolutely correct - as with nearly all other tags. Someone moves a
>> node for any reason. But on that node a traffic sign is mapped. Or its
>> a connection between two ways and the maxspeed changes. Or the lane
>> count. Or anything else. Information is now out of sync. All the same.
> I would not put 'changing the beginning of a maxspeed zone by 4m' and
> 'completely destroying the lanes rendering' in the same category
> But both will happen if I move a single node by a mere 4m without
> looking at the tags.
But you are not destroying the lanes rendering completely. It is just
off by 4m, just like the maxspeed zone. But thanks for that comment:
it made me thinking and I discovered an undefined state at the
end/beginning of a way that is tagged with
placement=right_of/left_of/middle_of. This is the same problem as
right now with a change of the lane count. If you're interested: have
a look at the second example in "Motorway exit" and assume that
section 3 is wrongly tagged with e.g. placement=right_of:2. Now think
about how the lanes should be rendered.
> So I whisper: there isn't so much effort if the tool support is good
> and you stay above max zoom level.
> But if you WANT to add that much detail, it is possible and will give
> good gain. Also it will solve a lot of problems with one scheme
> instead of several ones like your placement, the junction discussions,
> the trunk/accelearation/decelaration lines discussion, the
> legal/physical lane seperation discussion etc...
First of all you need tool support. Everyone else with a tool without
that support will immediately have problems. Secondly I think it is
always a good idea to have some levels of detail and tagging schemes
that build upon each other. I think that the placement key works
perfectly together with the area:highway idea. I see the area:highway
just as the most advanced way to specify the outline of the road; one
of a few ways.
> But now I better shut up.
Not because of me. I want tagging schemes which are as simple as
possible to reach some specific goal. Different approaches are a good
way to identify such tagging schemes.
More information about the Tagging