[Tagging] Feature Proposal - TMC - New tagging scheme for TMC
ewoerner at kde.org
Fri Apr 20 14:39:00 BST 2012
Am Freitag, 20. April 2012, 14:32:17 schrieb Heinrich Knauf:
> > 1) The big problem: missing directional information
> > Let's assume there is a way in OSM tagged tmc=DE:123+456;DE:456-123. One also
> > has real-time traffic information that talks about a traffic jam at LCD 456,
> > negative direction, extent 1. One therefore knows that this traffic jam affects
> > DE:123-456, and since we have a way with that information, we know that this
> > way is affected.
> > However, there's one problem: which direction of the way is affected? It could
> > be either the direction from the first point of the way to the last (called
> > forward from now on), or vice versa (backward). This essential information is
> > missing and makes the TMC information on non-oneway ways useless.
> > There are several solutions to this problem. Probably the best solution is not
> > using the tmc tag at all, but using tmc:forward and tmc:backward instead. Thus
> > assuming the direction of the way is from LCD 123 to LCD 456, the tagging
> > would be tmc:forward=DE:123+456, tmc:backward=DE:456-123. "forward" and
> > "backward" are already used in tagging (for example, maxspeed:forward) and are
> > also protected by tools. E.g. if you try to reverse the before-mentioned way,
> > JOSM suggests to swap tmc:forward and tmc:backward (which is the correct thing
> > to do in that case).
> That's no problem at all. The TMC direction must not be mixed up with
> the driving direction, which here does not matter at all. All that
> counts is the direction given (and defined) by the TMC data. If a
> traffic event extends "forward" woth respect to the direction defined by
> TMC, then "+" is used, if it extends in the revers direction, we use
> "-". This is very concise, and using "forward" or "backward" instead
> would just blow the tags.
Please re-read my argument. (Note that I use "positive"/"negative" to indicate a direction along TMC chains, and "forward"/"backward" to indicate a direction along an OSM way).
Arguing that the driving direction does not matter at all is wrong as soon as you're not talking about oneways anymore. An event affecting the positive direction of a TMC chain may affect either the forward or the backward direction of an OSM way, and this entirely depends on the OSM way.
> > 3) Bad influence: TMC information at junctions
> > One thing that I cannot wrap my head around is the TMC information *at*
> > junctions. As far as I remember, a traffic jam at LCD 456, negative direction,
> > extent 1 affects the road *between* LCD 123 and LCD 456, but not the actual
> > junctions 123 or 456. However, the rules of adding tmc tags to the actual
> > junctions influence a lot of maneuvers going over those junctions but not using
> > any other part of the way. This is especially true for roundabouts or
> > junctions between dual carriageways.
> Please could you supply an image, or probably refer to the figures and
> the numbering that we use in the proposals examples? That would make it
> a lot clearer.
See http://wiki.openstreetmap.org/wiki/DE_talk:Proposed_features/New_TMC_scheme#Auswirkungen_von_TMC-Nachrichten_an_Kreuzungen for a discussion of the problem.
> > 4) Exits and entries
> > TMC specifies messages that apply to entries or exits, which I feel are not
> > adequately represented in the proposal, even though the proposal mentions
> > them. For example, assume that the 2nd exit slip road going west at Köln-Süd
> > (where I already discovered the new tagging) is closed (and I believe there is
> > a TMC message for that). How do I find this 2nd slip road? (Yes, I picked a
> > really hard one.)
> Isn't that just a matter of the granularity of TMC location coding
> versus OSM mapping? If so, then there's nothing to help about that with
> any TMC tagging scheme whatsoever.
Unless I'm wrong (and I haven't read the TMC specs in a while) this should be possible with TMC, OSM just needs to supply the relevant data.
Anyway, parts of this have been covered in a different mail.
More information about the Tagging