[Talk-de] TMC-Reform (war Re: Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?))

[Wolfgang]

Hallo,
Am Samstag 05 Februar 2011 10:28:24 schrieb Ulf Lamping:

[ ]
> 
> "(CID) is replaced by the country-id (e.f. 58 for Germany)"
> 
> legt nahe, daß hier schlicht ein Tippfehler ist und es besser:
> 
> "(CID) is replaced by the country-id (e.g. 58 for Germany)"
> 
> heissen sollte (hab's korrigiert). Aus diesem Satz kann man schon gut
> herauslesen, daß CID dann wohl eine Abkürzung für country-id sein dürfte
> und 58 dabei der Wert ist, der Deutschland repräsentiert.
> 
> 
> Die Beschreibung ist allerdings aus anderen Gründen unzureichend. Ich
> kann herauslesen wie die Tags zustandekommen.
> 
> Damit kann ich aber weder meine eigene TMC Software schreiben (die
> Abbildung der TMC Empfangsdaten auf die Tags bleibt unklar) - was
> allerdings auch nicht unbedingt hier stehen muß.
> 
> Auch ist es keine gute Anleitung wie ein Mapper mit diesen Tags
> umzugehen hat. Das Problem haben wir aber auch bei vielen anderen Tag
> Beschreibungen.
> 
[ ]
> 
> Man könnte sicher hier und da Sachen vereinfachen, aber so krass wie du
> es darstellst ist es nun auch nicht ...
> 
> Gruß, ULFL
> 
> P.S: Das die Beschreibung etwas kryptisch ist, liegt sicher auch daran,
> das bislang kaum einer danach gefragt hat. Ich kann mich zumindest nicht
> dran erinnern, daß hier vorher schonmal solche Fragen wie deine gefragt
> wurden.

nachdem dieser Thread aus dem ursprünglichen destruktiven Ansatz in ein 
sachlicheres Fahrwasser gelangt ist, könnte man sich vielleicht überlegen, wie 
man die tags so gestaltet, dass sie von Nicht-Insidern wie mir auch erahnt und 
vor allem einigermaßen sicher gehandhabt werden.

Das Problem sehe ich weniger im Löschen oder Nicht-Verstehen der tags. Wenn da 
"tmc-Kram" drin steht, lass ich die Node am Way dran, lösche, falls 
erforderlich, eine andere und schiebe diese dann so, dass es geometrisch 
passt. Mit Ampel- oder anderen tags beißt es sich auch nicht, das ist nicht 
die eigentliche Baustelle.

Ein Problem bekommt der Normalmapper, wenn eine Straße, wie selbst in den 
Großstädten noch häufig, nicht korrekt gemappt wurde. Problematisch ist häufig 
die Zuordnung baulich getrennt - nicht baulich getrennt. Wenn das falsch 
gemappt wurde, ist das verwirrend für den Benutzer, der die Karte mit der 
Realität vergleicht.

Hier beginnt jetzt die Schwelle für den Mapper. Was soll er mit den ganzen 
Sch****-tags und -relationen machen, die tmc, Bus und weiß-der-Henker-was 
betreffen? Ich habe mal in HH eine ziemlich zentrale Hauptstraße trennen 
müssen. Man muss da schon etwas Mut zur Lücke haben und ansonsten einfach 
raten und sich ein paar Stellen ansehen, wo die Fahrbahnen entsprechend 
getrennt sind. Hier sollten wir ansetzen, nach dem Motto: Wenn etwas 
funktionieren soll, frage jemanden, der sich damit auskennt, aber wenn du 
etwas erklärt haben willst, frage jemanden, der sich damit nicht auskennt. Ein 
Experte kann meistens nicht beschreiben, was ihm selbst klar ist.

Ich bin dafür, 
1. die tags so weit wie möglich in eine verständlichere Schreibweise 
umzusetzen. Das kann durch ein Script geschehen, wenn man sich auf eine 
Schreibweise verständigt hat. Dabei geht die schon erbrachte Arbeit nicht 
verloren.
2. im Wiki ein Kochrezept zu hinterlegen, mit dessen Hilfe der Mapper die 
häufigsten Vorgänge wie Punkt verschieben, Fahrbahnen trennen, Fahrbahnen 
zusammenfassen, Abbiegespur abtrennen etc. einfach bearbeiten kann.
3. für die Editoren ein plugin anzubieten, dass die Standardaufgaben dem 
Mapper abnimmt.
4. das ganze nicht nur für tmc, sondern auch für Bus-Relationen und andere 
nicht selbsterklärende Objekte.

Bespiel:
TMC:cid_58:tabcd_1:Class=Point

TMC = Namensraum, sinnvoll
cid_58 haben wir jetzt gelernt, ist Deutschland. Besser wäre möglicherweise  
TMC:country=58;(germany)
tabcd_1 sagt mir gar nichts, ich habe auch nicht nachgesehen, will ich auch 
nicht, ich will mappen. Wie wäre es mit TMC:whatever=1;(verständliches 
Stichwort)?
Class sagt mir, dass hier irgendetwas klassifiziert wird, vermutlich, dass es 
sich um einen Einzelpunkt handelt. Also:
TMC:Class=Point

Damit würde aus dem obigen
TMC:cid_58:tabcd_1:Class=Point

ein
TMC:country=58;(germany)
TMC:TableCommand=1;(very important)	/* frei geraten */
TMC:Class=Point;(single waypoint)	/* auch frei geraten */

Das hat natürlich den Nachteil, dass aus einem tag 3 werden. Möglicherweise 
kann man aber davon auch etwas weglassen, weil es sich von selbst ergibt, wie 
z.b. germany.

Weiter:
TMC:cid_58:tabcd_1:Direction=positive

Das tag hat der tmc-Punkt auf der Gegenfahrbahn genauso. Warum auch immer. 
Hier reicht

TMC:Direction=positive(short keyword, why)

Weiter:
TMC:cid_58:tabcd_1:LCLversion=8

TMC:Version=8	/* verständlich, wenn jetzt aus dem LCLversion ein GPLversion=8 
werden sollte, kann man immer noch Gversion taggen ;-)  */

Weiter:
TMC:cid_58:tabcd_1:LocationCode=35565

TMC:LocationCode=35565;(coded position in tmc-Stream)

Weiter:
TMC:cid_58:tabcd_1:NextLocationCode=46004

TMC:NextLocationCode=46004

Damit heißt es:
TMC:country=58;(germany)
TMC:TableCommand=1;(very important)
TMC:Class=Point;(single waypoint)
TMC:Direction=positive(short keyword, why)
TMC:Version=8
TMC:LocationCode=35565;(coded position in tmc-Stream)
TMC:NextLocationCode=46004
TMC:PrevLocationCode=46003

Wenn ich es richtig sehe, werden in osm nur Einzelpunkte mit tmc-Info belegt, 
dann könnte das Point-Tag entfallen. Country könnte die Software recht einfach 
ermitteln und den code aus einer Tabelle holen. Ob weitere tags weggelassen 
werden können, müssen die Insider entscheiden. Mir erscheint es jedenfalls nur 
begrenzt sinnvoll, dass alle Locaction- und Prev/Next-Tags für beide 
Fahrtrichtungen gleich sind.

Vielleicht reicht ja ein
TMC:Version=8
TMC:LocationCode=35565;(coded position in tmc-Stream)

So, das war ein von keiner Sachkenntnis getrübter Versuch, das ganze etwas 
konstruktiv voran zu bringen. Jetzt könnt ihr ihn zerpflücken, bis nichts mehr 
übrig ist.  ;-)

In diesem Sinne,
Gruß, Wolfgang