[Talk-de] Koennen wir die TMC-Daten rauswerfen?

[Jan-Benedict Glaw]

On Wed, 2011-02-02 14:22:50 +0100, Frederik Ramm <frederik at remote.org> wrote:
> On 02/02/11 12:34, Peter Wendorff wrote:
> > Das Wiki dokumentiert eigentlich insgesamt recht gut, was da gemacht
> > wird und welches Tagging-Schema verwendet wird.
>
> Also offensichtlich gibt es da eine TMC-Datenbank mit bestimmten  
> Punkten, die Vorgaenger und Nachfolger haben - also sowas wie Ways bei 
> uns.

Richtig; zusätzlich gehören die allermeisten Objekte immer auch einem
höherwertigen Objekt an. (Autobahn-Abfahrt -> Streckenabschnitt ->
Bundeland)

> Diese Datenbank ist von sich aus, so wie ich das verstehe, erstmal  
> konsistent, d.h. alle Vorgaenger und Nachfolger existieren tatsaechlich,  
> es gibt keine Luecken usw.
>
> Nun ist es eine Sache, die einzelnen Punkte auf OSM abzubilden. Das  
> waere ideal komplett extern, aber es ginge auch noch mit einer TMC-Id an  
> einem OSM-Objekt ("dieses OSM-Objekt ist in der TMC-Datenbank der Knoten  
> 12345"). Dafuer brauche ich genau ein Tag, das ich noch dazu relativ  
> menschenlesbar gestalten koennte, z.B.
>
> tmc_code=12345

Das reicht leider nicht, weil damit die /gerichtete/ Natur der
BASt-Liste nicht abgebildet werden kann. Ein TMC-Code alleine sagt Dir
noch keine /Richtung/.

> Wenn ich nun aber - aus welchen Gruenden auch immer - damit beginne,  
> nicht nur ein Mapping zwischen dem externen Graphen und der  
> OSM-Datenbank zu bauen, sondern den externen Graphen direkt in OSM  
> einzubauen, dann gibt das ganz verschiedene Probleme. Ich schaffe damit  
> (logisch betrachtet) ja ein zweites Netz von Ways, die von einem  
> TMC-Knoten zum naechsten fuehren. Das wird nun krude ueber eine Art  
> "Vorgaenger-Pointer" abgebildet, der, je nachdem, wie die OSM-Datenbank  
> grade dasteht, auch mal ins Leere zeigen kann, weil das entspr. Objekt  
> bei OSM fehlt oder umgetaggt wurde - obwohl ich aus der externen  
> Datenbank ja wissen koennte, welches das betr. Objekt ist...

Das wiederum läßt sich anhand der Dumps recht einfach testen.

> Bliebe herauszufinden, *wieso* hier die Enscheidung getroffen wurde,  
> nicht nur die Nodes zu mappen, sondern auch den Versuch zu unternehmen,  
> den kompletten Graphen mit zu uebernehmen. - Wir haben ja durchaus  
> mehrere Graphen in OSM, zum Beispiel Stromleitungsnetze oder  
> Pipeline-Netze oder die Eisenbahnlinien. Aber die sind alle mit Ways  
> umgesetzt und nicht mit irgendwelchen speziellen numerischen Pointern.

Die einzelnen Nodes sind bei TMC nicht so selbständig, wie das bei
diesen anderen Netzen der Fall ist. Bei TMC liegt die "Intelligenz"
darin, daß mit einem Knoten und einer Richtung indirekt gleich mal
noch der Straßenabschnitt, die Straße, das Bundeland etc. mitgegeben
ist. Aus der Richtung folgt damit (insbesondere bei Autobahnen und
größeren Bundesstraßen) auch die Fahrbahn.

TMC kannt keine Fahrbahn in dem Sinne, sondern nur "A2 in
Positiv-Richtung" und "A2 in Negativ-Richtung". Irgendso auf der A2
(welcher der beiden OSM-Spuren jetzt eigentlich?) also ein tag
"tmc_lcl_code=12345" zu setzen bringt also nichts, weil das entweder
auf der Gegenspur fehlen würde oder ihm die Richtung fehlt... Wenn man
die zusätzlichen Tags nicht aufbringt, ist die Auswertung noch
schlechter machbar, als das jetzt schon per TMC-Liste (von der BASt)
zu machen ist.)

> Also, in mir festigt sich die Ansicht: So, wie es ist, ist es nicht nur  
> nervig fuer die Mapper, sondern auch fuer die TMC-Anwender unnoetig  
> kompliziert; haette man die TMC-Datenbank extern, koennte man damit  
> sogar besser arbeiten.

Klares "nein". Die übrigen Nutzer merken nicht viel von den TMC-Tags.
Im schlimmsten Fall gehen sie verloren. (Daß wer mutwillig TMC-Tags
vertauscht, weil es geht, wär' ja eher absurd...)

Einfache Mappings sind mit TMC so nicht zu machen.

> Wie gesagt, bis zu einem gewissen Grad wuerde ich da auch jedem  
> zugestehen, sein eigenes Ding irgnedwo in einer Nische bei OSM zu  
> machen. Eigener Prefix und gut is. Aber hier haben wir es mit einem  
> ziemlichen Kraken zu tun, der noch dazu einen taeglich laufenden  
> Korrektur-Bot braucht, und da hoert fuer mich irgendwann der Spass auf.

Der Bot wiederum sollte, nachdem die Daten einmal da sind (und solange
die BASt keine neue Listen-Version raushaut) recht unnötig sein.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
 Signature of:                    Arroganz verkürzt fruchtlose Gespräche.
 the second  :                                   -- Jan-Benedict Glaw
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 197 bytes
Beschreibung: Digital signature
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20110202/873dbe17/attachment.sig>