[Tagging] Feature Proposal - TMC - New tagging scheme for TMC

Eckhart Wörner ewoerner at kde.org
Thu Apr 5 03:27:39 BST 2012


(sorry for starting a new thread, I just subscribed to the list)

> infoware GmbH, Bonn, Germany, and Geofabrik GmbH, Karlsruhe, Germany, have
> developed an improved tagging scheme for TMC data which we would like to
> propopose to the OSM community.

I believe this is much needed, so thank you for starting this effort.

The one thing I like very much about the proposal is that it allows people to 
start using TMC information without spending too much time implementing insane 
heuristics or programming shortest path algorithms.

However, I feel like there are some problems with your design, which should be 
discussed on a mailing list, since Wiki discussions are ugly.

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).

2) A matter of taste: + and -

I'm not sure how others are feeling about this, but I find DE:123+456, 
DE:456-123 somehow confusing. Here's an alternate proposal: DE:123+456 becomes 
DE:123->456, and DE:456-123 becomes DE:123<-456 (notice the changed order). 
Therefore, the LCD order is encoded in the position of the numbers, and the 
movement between the LCDs is encoded in the arrow.
I would go even one step further and allow ← (LEFTWARDS ARROW; U+2190) and → 
(RIGHTWARDS ARROW; U+2192) as an *alternative*. I know that not everybody 
knows how to enter these codes, but every editor and every operating system 
nowadays should be able to display them, and we have full unicode support in 
the database.
Because of 1), DE:123/456 does not make sense at all.

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.

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.)

5) Versioning

You argue that versioning is not needed, since data can be changed in a timely 
manner, and the errors that appear are mostly harmless. I don't feel that way:
a) Experience tells that data is not always changed in a timely matter, 
especially since TMC data does not appear on most of the maps. It takes a 
while to process data (being half a month outdated seems to be normal even for 
online routing), and offline maps make this situation worse (just look at the 
bug reports at MapDust that appeared since Skobbler had started shipping offline 
b) When LCDs are inserted into chains, things break *badly*, since the extents 
are then out of sync as well.

Eckhart Wörner

More information about the Tagging mailing list