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

Di Feb 8 09:36:53 UTC 2011

Mein lieber Ulf,

Können wir hier nicht redlich diskutieren? Denn wir sind in vielen
Teilen glaub' ich einig. Also:

Ich sage nur, dass es von Vorteil wäre, wenn in OSM die Inhalte
(Semantik) verständlich beschrieben. Dies erst recht, wenn es sich um
eine "komplexere" Materie handelt, es wenig zugängliche Literatur gibt
und es sich um ein (an sich lobenswertes) grösseres Vorhaben handelt.
Das gilt für TMC zu auch auch für OePNV. Wer das als Papierkram
auffasst oder wem ein Internetprotokoll mehr liegt, soll sich mit
anderen zusammentun.

Du schreibst zur Forderung nach einfachen Modellen:
> Ich glaube nicht das dies der wirklich kritische Punkt ist.

Was denn?

und weiter:
> Über das Problem sinnvoll eine externe DB mit unserer zu verzahnen,
> also mit Minimum an manuellem Aufwand und benutzbar für Datenanwender,
> hatten wir doch schon häufiger gesprochen und bislang m.W. noch
> keine wirklich brauchbare Lösung gefunden.

Hat das schon jemand vergeblich vesucht? Wenn handeln besser als reden
ist, dann hier!

Zurück zu TMC Modell:

Man könnte nun klären, ob die Tables-Angabe nötig ist. Das hat meines
Wissens nicht mit länderübergreifenden Meldungen zu tun, sondern mit
der Tatsache, dass ein Land mehr als ein Table haben kann. Wenn nein,
ergäbe das den Tag "tmc:locationcode=countryid_58:52864". Das müsste
für die Variante Verknüpfung mit externer DB reichen.

Wenn die aktuelle Variante so bleibt, hätte ich da noch eine ganze
Reiher grundlegender Fragen: Wenn so bleibt, wie es jetzt angelegt ist
und es gibt zwei Tables (oder zwei Länder) und je zwei LCLVersionen,
dann müssten wir mit zwei, vier, sechs Tag-Gruppen à je sechs Tags
rechnen, oder? Da lohnt es sich m.E., sich das nochmals zu überlegen.

Da wird z.B. offenbar eine Relation an einen Node gehängt:
http://www.openstreetmap.org/browse/relation/374604

  <relation id="374604" ...>
    <member type="node" ref="10210539" role=""/>
    <tag k="TMC:cid_58:tabcd_1:Class" v="Point"/>
    <tag k="TMC:cid_58:tabcd_1:Direction" v="both"/>
    <tag k="TMC:cid_58:tabcd_1:LCLversion" v="8.00"/>
    <tag k="TMC:cid_58:tabcd_1:LocationCode" v="35722"/>
    <tag k="TMC:cid_58:tabcd_1:NextLocationCode" v="46160"/>
    <tag k="type" v="tmc"/>
  </relation>

Da scheint etwas redundant (oder aber "überlagernd") zu sein, wenn man
mit dem Mitglieder-Knoten 10210539 vergleicht
http://www.openstreetmap.org/browse/node/10210539 :

  <node id="10210539" lat="53.4710971" lon="9.9011535" ...>
    <tag k="highway" v="traffic_signals"/>
    <tag k="TMC:cid_58:tabcd_1:Class" v="Point"/>
    <tag k="TMC:cid_58:tabcd_1:LCLversion" v="8.00"/>
    <tag k="TMC:cid_58:tabcd_1:LocationCode" v="25005"/>
    <tag k="TMC:cid_58:tabcd_1:PrevLocationCode" v="25004"/>
    <tag k="TMC:cid_58:tabcd_1:NextLocationCode" v="25006"/>
    <tag k="TMC:cid_58:tabcd_1:Direction" v="both"/>
  </node>

* Das sind praktisch dieselben Tags aber mit anderen Values(?).
* Macht das Sinn, eine (oder mehrere) Relation(en) pro Node?
* Warum fehlt bei der Relation PrevLocationCode?
* Für was brauchts Class Point, wenn es schon ein Node ist?

Wäre das nicht viel eleganter:

  <node id="10210539" lat="53.4710971" lon="9.9011535" ...>
    <tag k="highway" v="traffic_signals"/>
    <tag k="tmc:de:locationcode" v="25005"/>
    <tag k="tmc:de:prevlocationcode" v="25004"/>
    <tag k="tmc:de:nextlocationcode" v="25006"/>
    <tag k="tmc:de:direction" v="both"/>
  </node>

d.h. ohne zus. Relation., ohne Tablecode und ohne LCLversion und mit
bekannten Länder-Code ISO-3166 (anstelle '58').

Für die Editoren-Erweiterungs-Diskussion wäre das ein Hinweis, Prefixe
wenn schon aufklappbar, dann mit mehreren Stufen darzustellen, also
aufgeklappt (und mit zweitem LocationCode für die Niederlande):

o highway = traffic_signals
+ tmc
   + de
      o locationcode = 25005
      o prevlocationcode = 25004
   + nl
      o locationcode = 11013

LG, S.

Am 7. Februar 2011 02:51 schrieb Ulf Lamping <ulf.lamping at googlemail.com>:
> Am 07.02.2011 01:21, schrieb Frederik Ramm:
>>
>> Hi,
>>
>> Stefan Keller wrote:
>>>
>>> => Daher könnte z.B. folgendes etwas sinniger sein:
>>> "tmc:locationcode=countryid_58:tablecode_1:52864".
>>
>> Ich denke, man koennte auch den Mut zur Luecke haben und einfach nur
>> "tmc_location_code=52864" schreiben oder so. Ok, man kriegt damit keine
>> laenderuebergreifenden Meldungen abgebildet, aber kommen die so oft vor?
>
> Frag mal die Leute in Trier, die können dir da ein Lied von singen ;-)
>
>> Ebenso mit dieser "table" (ulkigerweise dachte ich anfangs wegen "tabcd"
>> immer, das waere ein Beispielwert, a-b-c-d...) - wenn es wirklich mal zu
>> dem unwahrscheinlichen Fall kommt, dass wir zwei "Tables" parallel in
>> OSM abbilden muessen, kann man das Problem *dann* loesen. (Es entspricht
>> nicht der Tradition von OSM, ein komplexes Modell aufzubauen fuer Zeugs,
>> das noch gar nicht gebraucht wird und bei dem unklar ist, ob es
>> ueberhaupt jemals gebraucht wird - man macht erstmal was einfaches und
>> kann das dann spaeter immer noch erweitern.)
>
> Ich glaube nicht das dies der wirklich kritische Punkt ist.
>
>> Also ich koennte mir durchaus vorstellen, dass es gelingt, den groessten
>> Teil des TMC->OSM-Matchings komplett extern zu machen, so dass man den
>> gewuenschten Nutzen auch erzielen kann, ohne dass TMC-Tags in OSM sind.
>
> Über das Problem sinnvoll eine externe DB mit unserer zu verzahnen, also mit
> Minimum an manuellem Aufwand und benutzbar für Datenanwender, hatten wir
> doch schon häufiger gesprochen und bislang m.W. noch keine wirklich
> brauchbare Lösung gefunden.
>
> Du kennst das Bild mit dem "und hier geschieht ein Wunder" Kasten kurz vor
> der Fertigstellung?
>
> http://www.ethikpartei.ch/miracle1.jpg
>
> Gruß, ULFL
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>