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

[Sven Anders]

Am 05.02.2011 15:01, schrieb 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 */

(ich erfinde mal etwas ich kenne die polnischen TMC Daten nicht (gibt es 
welche?) und bin zu faul die deutschen nachzusehen)

Nehmen wir den Grenzübergang Deutschland Polen:

TMC:cid_62:tabcd_1:LocationCode=27313

In Deutchland hat der selbe Grenzübergang (im Zweifel ein OSM Node) den 
Eintrag:

TMC:cid_58:tabcd_1:LocationCode=52323

Außerden könnte es sein, das sich 2012 die Hälfte aller Hersteller aller 
Navis zusammentun und ein eigenes TMC Schema mit tabcd 2 erfindet, weil 
sie  das Deutsche Bundesamt saftige Gebühren für die Nutzung unter einer 
unfreien Lizenz einführt.  Dann gebe es evtl. noch einen Enitrag:

TMC:cid_58:tabcd_2:LocationCode=99432

Wenn man sagt: Wer TMC benutzen möchte soll sich die Daten vom Bundesamt 
sowieso holen (und diese nicht aus OSM auslesen), dann könnte man aber 
vermutlich auf einige (?alle) anderen Daten außer dem LocationCode 
verzichten. Mein Problem ist das ich den Aufbau von den 
Verkehrsmeldungen nicht so gut kenne, um das einzuschätzen, aber ich 
denke das das z.B. Pascal gut kann, und der beteiligt sich ja bereits an 
der Diskussion und will auf der Fossgis dazu einen Vortag machen.


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

Auf die Idee sind wir damals beim besprechen der Tags auch gekommen. 
Aber es würde halt dazu führen, das wir bestimmte Punkte die von zwei 
Ländern für wichtig angesehen werden, nicht mehr gut in OSM abbilden 
könnten. Man könnte natürlich für jedes Land eine eigen Relation anlegen...


Gruß
Sven