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

Heinrich Knauf knauf at infoware.de
Fri Apr 20 13:32:17 BST 2012


Am 05.04.2012 04:27, schrieb Eckhart Wörner:
> Hi,
>
> (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).
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.
> 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.
OK, I think special unicode characters should not be used at all because 
compatibility is uncertain and they are not available at any keyboard. 
Using "+" and "-" is just straightforward. I would not expected 
intereference or incompatibility with any other software from these, and 
for the tests that we made so far everything works fine.

However,  anybody having made experience with the issue what special 
characters to use for tagging without running into compatiblilty 
problems: Please would you share your ideas, your opinion is greatly 
appreciated.
> 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.
>
> 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.
>
> 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
> maps).
> b) When LCDs are inserted into chains, things break *badly*, since the extents
> are then out of sync as well.
Since TMC tags will simply be part of all other road network data that 
any solution will use for mapping, navigaiton, etc., they will always 
fit together from the time of creation. So there's n need for 
versioning. On the other hand, it is abolutely certain that the issueing 
organisations that are in charge of TMC (like BASt in Germany) will 
never "re-cycle" previosly used location codes in a way that  might 
create trouble.
>
> Eckhart Wörner
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging

Best regards,
Mit freundlichen Grüßen,
Heinrich Knauf

infoware GmbH
Riemenschneiderstr. 11
53175 Bonn
GERMANY

facebook_follow_us <http://facebook.infoware.de/>

office: +49 228 338899-21
email: knauf at infoware.de <mailto:knauf at infoware.de>
web: www.infoware.de <http://www.infoware.de>
infoware Gesellschaft für Informationstechnik mbH
Geschäftsführer: Thomas Schulte-Hillen, Martin Langhoff;
Sitz Bonn; Amtsgericht Bonn HRB 14141

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120420/043f1169/attachment.html>


More information about the Tagging mailing list