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

[Jan-Benedict Glaw]

On Wed, 2011-02-02 17:02:37 +0100, Bernd Wurst <bernd at bwurst.org> wrote:
> Am Mittwoch 02 Februar 2011, 16:35:38 schrieb Jan-Benedict Glaw:
> > UKW gibts für lau. Bzw. gegen GEZ-Gebühr. Wifi und UMTS gibts nur
> > gegen Extra-Geld, die Technik ist (denk' auch an die Navis) teurer und
> > komplizierter.  Maximal kommen die Daten noch in DAB (bzw. DAB+) mit
> > rein, aber ich geh' davon aus, daß es TMC noch sehr, sehr lange Zeit
> > geben wird.
> 
> Ich teile diese Meinung zu UKW, aber schau dir die Praxis an. Youtube und Co 
> sind so ziemlich das schlimmste was man dem Internet antun konnte und trotzdem 
> ist es gemacht worden. Und auch die Öffentlich-rechtlichen Anstalten mischen 

Warum?  Auf YouTube sieht man genau das, was man sehen möchte, genau
dann, wann man es sehen möchte. Eine typische Unicast-Anwendung.

TMC, mit UKW als Broadcast-Träger, ist da doch perfekt aufgehoben.
Durch die Reichweitenbegrenzung hat man auch nur die "lokalen" Daten,
also z.B. die von ~ einem Bundesland oder von ganz Deutschland. Ist
doch genau, was man im Navi braucht. (Und teilweise wird da ja sogar
mit zwei tunern gespielt, sodaß auch noch ein zweiter Sender nach
TMC-Infos belauscht werden kann.)

> kräftig mit indem sie eine Infrastruktur betreiben die das Fernsehschauen via 
> IP-Verbindung (und eben nicht Multicast!) ermöglicht. Es gibt heute TV-
> Receiver ohne jeglichen Tuner (siehe Telekom) und ähnlich wildes Zeug.
> 
> Und UMTS-Verbindungen werden in den allerwenigsten Fällen individuell 
> abgerechnet, da setzt sich die Trafficpauschale doch sehr durch. Und in einem 
> MB Traffic bekommt man auch viele aufgeblähte Infos unter.

TV & Co. sind da IMHO bisher kein gutes Beispiel, weil die
Content-Mafia^WVertreiber derzeit noch zu sehr damit beschäftigt sind,
möglichst für jeden einzelnen User die Hand aufzuhalten. Daher auch
so wenig Multicast (wobei das durchaus eingesetzt wird.) Das hat der
Regulierer nämlich durchgesetzt, aber die Industrie spricht darüber
natürlich nicht gerne.

Problematisch find' ich dann noch die, sagen wir, geringe Stabilität
der IP-Verbindungen bei hoher Geschwindigkeit. Zellwechsel,
Funklöcher. Die Probleme hat man bei UKW gleich mal garnicht--oder
zumindest nur in sehr viel größeren Abständen.

> Man muss das nicht gut finden, aber das ist die Entwicklung der Dinge. Nicht 
> dass morgen jemand den Schalter umlegt und TMC abschaltet, nein. Aber wenn wir 
> jetzt erst anfangen die Infrastruktur für TMC in den Daten zu bauen, ist es 
> dann noch von Bedeutung wenn es benutzbar wird?

Ich bin gespannt!

> > > Übertragungen auch nötig sind oder ob die das auf die für mich
> > > naheliegendere Weise machen: "Von Koordinate [X] bis Koordinate [Y] auf
> > > Straße [Z]" mit ganz "normalen" GPS-Koordinaten und einem Straßennamen
> > > ("A 1") den das Navi auf seine Daten projeziert.
> > Das paßt nicht in die behördlichen Vorgänge ;-)
> 
> TMCpro hat mit behördlichen Vorgängen ja nichts zu tun, das ist ja 
> privatwirtschaftlich organisiert.
> 
> Auch diese Entwicklung muss man nicht gut finden, aber wenn Behörden banale 
> Dinge zu umständlich machen gibt es halt Firmen die das ganze für Geld 
> einfacher anbieten. Daher erneut die Frage: Nutzt TMCpro ebenfalls diese 
> Technik? Gerüchteweise (habe kein TMCpro-Gerät) soll das ja detailliertere 
> Infos bieten.

Zu TMCpro hab' ich keine Infos. Für TMC und (allgemeiner)
Digitaldaten-Übertragung im Radio gibts ja dicke Specs, aber zur
Pro-Variante hab' ich noch nichts gelesen.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
Signature of:                     Eine Freie Meinung in einem Freien Kopf
the second  :                   für einen Freien Staat voll Freier Bürger.
-------------- 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/e9f46872/attachment.sig>