subject:"\[Talk\-de\] Koennen wir die TMC\-Daten rauswerfen\?"


Hallo,

André Reichelt wrote:

ich sehe das Problem eher darin begründet, dass unsere Editoren nicht
besonders gut für den Einsatz mehrerer Tags optimiert sind. Man müsste
bei diesen Namensraumkonstruktionen mit dem Doppelpunkt dazu übergehen,
mehrere Tags gleichen Namensraumes in der Software zusammenzuziehen und
aufklappbar zu machen.

Wenn es zu viele Tags werden kann es doch nicht ernsthaft die Lösung
sein zu sagen, wir erlauben diese nicht mehr oder nur noch unter
bestimmten Bedingungen. Das ist doch Käse!


Diese Loesung geht, im konkreten Fall TMC, am Problem vorbei.

Das Problem ist doch, dass da - egal wie viel ein Editor was zuklappt - 
irgendwelche semantisch schwer verstaendlichen Zusatzinformationen an 
einem Node haengen. Wieso hat diese Ampel hier Zusatztags, und die 
Ampel an der naechsten Kreuzung hat keine? Was tue ich, wenn diese Ampel 
hier abgebaut wird?


Wir sind eines der am vollstaendigsten erfassten Laender bei OSM. Bei 
uns beginnt jetzt schon die Entwicklung weg vom Neuerfassen hin zum 
Erhalten, Pflegen, Aktualisieren. Einige der Pioniere, die noch auf 
weisser Flaeche mit GPS unterwegs waren, orientieren sich um; andere 
suchen sich in fernen Gefilden andere Betaetigungsfelder. Wir sind 
darauf angewiesen, dass staendig Newbies zu OSM stossen und unsere 
Daten aktuell halten. Unsere Daten duerfen sich nicht in eine staendig 
komplexere Richtung entwickeln, so dass sie nur noch von Experten 
gepflegt werden koennen.



Als weiteren Schritt sollten wir uns überlegen eine Möglichkeit zu
schaffen, bestimmte Tags komplett ausblenden zu lassen. 


[...]


Sollte ein Objekt mit versteckten Tags verändert oder gelöscht werden
müsste der User über eine Warnmeldung darauf hingewiesen werden. Das ist
aber, denke ich, obligatorisch.


Das ist ja dann der absolute UI-GAU. Lieber User, mit diesem Objekt 
hier ist irgendwas, was Du nicht verstehst, und das, was Du hier gerade 
machen willst, kann Folgen haben, die Du nicht verstehst und die wir 
hier leider auch nicht erklaeren kann... - das ist *genau* der Kern des 
Problems.


Ich will, dass jeder Newbie herkommen und eine Strassengeometrie 
verfeinern kann, eine Ampel loeschen oder eine Umgehungsstrasse 
eintragen, ohne dass er erst die Wikiseite zu TMC lesen muss (und 10 
andere Wikiseiten zu anderen Spezialnamensraeumen auch).


Deswegen ist mein Mantra: Jeder kann seinen Spezialkram mit OSM aufbauen 
(und fuer mich ist TMC Spezialkram), aber das darf nicht zu Lasten der 
Komplexitaet gehen. Man darf dadurch, dass man OSM fuer 
Spezialanwendungen nutzt, nicht Mauern aufbauen, die es Neulingen 
erschweren, an OSM teilzunehmen.


Und Tags, die entweder ganz offen (ueber eine Editorwarnung) oder 
unterschwellig (durch ihre Komplexitaet gepaart mit unlesbaren 
Wikiseiten) suggerieren: Finger weg! (oder sollte ich sagen: 
pfoten_weg?), die sind meines Erachtens fuer OSM schaedlich.


Es mag sein, dass es manchmal einfach nicht anders geht, und dann kann 
man mal einen Kompromiss machen, aber es sollte wenigstens klar sein, 
*dass* solche Tags schaedlich sind und dass man, wenn es irgend geht, an 
ihrer Vermeidung arbeiten sollte statt an ihrer Vermehrung.



Im Übrigen sollten im selben Zuge auch direkt ein System implementieren,
mit denen man als historic getaggte Objekte direkt ausblenden kann,
sodass diese den Mapper nicht mehr stören. Im nächsten Schritt muss es
dann auch möglich sein ganze Taggruppen auszublenden, da es im
innerstädtischen Bereich mitunter schon recht unübersichtlich wird.


JOSM kann bereits ganze Objekte anhand ihrer Tags ausblenden, jedoch 
nicht einzelne Tags eines Objekts.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-05 Diskussionsfäden M∡rtin Koppenhoefer

Am 5. Februar 2011 19:32 schrieb Frederik Ramm frede...@remote.org:
 Diese Loesung geht, im konkreten Fall TMC, am Problem vorbei.


dem stimme ich natürlich auch zu


 Unsere
 Daten duerfen sich nicht in eine staendig komplexere Richtung entwickeln, so
 dass sie nur noch von Experten gepflegt werden koennen
 Ich will, dass jeder Newbie herkommen und eine Strassengeometrie verfeinern
 kann, eine Ampel loeschen oder eine Umgehungsstrasse eintragen, ohne dass er
 erst die Wikiseite zu TMC lesen muss (und 10 andere Wikiseiten zu anderen
 Spezialnamensraeumen auch).


m.E. ist es leider unausweichlich. dass das Taggingschema immer
komplexer wird. TMC scheint im Vergleich zum ÖPNV noch simpel (mal
davon abgesehen, dass es da auch noch verschiedene konkurrierende
Möglichkeiten gibt, die Daten abzubilden).

Durch das Bedürfnis der Mapper, immer mehr verschiedene Dinge
einzutragen, und immer (m.E. auch sinnvolle) mehr Differenzierungen
festzuhalten, gibt es halt auch immer mehr unterschiedliche Tags. Wenn
unser Ziel ist, die Welt abzubilden, dann liegt es auf der Hand, dass
das nicht so einfach sein kann wie eine Sammlung untereinander
weitgehend unabhängiger Artikel (WP).

Im Prinzip sind wir daher jetzt schon an einem Punkt angekommen, wo
einfach mal Loseditieren nicht geht, ohne sich ein bisschen mit der
Materie zu beschäftigen (und ich behaupte mal ketzerisch, das war
schon immer so, die Tools sind ja auch deutlich benutzerfreundlicher
geworden).


 Deswegen ist mein Mantra: Jeder kann seinen Spezialkram mit OSM aufbauen
 (und fuer mich ist TMC Spezialkram), aber das darf nicht zu Lasten der
 Komplexitaet gehen. Man darf dadurch, dass man OSM fuer Spezialanwendungen
 nutzt, nicht Mauern aufbauen, die es Neulingen erschweren, an OSM
 teilzunehmen.


die Komplexität entsteht ja alleine schon durch die reine Masse an
unterschiedlichen Dingen, die alle irgendwie miteinander in
Zusammenhang stehen.


 Und Tags, die entweder ganz offen (ueber eine Editorwarnung) oder
 unterschwellig (durch ihre Komplexitaet gepaart mit unlesbaren Wikiseiten)
 suggerieren: Finger weg! (oder sollte ich sagen: pfoten_weg?), die sind
 meines Erachtens fuer OSM schaedlich.


gut, der Hinweis auf das Wiki. Je besser unsere Dokumentation ist, um
so eher bleibt das System auch beherrschbar und zugänglich.

Das alles mehr oder weniger allgemein, TMC ist sicher ein Beispiel
dafür, dass man es auch ein bisschen weniger programmiereraffin
hätte gestalten können.

M.E. wird die Entwicklung dahin gehen, dass es einerseits Editoren wie
JOSM gibt, die einem alle Möglichkeiten bieten, an den Daten
herumzumanipulieren, die aber auch Einarbeitung sowohl in die Software
als auch in das Taggingsystem erfordern, und andere Editoren, die
einen z.B. keine Ways kombinieren lassen, wohl aber ne einfache
Möglichkeit bieten, mal einen Straßennamen einzutragen oder eine
Einbahnstraße umzudrehen, bzw. die für einen speziellen Nutzerkreis
(s.z.B. Openseamap) anhand deren Bedürfnisse entwickelt wurden.

Gruß Martin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-05 Diskussionsfäden André Reichelt

Am Samstag, den 05.02.2011, 19:32 +0100 schrieb Frederik Ramm:
 Das ist ja dann der absolute UI-GAU. Lieber User, mit diesem Objekt 
 hier ist irgendwas, was Du nicht verstehst, und das, was Du hier gerade 
 machen willst, kann Folgen haben, die Du nicht verstehst und die wir 
 hier leider auch nicht erklaeren kann... - das ist *genau* der Kern des 
 Problems.

Das wird sich aber auch nicht durch eine ID in eine externe Datenbank
lösen lassen, da auch hier der User zunächst überprüfen muss, was das
Tag bedeutet und wie er hier vorgehen muss. Also bringt uns auch die
Geforderte ID in eine externe Datenbank keinen Schritt weiter.

Außerdem haben wir bereits festgestellt, dass man von einer anderen
Datenbank nicht in die OSM-Datenbank linken kann, da hier die Gefahr
groß ist, dass irgendwer ein paar Nodes/Wege löscht und dadurch die
externe Datenbank ständig korrigiert werden müsste.

Wir stehen hier meiner Meinung nach vor einem schwerwiegenden Problem,
für das wir gegenwärtig keine Lösung parat haben. Nun einfach ohne
Rücksicht auf Verluste zu fordern all diese Tags wieder zu löschen wäre
falsch und destruktiv.

 Es mag sein, dass es manchmal einfach nicht anders geht, und dann kann 
 man mal einen Kompromiss machen, aber es sollte wenigstens klar sein, 
 *dass* solche Tags schaedlich sind und dass man, wenn es irgend geht, an 
 ihrer Vermeidung arbeiten sollte statt an ihrer Vermehrung.

Dass solche Tags »schädlich« sind konnte bisher noch niemand mit Fakten
belegen. Die einzige Aussage die hier von Dir und von Anderen glaubhaft
vermittelt werden konnte ist, dass die gegenwärtige Lösung suboptimal
ist.

Wir stehen nun also an dem Punkt, an dem wir dazu angehalten sind eine
*bessere* Lösung zu finden. Dieses Ziel werden wir nicht erreichen,
indem wir hier in Wikipedia-Manier irgendwelchen relevanzkriterien-
ähnlichen Mist veranstalten.

Ich möchte das Problem noch einmal allgemein gefasst darstellen:
Wir haben eine externe Datenquelle, die mit der OSM-Datenbank verbunden
werden soll. Eine direkte Verbindung mit der OSM-ID des Objektes nicht
nicht möglich, da es in der OSM-Datenbank keinen »Fertig«-Zustand gibt,
der ein Löschen oder Verändern des Objektes dauerhaft ausschließt. Daher
muss ein Weg gefunden werden unabhängig von zukünftigen Änderungen an
der OSM-Datenbasis zuverlässig eine Verknüpfung von OSM-Daten mit einer
externen Datenquelle zu gewährleisten.

Ich behaupte, dass wir hier von einem komplexeren Problem sprechen, dass
sich durch blinden Aktionismus nicht lösen lässt. Bevor jedoch keine
zuverlässige und stabile, weniger »schädliche« Lösung gefunden ist kommt
eine Löschung der TMC-Daten nicht in Frage, da dadurch die
Datennutzbarkeit in erheblichem Umfang eingeschränkt wird.

Gruß
André



*Anhang:* Meine Idee für einen Lösungsansatz

Ein Lösungsansatz könnte es sein, nicht nur auf das Objekt in der OSM-DB
selbst zu verweisen sondern zusätzlich auf den Revisionsstand. Auch hier
könnte es allerdings zu konflikten mit zukünftigen Änderungen kommen.
Von unserer Seite aus müsste bei diesem Ansatz also ein System
geschaffen werden dass zwar die Datenbasis *möglichst* aktuell zur
Verfügung stellt. Wird jedoch in der Dump-Abfrage ein Objekt mit
Revision abgefragt muss die Blackbox in der Lage sein alle involvierten
zukünftigen Änderungssätze zu ermitteln, dort eventuelle Konflikte
feststellen und die betroffenen Daten vor der Ausgabe auf einen
konsistenten Revisionsstand zurücksetzen.

Als Zwischen-/Notlösung könnte man sich auch vorstellen, dass einfach
nur eine Liste von Objekten und deren Revisionsstand an die Blackbox
übergeben wird. Diese gibt dann für jedes Objekt zurück, ob es
mittlerweile einen neuen Revisionsstand hat. Diese Lösung hat allerdings
den Nachteil, dass ich als Betreiber der externen Datenquelle, die in
OSM linkt zunächst meinen Datensatz überprüfen muss und im Konfliktfall
meine Verknüpfungen zu korrigieren habe.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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


Hallo,

André Reichelt wrote:

Am Samstag, den 05.02.2011, 19:32 +0100 schrieb Frederik Ramm:
Das ist ja dann der absolute UI-GAU. Lieber User, mit diesem Objekt 
hier ist irgendwas, was Du nicht verstehst, und das, was Du hier gerade 
machen willst, kann Folgen haben, die Du nicht verstehst und die wir 
hier leider auch nicht erklaeren kann... - das ist *genau* der Kern des 
Problems.


Das wird sich aber auch nicht durch eine ID in eine externe Datenbank
lösen lassen, da auch hier der User zunächst überprüfen muss, was das
Tag bedeutet und wie er hier vorgehen muss. Also bringt uns auch die
Geforderte ID in eine externe Datenbank keinen Schritt weiter.


 Außerdem haben wir bereits festgestellt, dass man von einer anderen
 Datenbank nicht in die OSM-Datenbank linken kann, da hier die Gefahr
 groß ist, dass irgendwer ein paar Nodes/Wege löscht und dadurch die
 externe Datenbank ständig korrigiert werden müsste.

Wir haben vielleicht festgestellt, dass es nicht trivial ist; aber 
nicht, dass man es nicht kann. Es braucht halt ein bisschen 
Gehirnschmalz, und mir es es lieber, die externen Datenbanken werden 
kompliziert und OSM bleibt einfach, als umgekehrt. Denn wir haben 
hunderte von externen Datenbanken und nur ein OSM ;)


Ideal waere, wenn es gelaenge, komplett von aussen nach OSM hinein zu 
linken. Das kommt ja immer wieder auf den Tisch, und die Alternativen 
sind immer die gleichen - entweder man macht es sich leicht und traegt 
die externe ID bei OSM ein, was aber auf Dauer ein Problem werden kann 
und anfaellig gegen Loeschungen usw. ist, oder man findet eine Art 
symbolischer Links - so dass in der externen Datenbank steht: ein 
Objekt vom Typ Way oder Node mit den Tags amenity=restaurant und Name=La 
Cucina im Umkreis von 500m um diesen Punkt oder so etwas. So eine 
Verknuepfung mit etwas Spiel ist immun gegen viele Probleme und 
verkompliziert OSM gar nicht - sie ist aber technisch anspruchsvoll, 
weil man eine XAPI-artige Link-Finde-Maschine braucht. In irgendeiner 
Weise wird es sowas aber geben muessen, und vielleicht koennte man das 
fuer TMC dann auch verwenden.


(Deine Idee mit dem Linken auf Revisionsstaende hat auch Charme, aber 
auch wieder ihre eigenen Probleme.)



Wir stehen hier meiner Meinung nach vor einem schwerwiegenden Problem,
für das wir gegenwärtig keine Lösung parat haben. Nun einfach ohne
Rücksicht auf Verluste zu fordern all diese Tags wieder zu löschen wäre
falsch und destruktiv.


Ja, nun ist ja gut. Ich habe ja auch nicht gefordert, ohne Ruecksicht 
auf Verluste alle diese Tags wieder zu loeschen. Mir ist erstmal 
allgemein wichtig, grundaetzlich das Bewusstsein dafuer zu schaerfen, 
dass solche Tags weder gut noch unumgaenglich sind, sondern maximal eine 
Notloesung, weil wir gegenwaertig nichts besseres haben.


In bezug auf TMC wuensche ich mir, dass wir diese Daten mittelfristig 
weitgehend in ein OSM-externes System migrieren koennen, dass keinerlei 
regelmaessige automatische Veraenderungen von OSM fuer mehr 
TMC-Konformitaet stattfinden, und dass Benutzer, die sich nicht fuer TMC 
interessieren, nicht im Dunkeln tappen muessen. Wenn wir uns einig sind, 
dass es so, wie es jetzt ist, ganz bestimmt nicht richtungsweisend 
ist, dann ist das schonmal ein guter Anfang.



Dass solche Tags »schädlich« sind konnte bisher noch niemand mit Fakten
belegen. Die einzige Aussage die hier von Dir und von Anderen glaubhaft
vermittelt werden konnte ist, dass die gegenwärtige Lösung suboptimal
ist.


Ein einziger User, der sich wegen TMC-Tags nicht traut, ein Objekt zu 
bearbeiten - und da gab es mindestens einen hier im Thread - reicht in 
meinen Augen schon zum Schadensbeweis. Denk dran, dass sich hier in 
der Liste nur die Top 1% herumtreiben, und frage Dich, wie viele 
andere erschrocken ihre Finger von einer Verbesserung gelassen haben.



Wir haben eine externe Datenquelle, die mit der OSM-Datenbank verbunden
werden soll.


Jup. Und nicht: Eine externe Datenbank, die in OSM abgebildet werden 
soll, was, wie mir scheint, derzeit der Fall ist.



Eine direkte Verbindung mit der OSM-ID des Objektes nicht
nicht möglich, da es in der OSM-Datenbank keinen »Fertig«-Zustand gibt,
der ein Löschen oder Verändern des Objektes dauerhaft ausschließt. 


Jup.


Daher
muss ein Weg gefunden werden unabhängig von zukünftigen Änderungen an
der OSM-Datenbasis zuverlässig eine Verknüpfung von OSM-Daten mit einer
externen Datenquelle zu gewährleisten.


Zuverlaessig und gewaehrleisten wird es nie geben. Was wir anstreben 
wuerden, waere allenfalls ein moeglichst geringes Risiko der 
unabsichtlichen Zerstoerung, sowie eine moeglichst einfache 
(automatisierte) Erkennung von solchen Problemen, so dass diese dann von 
Menschen repariert werden koennen.



Ich behaupte, dass wir hier von einem komplexeren Problem sprechen, dass
sich durch blinden Aktionismus nicht lösen lässt. Bevor jedoch keine
zuverlässige und stabile


Zu zuverlaessig und stabil s.o.


weniger »schädliche« Lösung gefunden

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

2011-02-05 Diskussionsfäden Ulf Lamping


Am 05.02.2011 22:44, schrieb Frederik Ramm:

In bezug auf TMC wuensche ich mir, dass wir diese Daten mittelfristig
weitgehend in ein OSM-externes System migrieren koennen, dass keinerlei
regelmaessige automatische Veraenderungen von OSM fuer mehr
TMC-Konformitaet stattfinden, und dass Benutzer, die sich nicht fuer TMC
interessieren, nicht im Dunkeln tappen muessen.


Was macht TMC weniger wichtig für OSM als ÖPNV, Wanderwege, ...?

Es ist dir vielleicht nicht bewußt, aber das was du damit letztlich 
forderst ist nichts anderes als sowas wie die Relevanzkriterien der 
deutschen Wikipedia. Das gehört nicht hier her, das muß hier weg.


Wenn du das Thema weiter denkst: Wieso müssen die TMC Daten raus in eine 
eigene Datenbank, aber die ÖPNV Daten dürfen drin bleiben? Mit der 
gleichen Argumentation wie du oben: Diese für mich überflüssigen und 
kryptischen ÖPNV Relationen stören mich die ganze Zeit beim Editieren - 
also raus damit! Und Wanderwege, kann doch eigentlich auch woanders hin, 
sind ja keine Geodaten, ...


Was darf bleiben, was muß raus? Was sind die Kriterien, an denen du das 
bemißt?


 Wenn wir uns einig sind,
 dass es so, wie es jetzt ist, ganz bestimmt nicht richtungsweisend
 ist, dann ist das schonmal ein guter Anfang.

Das wir ein allgemeines Problem mit der wachsenden Komplexität unserer 
Daten(strukturen) haben, ist ein offenes Geheimnis.


Der Ansatz in externe DB auslagern hört sich auf den ersten Blick 
elegant an, hat aber schon bei der Wikipedia viel böses Blut erzeugt.


Wir sollten versuchen bessere Lösungen zu finden als solche die schon 
anderswo mehr schlecht als recht funktioniert haben ...


Gruß, ULFL

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-05 Diskussionsfäden Garry


Am 05.02.2011 22:44, schrieb Frederik Ramm:


Wir haben vielleicht festgestellt, dass es nicht trivial ist; aber 
nicht, dass man es nicht kann. Es braucht halt ein bisschen 
Gehirnschmalz, und mir es es lieber, die externen Datenbanken werden 
kompliziert und OSM bleibt einfach, als umgekehrt. Denn wir haben 
hunderte von externen Datenbanken und nur ein OSM ;)
TMC benötigt Fixpunkte die auf einer Strasse liegen. Benötigt man einen 
riesen Aufwand um diese Fixpunkte mit externen Lösungen zu finden ist 
die ganze Sache Wertlos.


(Deine Idee mit dem Linken auf Revisionsstaende hat auch Charme, aber 
auch wieder ihre eigenen Probleme.)



Im Gegesatz zu OSM gibt es diese bei TMC...


In bezug auf TMC wuensche ich mir, dass wir diese Daten mittelfristig 
weitgehend in ein OSM-externes System migrieren koennen, dass 
keinerlei regelmaessige automatische Veraenderungen von OSM fuer mehr 
TMC-Konformitaet stattfinden, und dass Benutzer, die sich nicht fuer 
TMC interessieren, nicht im Dunkeln tappen muessen. Wenn wir uns einig 
sind, dass es so, wie es jetzt ist, ganz bestimmt nicht 
richtungsweisend ist, dann ist das schonmal ein guter Anfang.
TMC-Daten sind relativ konstant und springen nicht wild umher! 
Autoradios bzw. Navis(Festeinbauten) werden relativ selten upgedated so 
dass sie schnell

ändernde TMC-Daten wertlos machen würde.



Dass solche Tags »schädlich« sind konnte bisher noch niemand mit Fakten
belegen. Die einzige Aussage die hier von Dir und von Anderen glaubhaft
vermittelt werden konnte ist, dass die gegenwärtige Lösung suboptimal
ist.


Ein einziger User, der sich wegen TMC-Tags nicht traut, ein Objekt zu 
bearbeiten - und da gab es mindestens einen hier im Thread - reicht in 
meinen Augen schon zum Schadensbeweis. Denk dran, dass sich hier in 
der Liste nur die Top 1% herumtreiben, und frage Dich, wie viele 
andere erschrocken ihre Finger von einer Verbesserung gelassen haben.

Das ist absoluter Blödsinn!
Mit der Begründung müsstest Du als aller erstes die Relationen wieder 
abschaffen!
Sobald Du versuchst ein grob eingezeichnetes Stück Wald in zwei feiner 
aufgegliederte zu teilen kommt eine dicke Warnmeldung in JOSM wenn eine
Relation im Spiel ist. Und Wälder sind mit Sicherheit nicht das 
wichtigste was OSM zu bieten hat - heisst ja auch OpenStreetMap und 
nicht OpenForestMap...
Soll heissen es gibt ..zig Dingen die auch einem schon etwas geübteren 
User nicht geläufig sind und ihn davon abhalten können bestehende Daten 
aus seiner Sicht zu verbessern.



Wir haben eine externe Datenquelle, die mit der OSM-Datenbank verbunden
werden soll.


Jup. Und nicht: Eine externe Datenbank, die in OSM abgebildet werden 
soll, was, wie mir scheint, derzeit der Fall ist.
Es ist eine externe Datenbank die sich auf Bezugpunkte auf Strassen 
bezieht. Der Bezug auf feste Koordinaten ist wertlos weil es 
diesbezüglich Ungenauigkeiten
sowohl in der externen Datenbank als auch bei OSM gibt. Der Stau findet 
auf der Strasse statt und nicht auf der daneben liegenden Wiese.


Zuverlaessig und gewaehrleisten wird es nie geben. Was wir 
anstreben wuerden, waere allenfalls ein moeglichst geringes Risiko der 
unabsichtlichen Zerstoerung, sowie eine moeglichst einfache 
(automatisierte) Erkennung von solchen Problemen, so dass diese dann 
von Menschen repariert werden koennen.
Das Ziel sollte sein möglichst wenig reparieren zu müssen und nicht 
möglichst viele Reparaturmöglichkeiten zu schaffen!



weniger »schädliche« Lösung gefunden ist kommt
eine Löschung der TMC-Daten nicht in Frage, da dadurch die
Datennutzbarkeit in erheblichem Umfang eingeschränkt wird.


Ehrlich gesagt scheint mir diese Datennutzbarkeit derzeit noch ein 
ziemliches Phantom zu sein. Das einzige, was ich gehoert habe, ist: 
Mein Nuevi kann mir einen Punkt anzeigen, an dem die Stoerung ist. 
Das aber kann ich auch, indem ich 100% extern jedem TMC-Node ein 
Koordinatenpaar zuweise. Ich verstehe, dass das gewuenschte Ziel ist, 
dass Router automatisch Wegsegmente highlighten und ausblenden 
koennen, aber gibt es irgendeine Software, und sei es auch nur proof 
of concept, die das macht? Oder reden hier alle nur von einer 
theoretischen, zukuenftigen, erhofften Nutzbarkeit?
Hast nicht gerade Du immer gross auf Deine Fahnen geschrieben dass wir 
nicht für eine bestimmte Anwendung taggen sollen?
Welche Anwendung zeigt Dir den den kürzesten Weg zum nächsten 
Hundekottütenspender an, welche zur nächsten Parkbank?


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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


Hallo Ulf,

Ulf Lamping wrote:
Es ist dir vielleicht nicht bewußt, aber das was du damit letztlich 
forderst ist nichts anderes als sowas wie die Relevanzkriterien der 
deutschen Wikipedia. Das gehört nicht hier her, das muß hier weg.


Es hat schon immer bei OSM die Auffassung gegeben, dass wir in der Regel 
keine Duplikate von extern gehaltenen Datenbestaenden bei uns anlegen 
wollen. Das hat noch nie jemand ein Relevanzkriterium genannt, aber 
wenn Du moechtest, kannst Du das tun.


Es gibt Ausnahmen von dieser Regel, die aber nicht selten ziemlich 
umstritten sind. Ausnahmen kommen meistens vor, wenn


* der externe Datenbestand von seinem Hersteller nicht mehr gepflegt 
wird und daher, wenn OSM ihn nicht adoptiert, immer nutzloser wird;


* die Hoffnung besteht, dass die Arbeit in OSM durch diesen Datenbestand 
besser vorangeht (z.B. man importiert Ortsnamen aus der OpenGeoDB und 
erkennt dadurch dann leicher, wo man noch was tun muss)


* man sich vom externen Datenbestand einen so hohen Nutzen erwartet, 
dass man alle Bedenken in den Wind schlaegt ;)


Ausnahmen kommen nur aeusserst selten vor, wenn der externe Datenbestand 
*nicht* durch Mapper pflegbar ist; da gab es zum Beispiel mal eine lange 
Diskussion mit jemandem in den USA, der irgendwelche offiziellen 
Schutzgebietsgrenzen importieren wollte, die dann in OSM nicht 
editierbar sein sollten (denn sie waren ja offiziell) - das lief auch 
drauf hinaus: Wenn diese Daten so offiziell sind, dass man sie nicht 
aendern kann, dann brauchen wir sie auch nicht in OSM, denn OSM ist kein 
Sammelpott fuer coole Daten, sondern ein gigantisches Editierwerkzeug.


Wenn du das Thema weiter denkst: Wieso müssen die TMC Daten raus in eine 
eigene Datenbank, aber die ÖPNV Daten dürfen drin bleiben? 


Die OePNV-Daten sind auch ein ziemlich komplexes Biest. Ich sehe den 
Unterschied, dass es die externe OePNV-Datenbank (im abstrakten Sinne, 
also in Form irgendeiner Liste, die von irgendwem herausgegeben oder 
gewartet wird) nicht gibt; diese Datenbank wird sozusagen durch OSM 
ueberhaupt erst aufgebaut. Beim OePNV ist es so, dass ein kundiger 
Mapper sich die OSM-Daten anschaut und selbst aus eigener Kenntnis 
eintraegt: Hier faehrt der Bus Nr. 67 lang. Es gibt keine offizielle 
Datenbank vom Verkehrsverbund, die man sich holen kann und in der das 
drin stuende (und erst recht keine bundesweite Datenbank).


Aber mal angenommen, es *gaebe* eine solche Datenbank, die vom 
Bundesverband der Nahverkehrsunternehmen oder sonst wem gepflegt wuerde, 
dann waere ich der erste, der sagt: Lasst uns doch versuchen, einfach 
nur die Korrespondenz zwischen OSM und diesen Daten herzustellen, statt 
die Daten in OSM zu stopfen. Lasst uns ein Mapnik-Rendering-Backend 
schreiben, das die Verkehrsverbund-Daten anzapft und in die OePNV-Karte 
einzeichnet, statt diese und 100 andere Spartendaten alle bei uns 
pflegen zu wollen.


Vielleicht kommt auch Transiki irgendwann mal dahin, dass dort 
Liniennetze und Tarif-/Fahrplaene gespeichert werden und bei uns die 
dazugehoerigen Geodaten. Das wuerde ich begruessen.


 Mit der
gleichen Argumentation wie du oben: Diese für mich überflüssigen und 
kryptischen ÖPNV Relationen stören mich die ganze Zeit beim Editieren - 
also raus damit! 


Mich stoeren sie auch. Aber ich denke, man muss das pragmatisch sehen. 
Wir haben viele Leute, die gern daran arbeiten wuerden, diese 
OePNV-Daten zusammenzutragen, und ausser OSM gibt es derzeit kein 
geeignetes Vehikel. Ich sehe das auch als temporaer; irgendwann kann man 
die so gesammelten Daten vielleicht ausgliedern. Diese Argumentation 
trifft aber m.E. fuer TMC nicht zu. Diese Daten muessen nicht 
zusammengetragen werden, die existieren ja schon.


Und Wanderwege, kann doch eigentlich auch woanders hin, 
sind ja keine Geodaten, ...


Wie gesagt, ich sehe das pragmatisch. Grundsaetzlich ist OSM fuer 
Geodaten, und zwar im weitesten Sinne; wir erfassen von Restaurants ja 
mittlerweile auch schon, was sie kochen und ob sie rollstuhltauglich 
sind - weil alles andere nicht gescheit geht. *Gaebe* es aber eine 
deutschlandweite offizielle und garantiert richtige Restaurantdatenbank 
(zum Beispiel, weil sie von einer Behoerde rausgegeben wird, die die 
Genehmigungen zum Eroeffnen eines Restaurants erteilt), dann wuerden wir 
uns vieles sparen und einfach nur auf diese Datenbank verweisen (oder 
ein komplizierteres Link-Schema aufbauen).


Bei TMC ist es nun mal so, dass es richtiger als die offizielle 
Datenbank nicht geht. Das ist komplett extern, da ist kein Spielraum 
fuer den Mapper, irgendwas zu verbessern. Oder sehe ich das falsch?


Es gibt auch durchaus sowas wie die Lizenz zum Spielen in OSM. Man 
muss nicht alles rechtfertigen, was man macht. Aber ab einem gewissen 
Punkt muss man sich vielleicht schon mal fragen lassen, was man da 
gerade landes- oder weltweit fuer ein Schema ausrollt und ob man sich 
das auch gut ueberlegt hat, oder ob man da was konstruiert, mit dem zwar 
tausende in

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


Hallo,

Garry wrote:
TMC benötigt Fixpunkte die auf einer Strasse liegen. Benötigt man einen 
riesen Aufwand um diese Fixpunkte mit externen Lösungen zu finden ist 
die ganze Sache Wertlos.


Ich bin nicht ueberzeugt, dass es sich hier um einen Riesenaufwand 
handelt. Ich koennte mir vorstellen, dass man mit einem halbwegs 
gescheiten Vorverarbeitungsschritt problemlos das Strassennetz aus OSM 
nehmen kann plus den TMC-Graphen und das gescheit aufeinander abbilden. 
Denn wie Du richtig sagst, werden die TMC-Segmente wohl kaum auf der 
Wiese liegen oder auf dem Radweg, der neben der Bundesstrasse verlaeuft. 
Und wer auch immer die OSM-Daten fuer das routingfaehige Navi 
aufbereitet, muss diese ganzen Daten doch eh durchnudeln.


Aber das ist jetzt von mir zugegebenermassen so dahingesagt, ich habe 
das noch nicht selber ausprobiert. Vielleicht schlummern da irgendwelche 
Hunde, die ich nicht kenne. Pascal weiss das sicher besser, deswegen 
versuche ich jetzt mal, bis zu seinem Talk auf der FOSSGIS nicht mehr 
weiterzuspekulieren ;)


Ein einziger User, der sich wegen TMC-Tags nicht traut, ein Objekt zu 
bearbeiten - und da gab es mindestens einen hier im Thread - reicht in 
meinen Augen schon zum Schadensbeweis. Denk dran, dass sich hier in 
der Liste nur die Top 1% herumtreiben, und frage Dich, wie viele 
andere erschrocken ihre Finger von einer Verbesserung gelassen haben.



Das ist absoluter Blödsinn!
Mit der Begründung müsstest Du als aller erstes die Relationen wieder 
abschaffen!


Sind wir uns also darin einig, dass jeder User, der durch 
was-auch-immmer erschrocken seine Finger von etwas laesst, einen Schaden 
darstellt? Egal ob TMC:c347:tabcdefghi:next_pointer=0x3728754 oder durch 
eine Multipolygonrelation?


Soll heissen es gibt ..zig Dingen die auch einem schon etwas geübteren 
User nicht geläufig sind und ihn davon abhalten können bestehende Daten 
aus seiner Sicht zu verbessern.


Genau, und diese Dinge muessen wir kennen, verstehen, im Griff behalten, 
bekaempfen, reduzieren.


Ich hab neulich, als ich eine Gruppe Studenten in OSM einfuehren sollte, 
schon ein Dorf in Turkmenistan mappen lassen, weil ich so viel gar nicht 
an einem Vormittag erklaeren konnte, wie die wissen muessten, um in 
einer deutschen Innenstadt was zu editieren.



weniger »schädliche« Lösung gefunden ist kommt
eine Löschung der TMC-Daten nicht in Frage, da dadurch die
Datennutzbarkeit in erheblichem Umfang eingeschränkt wird.


Ehrlich gesagt scheint mir diese Datennutzbarkeit derzeit noch ein 
ziemliches Phantom zu sein. Das einzige, was ich gehoert habe, ist:


Hast nicht gerade Du immer gross auf Deine Fahnen geschrieben dass wir 
nicht für eine bestimmte Anwendung taggen sollen?


Also wenn jemand 175000 Tags in Deutschland verteilt und wenn in der 
Mailingliste behauptet wird, dass deren Entfernung die Datennutzbarkeit 
in erheblichem Umfang einschraenken wuerde, dann wird doch mal die 
Frage erlaubt sein, worin konkret diese Datennutzbarkeit besteht?


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden Garry


Am 02.02.2011 23:40, schrieb Frederik Ramm:


Vermutlich hast Du recht, dass die Pflege des 1-2-Mappings in OSM am 
einfachsten ist. Was den Speicherort der Datenbank 2 betrifft, 
glaube ich aber, dass der potentielle Anwender es einfacher haette, 
wenn diese Datenbank separat waere.
Die TMC-Daten beziehen sich jeweils auf ein konkretes Wegstück. Wie 
willst Du mit vertretbarem Aufwand sicherstellen dass die Zuordnung der 
Datenbank

2 das richtige Wegstück findet.



Habe ich die Datenbank 2 separat vorliegen, so kann ich auf jeden 
Fall korrekt und exakt bestimmen, dass es sich insgesamt um die 
Strecke TMC-Id 1234-5678-7890-2345 handelt (oder so), und selbst 
wenn ich einzelne davon nun nicht in OSM finde, weiss ich trotzdem 
grob, wo's langgeht.


Also: Wenn der Softwareschreiber/Datenaufbereiter die Datenbank 2 
als echte Datenbank hat, hat er's leichter, nicht schwerer.
Er hat eine zusätzliche Fehlerquelle die er berücksichtigen muss, denke 
nicht dass es dadurch leichter wird ein funktionierendes System aufzubauen..


Alternative wäre in OSM ein System zu schaffen dass jedem Wegstück eine 
eindeutige, gleichbleibende ID gibt und die entlang eines Weges ein
möglichst in Folge liegen. So könnte man ein OpenTMC aufbauen bei dem in 
einer externen Datenbank beliebige Statusmeldungen abgelegt werden können,

z.B. auch die Befahrbarkeit von Skipisten...

Garry

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden Frederik Ramm


Hallo,

On 02/03/11 09:20, Garry wrote:

Vermutlich hast Du recht, dass die Pflege des 1-2-Mappings in OSM am
einfachsten ist. Was den Speicherort der Datenbank 2 betrifft,
glaube ich aber, dass der potentielle Anwender es einfacher haette,
wenn diese Datenbank separat waere.



Die TMC-Daten beziehen sich jeweils auf ein konkretes Wegstück. Wie
willst Du mit vertretbarem Aufwand sicherstellen dass die Zuordnung der
Datenbank 2 das richtige Wegstück findet.


Ich glaube, wir reden aneinander vorbei. Was ich sage, ist: Die 
Information, dass auf den TMC-Knoten 1234 in positiv-Richtung der 
TMC-Knoten 8765 folgt, sollte nicht in OSM stehen; OSM sollte sich - 
wenn ueberhaupt! - darauf beschraenken, zu identifizieren, wo sich der 
Knoten 1234 befindet.


Das schafft keine zusaetzliche Fehlerquelle, sondern beseitigt eine, 
meiner Ansicht nach.


Bye
Frederik

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden Henning Scholland


Am 03.02.2011 09:26, schrieb Frederik Ramm:

Hallo,

On 02/03/11 09:20, Garry wrote:

Vermutlich hast Du recht, dass die Pflege des 1-2-Mappings in OSM am
einfachsten ist. Was den Speicherort der Datenbank 2 betrifft,
glaube ich aber, dass der potentielle Anwender es einfacher haette,
wenn diese Datenbank separat waere.



Die TMC-Daten beziehen sich jeweils auf ein konkretes Wegstück. Wie
willst Du mit vertretbarem Aufwand sicherstellen dass die Zuordnung der
Datenbank 2 das richtige Wegstück findet.


Ich glaube, wir reden aneinander vorbei. Was ich sage, ist: Die 
Information, dass auf den TMC-Knoten 1234 in positiv-Richtung der 
TMC-Knoten 8765 folgt, sollte nicht in OSM stehen; OSM sollte sich - 
wenn ueberhaupt! - darauf beschraenken, zu identifizieren, wo sich der 
Knoten 1234 befindet.


Das schafft keine zusaetzliche Fehlerquelle, sondern beseitigt eine, 
meiner Ansicht nach.
Ich glaube es wäre in OSM einfacher abzubilden und für die Router 
einfacher auszuwerten, wenn man nicht die TMC-Knoten einträgt, sondern 
die Abschnitte zwischen den TMC-Knoten eine ID gibt und diese dann an 
die entsprechenden OSM-Wege tagt.


Bsp:
Auf dem OSM-Weg verläuft nur eine Richtung:
(1234)---(5678)   --   TMC:forward=1234:5678
oder
(1234)---(5678)   --   TMC:backward=1234:5678

Auf dem OSM-Weg verlaufen beide Richtungen:
(1234)---(5678) TMC:forward=1234:5678 und TMC:backward=5678:1234
oder
(1234)---(5678) TMC:backward=1234:5678 und TMC:forward=5678:1234

Der Algorithmus bekommt als Input gesagt, zwischen 1234 und 5678 ist in 
positiver Richtung Stau.
Positive Richtung bedeutet für ihn: Suche alle Wege, die 
TMC:forward=1234:5678 und TMC:backward=1234:5678 haben und sperre diese 
in die entsprechende Wayrichtung fürs Routing.


Viele Grüße
Henning


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden André Riedel

Am 3. Februar 2011 10:05 schrieb Henning Scholland o...@aighes.de:
 Ich glaube es wäre in OSM einfacher abzubilden und für die Router einfacher
 auszuwerten, wenn man nicht die TMC-Knoten einträgt, sondern die Abschnitte
 zwischen den TMC-Knoten eine ID gibt und diese dann an die entsprechenden
 OSM-Wege tagt.

 Bsp:
 Auf dem OSM-Weg verläuft nur eine Richtung:
 (1234)---(5678)   --   TMC:forward=1234:5678
 oder
 (1234)---(5678)   --   TMC:backward=1234:5678

 Auf dem OSM-Weg verlaufen beide Richtungen:
 (1234)---(5678) TMC:forward=1234:5678 und TMC:backward=5678:1234
 oder
 (1234)---(5678) TMC:backward=1234:5678 und TMC:forward=5678:1234

 Der Algorithmus bekommt als Input gesagt, zwischen 1234 und 5678 ist in
 positiver Richtung Stau.
 Positive Richtung bedeutet für ihn: Suche alle Wege, die
 TMC:forward=1234:5678 und TMC:backward=1234:5678 haben und sperre diese in
 die entsprechende Wayrichtung fürs Routing.

Klingt gut. Jedoch müssen die Punkte trotzdem in den Daten bleiben,
denn es gibt ja noch Meldungen wie Kreuzung/Abfahrt gesperrt.

Desweiteren sind Land und Listen-Nummer noch nicht im Schlüssel oder Wert.

Ciao André

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden Frederik Ramm


Hallo,

On 02/03/11 10:05, Henning Scholland wrote:

Ich glaube es wäre in OSM einfacher abzubilden und für die Router
einfacher auszuwerten, wenn man nicht die TMC-Knoten einträgt, sondern
die Abschnitte zwischen den TMC-Knoten eine ID gibt und diese dann an
die entsprechenden OSM-Wege tagt.


Wuerde dies nicht zu einer noch groesseren Inflation von TMC-Tags 
fuehren, weil nun saemtliche Ways zwischen zwei Punkten getaggt werden 
muessten?



Bsp:
Auf dem OSM-Weg verläuft nur eine Richtung:
(1234)---(5678) -- TMC:forward=1234:5678
oder
(1234)---(5678) -- TMC:backward=1234:5678


Was waere der Unterschied zwischen TMC:forward=1234:5678 und 
TMC:backward=5678:1234?


Was waere, wenn ich ueberhaupt keine Nodes und Ways taggen wuerde, 
sondern stattdessen aussschliesslich Relationen anlegen wuerde, und zwar 
eine pro TMC-Segment, mit den Tags


tmc:from=1234
tmc:to=5678

(von mir aus noch Land und Listennummer und so, aber das scheint mir 
ziemlich uebertrieben zu sein - Land wuerde ich maximal im Grenzbereich 
verwenden, und welche praktische Relevanz die Listennummer hat, hab ich 
noch nicht verstanden)


und dann noch mit einer Reihe von Members. Dabei wird es oft reichen, 
als Member nur einen Node an jedem Ende anzugeben; man muss nicht jedes 
Wegstueck, das zwischen den beiden liegt, der Relation hinzufuegen, aber 
man kann, wenn es zur Vermeidung von Missverstaendnissen notwendig ist. 
(Wenn ich einem Router sage, er soll die Punkte Autobahnkruez 
Wiesbaden und Abfahrt Niedernhausen meiden, dann brauche ich ihm 
nicht noch zusaetzlich zu sagen, dass er die 10 Autobahn-Ways dazwischen 
auch meiden soll, das ergibt sich automatisch.)


Wenn man unbedingt will, kann man auch eventuelle Kindrelationen als 
Member einbauen und dadurch die Hierarchie nachbilden.


Aber eigentlich bin ich noch nicht ueberzeugt, dass wir die Segmente 
ueberhaut bei uns speichern sollten; vielleicht ist es besser, ueber 
Relationen abzubilden: Diese Punkte hier gemeinsam bilden das AK 
Wiesbaden und das hat die TMC-ID 1234 (so eine Relation haette auch 
anderen Nutzen, z.B. ein Renderer koennte auf einer kleinen Zoomstufe 
das ganze Autobahnkreuz durch einen Punkt symbolisieren und mit einem 
Label beschriften). Den tatsaechlichen TMC-Graphen (auf Punkt 1234 folgt 
in Positivrichtung der Punkt 6543) koennte man dann ausserhalb lagern.


Bye
Frederik

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden Pascal Neis


Hi,

Henning Scholland schrieb:

Am 03.02.2011 09:26, schrieb Frederik Ramm:

Hallo,

On 02/03/11 09:20, Garry wrote:

Vermutlich hast Du recht, dass die Pflege des 1-2-Mappings in OSM am
einfachsten ist. Was den Speicherort der Datenbank 2 betrifft,
glaube ich aber, dass der potentielle Anwender es einfacher haette,
wenn diese Datenbank separat waere.



Die TMC-Daten beziehen sich jeweils auf ein konkretes Wegstück. Wie
willst Du mit vertretbarem Aufwand sicherstellen dass die Zuordnung der
Datenbank 2 das richtige Wegstück findet.


Ich glaube, wir reden aneinander vorbei. Was ich sage, ist: Die 
Information, dass auf den TMC-Knoten 1234 in positiv-Richtung der 
TMC-Knoten 8765 folgt, sollte nicht in OSM stehen; OSM sollte sich - 
wenn ueberhaupt! - darauf beschraenken, zu identifizieren, wo sich der 
Knoten 1234 befindet.


Das schafft keine zusaetzliche Fehlerquelle, sondern beseitigt eine, 
meiner Ansicht nach.
Ich glaube es wäre in OSM einfacher abzubilden und für die Router 
einfacher auszuwerten, wenn man nicht die TMC-Knoten einträgt, sondern 
die Abschnitte zwischen den TMC-Knoten eine ID gibt und diese dann an 
die entsprechenden OSM-Wege tagt.


Bsp:
Auf dem OSM-Weg verläuft nur eine Richtung:
(1234)---(5678)   --   TMC:forward=1234:5678
oder
(1234)---(5678)   --   TMC:backward=1234:5678

Auf dem OSM-Weg verlaufen beide Richtungen:
(1234)---(5678) TMC:forward=1234:5678 und TMC:backward=5678:1234
oder
(1234)---(5678) TMC:backward=1234:5678 und TMC:forward=5678:1234

Der Algorithmus bekommt als Input gesagt, zwischen 1234 und 5678 ist in 
positiver Richtung Stau.
Positive Richtung bedeutet für ihn: Suche alle Wege, die 
TMC:forward=1234:5678 und TMC:backward=1234:5678 haben und sperre diese 
in die entsprechende Wayrichtung fürs Routing.


sowas in der Art wollte ich in meinem Vortrag auf
der #FOSSGIS auch präsentieren, oder zumindest zur
Diskussion stellen. Wenn ich mich gerade nicht ganz
täusche macht das TeleAtlas in seinen Daten auch so ...

viele gruesse
pascal

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden Pascal Neis


Hi,

Frederik Ramm schrieb:

On 02/03/11 10:05, Henning Scholland wrote:

Ich glaube es wäre in OSM einfacher abzubilden und für die Router
einfacher auszuwerten, wenn man nicht die TMC-Knoten einträgt, sondern
die Abschnitte zwischen den TMC-Knoten eine ID gibt und diese dann an
die entsprechenden OSM-Wege tagt.


Wuerde dies nicht zu einer noch groesseren Inflation von TMC-Tags 
fuehren, weil nun saemtliche Ways zwischen zwei Punkten getaggt werden 
muessten?


Dies ist/wäre ein Nachteil bei diesem Verfahren ...
Aber sehr gut um TMCs Sachen in einem Router oder auf
der Karte darzustellen.



Bsp:
Auf dem OSM-Weg verläuft nur eine Richtung:
(1234)---(5678) -- TMC:forward=1234:5678
oder
(1234)---(5678) -- TMC:backward=1234:5678


Was waere der Unterschied zwischen TMC:forward=1234:5678 und 
TMC:backward=5678:1234?


Was waere, wenn ich ueberhaupt keine Nodes und Ways taggen wuerde, 
sondern stattdessen aussschliesslich Relationen anlegen wuerde, und zwar 
eine pro TMC-Segment, mit den Tags


Man muss hier mit den Begriffen etwas aufpassen.
Ein TMC-Segment enthält bei TMC mehrere Untersegmente.
Die eigentlichen TMC-Segmente werden ja bereits in
OSM importiert, was wir aber meiner Meinung nach brauchen
ist eine Darstellung der (ich nenne es jetzt mal) Untersegmente.
Also von wo nach wo geht das Untersegment von LCL:1234 to LCL:1235.
Denn genau diese brauche ich bei der Verarbeitung von
TMC-Nachrichten. Aber dein Vorschlag diese ebenfalls mit Hilfe
von Relations abzubilden könnte vlt. besser sein, als die
TMC Codes an alles beteiligten Ways zu haengen. Stift und
Papier zum Malen wäre jetzt hilfreich ... :)

viele gruesse
pascal

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden Stefan Keller

Hallo,

Sorry meinen grundsätzlichen Einwurf... Ich kenne TMC etwas und
interessiere mich immer, wie ein externe Fachinformationssysteme (FIS)
und OSM zusammenarbeiten können und kann Frederiks Bedenken in diesem
Falle nachvollziehen.

Nun scheint ja ein Kompromiss zu entstehen, denn eine Löschung von
FIS-Daten wäre schon FIES :-

Nur tmc_id=8326765 scheint mir ev. etwas zuwenig zu sein, denn oft
möchte ein SW-Client die Infos möglichst direkt haben. Also sollte
meiner der Kompromiss nochmals auf wenige weitere Tags ausgedehnt
werden zu müssen. Man denke da z.B. an die Situation, wo OSM bei
Katastrophen real-time (wie TMC) helfen will, und Brücken/Strassen
als unpasierbar kennzeichnen. Die Tags sollten aber auf jeden Fall
menschenlesbar sein (Präfix hin oder her).

Weiter schrieb Frederik am 2. Februar 2011 23:40:
 Wir haben hier ja sozusagen drei verschiedene Datenbanken:
 1. OSM
 2. Das TMC-Netz, das wir auf OSM abbilden
 3. aktuelle Verkehrsdaten, die auf das TMC-Netz abgebildet werden

 Um 3 brauchen wir uns nicht zu kuemmern. Wer pflegt die Datenbank 2,
 also das TMC-Netz an sich - gibt es da regelmaessig neue TMC-Nodes oder
 Aenderungen inden bestehenden, oder ist das weitgehend statisch?

2. ist eine Geometrie und die ändert nicht so schnell (mindestens die
Hauptrouten/Knoten). Solche Geometrien - konkret: Way oder Relation
über Ways - kennen wir doch schon beim öffentlichen Verkehrsnetz (z.B.
S-Bahn). Da sehe ich grundsätzlich keinen Unterschied und würde das in
OSM dulden.

Fazit: FIS sollen OSM nutzen können unter bestimmten Bedingungen (u.a.
Zurückhaltung). Habe dazu eine Wiki-Seite eröffnet:
http://wiki.openstreetmap.org/wiki/DE:Nutzung_von_OSM_durch_FIS . Nur
zu mit Editieren...

= Gibt es gute Beispiele zur Nutzung von OSM durch FIS?

LG,
-S.

P.S. Die vielen Opengeodb-Tags stören mich (auch) schon lange. Sind
die nicht veraltet? Kann man ev. nicht mal die löschen?


Am 2. Februar 2011 23:40 schrieb Frederik Ramm frede...@remote.org:
 Hallo,

 On 02/02/11 23:17, Ulf Lamping wrote:

 Bist Du auch davon ueberzeugt, dass diese Daten in OSM direkt enthalten
 sein muessen, um genutzt werden zu koennen?

 Ich bin davon überzeugt, das diese Daten direkt in OSM enthalten sein
 sollten, wenn der Aufwand für einen potentiellen Anwender der Daten
 ungleich geringer ist als diese seperat zu pflegen. Das ist hier aus
 meiner Sicht der Fall.

 Wir haben hier ja sozusagen drei verschiedene Datenbanken:

 1. OSM

 2. Das TMC-Netz, das wir auf OSM abbilden

 3. aktuelle Verkehrsdaten, die auf das TMC-Netz abgebildet werden

 Um 3 brauchen wir uns nicht zu kuemmern. Wer pflegt die Datenbank 2,
 also das TMC-Netz an sich - gibt es da regelmaessig neue TMC-Nodes oder
 Aenderungen inden bestehenden, oder ist das weitgehend statisch?

 1 pflegen wir sowieso.

 Derzeit ist in OSM sowohl die Abbildung 1-2 als auch, wie mir scheint, die
 komplette Datenbank 2 erhalten (oder es ist zumindest als Zielzustand so
 geplant).

 Der potentielle Anwender ist also einer, der irgendwas programmiert, was
 Meldungen aus der Datenbank 3 annimmt und auf der Datenbank 1 anzeigt
 und sich dazu die 2 und deren Abbildung 1-2 zunutze macht.

 Vermutlich hast Du recht, dass die Pflege des 1-2-Mappings in OSM am
 einfachsten ist. Was den Speicherort der Datenbank 2 betrifft, glaube ich
 aber, dass der potentielle Anwender es einfacher haette, wenn diese
 Datenbank separat waere.

 Ohne jetzt die genauen Details zu kennen, scheint mir das Vorgehen ja so: Es
 kommt eine Meldung von TMC-Id 1234 bis TMC-Id 2345 ist Zustand ABCD. Es
 gilt nun, zunaechst herauszufinden, welche TMC-Ids alle zwischen 1234 und
 2345 liegen, dann, diese auf der Karte zu identifizieren, und dann das ganze
 einzuzeichnen bzw, herumzurouten.

 Wenn ich nun anstatt einer sauberen TMC-Datenbank 2, die einfach eine
 komplette Liste aller Knoten und Kanten des TMC-Graphen enthaelt, die
 derzeit in OSM vorliegende Schlaglicht-Sichtweise habe, bedeutet das, dass
 ich mir zuerst alle TMC-IDs aus OSM heraussuchen muss, dann anhand der
 next/previous-IDs mit einen Graphen aufbauen, der im worst case sogar
 lueckenhaft sein wird (ein einzelner fehlender Node reisst da ja schon ganze
 Verbindungen ein).

 Habe ich die Datenbank 2 separat vorliegen, so kann ich auf jeden Fall
 korrekt und exakt bestimmen, dass es sich insgesamt um die Strecke TMC-Id
 1234-5678-7890-2345 handelt (oder so), und selbst wenn ich einzelne davon
 nun nicht in OSM finde, weiss ich trotzdem grob, wo's langgeht.

 Also: Wenn der Softwareschreiber/Datenaufbereiter die Datenbank 2 als
 echte Datenbank hat, hat er's leichter, nicht schwerer.

 Oder?

 Bye
 Frederik

 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden Florian Lohoff

On Wed, Feb 02, 2011 at 03:26:28PM +0100, Jan-Benedict Glaw wrote:
 ...und in ganz NRW gibts Nebel und Eisregen. Sowas kommt nicht nur
 gesprochen vom Radio-Moderator, sondern wird eben auch via TMC
 übertragen.

NA - an der Grenze fuer NRW sind die Daten aber dran - Also der
TMC Location code ...

http://www.openstreetmap.org/browse/relation/62761

So weit ich weiss bezieht sich TMC auch immer auf administrative
Grenzen und eben die wollen wir in OSM auch haben.

Flo
-- 
Florian Lohoff f...@zz.de
 Professionell gesehen bin ich zu haben 


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden Jan-Benedict Glaw

On Thu, 2011-02-03 12:13:29 +0100, Florian Lohoff f...@zz.de wrote:
 On Wed, Feb 02, 2011 at 03:26:28PM +0100, Jan-Benedict Glaw wrote:
  ...und in ganz NRW gibts Nebel und Eisregen. Sowas kommt nicht nur
  gesprochen vom Radio-Moderator, sondern wird eben auch via TMC
  übertragen.
 
 NA - an der Grenze fuer NRW sind die Daten aber dran - Also der
 TMC Location code ...
 
 http://www.openstreetmap.org/browse/relation/62761
 
 So weit ich weiss bezieht sich TMC auch immer auf administrative
 Grenzen und eben die wollen wir in OSM auch haben.

Na, das schreib' ich doch! Via TMC wird eben nicht nur über
Verkehrsbehinderung an Straßenzügen berichtet, sondern eben auch in
Polygonen (zumeist Kreise bzw. Bundesländer.)

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  The course of history shows that as a government grows, liberty
the second  : decreases.  (Thomas Jefferson)


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden Henning Scholland


Am 03.02.2011 10:44, schrieb Frederik Ramm:

Hallo,

On 02/03/11 10:05, Henning Scholland wrote:

Bsp:
Auf dem OSM-Weg verläuft nur eine Richtung:
(1234)---(5678) -- TMC:forward=1234:5678
oder
(1234)---(5678) -- TMC:backward=1234:5678


Was waere der Unterschied zwischen TMC:forward=1234:5678 und 
TMC:backward=5678:1234?


Das forward bzw. backward sollte die Richtung des Verkehrsstromes  in 
Bezug auf die Wegrichtung in den OSM-Daten anzeigen. Bei oneway=yes 
hätte man typischerweise forward und bei oneway=-1 hätte man backward. 
Auf einem Weg mit zwei Verkehrsrichtungen wäre es nötig um nur eine 
Richtung sperren zu können.

Man könnte es auch über Relationen machen, da hast du recht.

Für das allgemeine Verständnis finde ich die Variante über Wege 
(meinetwegen auch Relationen) zu gehen einfacher
als wenn man nur irgendwelche Knoten einträgt. Man selektiert den 
betreffenden Weg und hat die Info im Sichtfeld und kann diese bearbeiten 
und muss nicht erst nodes suchen.


Die Idee ist sicher nicht perfekt, sondern wäre meiner Meinung nach 
verständlich und für Router einfach auszuwerten. Weil theoretisch gäbe 
es unendlich viele Möglichkeiten zwei Punkte mit einander zu verbinden. 
Welches nun der richtige Weg ist, wäre meiner Meinung nach mehr raterei.


Henning


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden Sven Anders

Am 02.02.2011 22:56, schrieb Frederik Ramm:
 Hallo,
 
 On 02/02/11 21:16, Sven Anders wrote:
 Mein Eindruck ist: Marcus hat sich sehr viel Mühe gemacht ein
 funktionierendes TMC Schema zu entwerfen.
 
 Marcus hat ein Schema fuer Maschinen entworfen. OSM ist aber fuer
 Menschen. Fuer Menschen ist dieses Schema nicht wartbar.

Naja die Bundesanstallt für Straßenwesen pflegt ja solche Tabellen auch.
 
 Leider gab es sehr wenig
 Kommentare dazu. Alle die ich gerne dazu um eine Meinung gefragt hätte,
 haben immer nur abgewunken, und gesagt, mit TMC beschäftige ich mich
 nicht, da habe ich keine Zeit zu etc..

 Ich meine mich zu erinnern, das ich auch dich gefragt hatte.
 
 Das ist sehr gut moeglich. Wie gesagt, normalerweise finde ich es auch
 das richtige Verhalten, Leute, die sich mit etwas auskennen, einfach mal
 machen zu lassen, und wuerde mich selber jetzt da nicht einmischen. Es
 draengt sich mir aber mehr und mehr der Verdacht auf, dass dieses
 Problem sehr suboptimal geloest wurde und an anderen Stellen Probleme
 schafft, und dass man daher jetzt einen Kurswechsel einleiten (oder die
 Notbremse ziehen) muss, bevor das Problem immer groesser wird.


Wo bitte ist das Problem an anderen Stellen?

Du vermutest Probleme, wenn jemand eine Schema ändert etc. aber bislang
sagst du nicht ich will das und das ändern und das beißt sich mit TMC.

Außer das es dir nichts gefällt, habe ich bislang nichts dazu gehört.

 Bist Du auch davon ueberzeugt, dass diese Daten in OSM direkt enthalten
 sein muessen, um genutzt werden zu koennen?

Ein Teil der Daten macht IMHO nur in OSM Sinn. Die Angaben von dem
Bundesamt sind an manchen Stellen so schlecht, das es auch nicht einfach
zu berechnen wäre. Andere Daten wie z.B. alles was der TMC Bot ergänzt
müssen nicht im OSM enthalten sein.

Aber ich fände es trotzdem gut sie drinn zu habem, weil dann niemand für
eine TMC Unterstützung beim Bundesamt nachfragen müsste. Sonst müssten
diese Daten z.B. zusammen mit Navit ausgeliefert werden.

 Damit eröffnest du aber ganz klar eine Relevanz-Diskussion.
 Ich will nur eine Datenbank für alle Geo-Informationen. Die soll
 OpenStreetMap heißen.
 
 Ich hingegen werde nicht muede, jedem zu sagen, dass alles, was
 sinnvollerweise ausserhalb von OSM gepflegt werden kann, auch ausserhalb
 von OSM gepflegt werden sollte.

Das ist ja ein toller Satz, die Frage ist ja was wird sinnvollerweise
außerhalb gefplegt?

 Wo ich aber die Grenze ziehe, ist, wenn diese kompletten externen
 Datenbanken mit in OSM abgebildet werden (wenn jetzt zusaetzlich noch
 vermerkt werden soll, in welcher Richtung der naechste Mautknoten liegt,
 wie viele Tarifkilometer der entfernt ist, undsoweiter). *Das* sind
 keine Geodaten mehr.

Natürlich kann ich Dir da nicht ganz widersprechen. Aber ein wenig:

Es wäre doch toll, wenn alle nur noch OSM benutzen, wenn z.B. die
Telekom an jeder Telefonzelle gleich erfassen würde, ob diese gerade
geht, oder defekt ist, wäre das doch ein Vorteil für alle die OSM Daten
benutzen. Natürlich gibt es Grenzen, aber bei dem was wir bislang an TMC
Daten haben ist das IMHO doch nicht das Problem.

Es wäre doch toll, wenn jemand für einen Mautkalkulator nur OSM Daten
verwenden müsste, und dazu sind halt die Tarifkilometer wichtig.

Das ist eine Relevanz-Diskussion. Wo ziehen wir die Grenze?

Deine Grenze ist Geodaten. Die TMC Daten besteht eigentlich fast nur
aus Geodaten, es geht ja auch nur um Zuordnung einer Verkehrsmeldung zu
Geodaten. Das ist der Sinn von TMC.

 Aber nicht, wenn Du irgendwann damit rechnen musst, durch die
 Verfeinerung einer Strassengeometrie ploetzlich die akribisch erstellte
 next-node-id-previous-node-id-Struktur von jemand anders kaputt zu
 machen und der sich dann bei Dir beschwert.

Ist das schon passiert? Oder ist das ein theoretisches Problem?

Entschuldigung ich reite darauf vielleicht etwas rumm, aber ich
hab immer noch den verstehe immer noch nicht, warum du bei dem Thema so
Radikal argumentierst.



Gruß
Sven

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden Wolfgang

Hallo,
Am Mittwoch 02 Februar 2011 21:16:57 schrieb Sven Anders:

sehr viel sinnvollen Text
 
+1

Gruß, Wolfgang

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden Frederik Ramm


Hallo,

On 02/03/2011 02:59 PM, Sven Anders wrote:

Du vermutest Probleme, wenn jemand eine Schema ändert etc. aber bislang
sagst du nicht ich will das und das ändern und das beißt sich mit TMC.


Ich moechte, dass OSM nach Moeglichkeit auch weiterhin ohne 
Fuehrerschein bedienbar ist. Dass man sich ein bisschen reinfuchsen 
muss in die Art, wie OSM tickt - was sind Tags, was sind Ways usw., 
laesst sich nicht vermeiden. Aber dass man sich dazu noch - je nachdem, 
was man gerade editiert - in verschiedene Fachdatenwelten 
hineinfuchsen muss, dass missfaellt mir.


Ich habe normalerweise keine unterdurchschnittliche Auffassungsgabe, 
aber fuer mich sahen und sehen diese TMC-Daten in OSM wie Kraut und 
Rueben aus, wie etwas, das ich ohne zusaetzliche Software nicht 
verstehen kann und dessen Korrektheit ich nicht pruefen kann.


Ich habe die Befurechtung, dass dadurch Mapper abgeschreckt werden - und 
mindestens einer hat mir hier ja auch recht gegeben und gesagt, er 
laesst von einer so getaggten Strasse dann lieber die Finger. Das ist 
genau das, was ich vermeiden will.


Ich mag auch einige andere Sachen nicht, es gibt z.B. eine ganze Anzahl 
von Relationen nach dem neuen OePNV-Schema, an denen gross eine Warnung 
dran steht Bitte nicht aendern, bevor Du nicht die Seite XYZ gelesen 
hast. Das ist auch schon sowas, wo ein paar Leute sich in OSM eine 
kleine Mauer bauen und sagen hier darf nur mitmachen, wer die folgenden 
Bedingungen erfuellt. Mir ist schon klar, dass das manchmal notwendig 
ist, aber es ist ein notwendiges Uebel mit der Betonung auf Uebel.


Ein bisschen muss TMC hier als Stellvertreter fuer viele andere 
aehnliche Situationen herhalten, die noch kommen werden - aber, auch das 
wurde gesagt, Marcus hatte ja angeblich mit dem TMC-Import auch vor, in 
gewisser Weise richtungsweisend zu sein. Und da muss ich sagen, in 
*diese* Richtung - naemlich mehr und mehr unverstaendliche Spezialtags, 
die dem Mapper jede Sicherheit rauben - moechte ich nur sehr ungern 
gehen. Ich habe die ernste Befuerchtung, dass das unserem Projekt die 
Basisdemokratie raubt, dieses jeder kann ganz einfach mitmachen. Das 
finde ich aber elementar wichtig.


Fuer mich kommt so ein Node mit 4 TMC-Tags an wie eine Reviermarkierung. 
Hier nichts aendern, dieser Node bedeutet was bestimmtes, und was 
genau, das wirst Du auch dann nicht verstehen, wenn Du auf die Wikiseite 
geschaut hast.


Ich halte mich fuer nicht ganz bloed, aber ein einfaches 
auf-die-Wikiseite-Schauen hat mir nicht gereicht, um zu verstehen, was 
das alles soll. Und ich bin ein alter OSM-Hase. Wie soll das also erst 
bei einem Neuling ankommen? Der schlaegt doch die Haende ueberm Kopf 
zusammen und geht lieber wieder.



Es wäre doch toll, wenn alle nur noch OSM benutzen, wenn z.B. die
Telekom an jeder Telefonzelle gleich erfassen würde, ob diese gerade
geht, oder defekt ist, wäre das doch ein Vorteil für alle die OSM Daten
benutzen.


Nein, das sehe ich ganz anders, zumindest ist unsere Technologie fuer 
sowas nicht ausgelegt - dann muessten wir viel mehr filtern koennen und 
z.B. dafuer sorgen koennen, dass ein Tileserver nicht saemtliche 
Telefonzellen-Stoerungsmeldungen gefuettert bekommt und so weiter. Ich 
sehe generell mit Besorgnis, was Leute alles in OSM stopfen moechten - 
meistens aus Faulheit oder Inkompetenz: Ich habe hier diesen Datensatz 
mit Vogelbeobachtungen, aber weil ich nicht in der Lage bin, eine Karte 
zu rendern, auf der diese Vogelbeobachtungen ueber einen OSM-Hintergrund 
eingezeichnet werden, will ich lieber die Vogelbeobachtungen zu OSM 
hochladen, dann kann ich das komfortabel in meinem Renderer einstellen.



Entschuldigung ich reite darauf vielleicht etwas rumm, aber ich
hab immer noch den verstehe immer noch nicht, warum du bei dem Thema so
Radikal argumentierst.


Vielleicht ist das jetzt einigermassen klar geworden. Die 175000 
TMC-Tags in der Datenbank allein wuerden eine solche Haltung vielleicht 
noch nicht rechtfertigen - aber die Richtung, in die das zeigt, und die 
Angst, dass mit anderen Nischeninformationen ebenso verfahren wird.


Bye
Frederik

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-03 Diskussionsfäden Stefan Keller

Ih möchte da Frederik etwas die Stange halten.

Die Erläuterungen zu TMC und das TMC Schema entsprechen z.zT. wirklich
nicht den Regeln der sinnvoller OSM-Schemas. Ich beziehe mich auf die
Schema-Diskussion oben und den wohl relevanten Artikel
http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany#Tagging_Schema

Da steht u.a. TMC:LocationCode, TMC:Direction,
TMC:NextLocationCode,TMC:PrevLocationCode. Auch konkrete
OSM-Beispieldaten helfen da nicht weiter.

Das bringt mich - nebst bitte menschenlesbaren Tag-Namen - auf einen
weiteren Punkt in
http://wiki.openstreetmap.org/wiki/DE:Nutzung_von_OSM_durch_FIS

Es besteht die Gefahr, dass das Schema aus Sicht FIG modelliert wird,
mit fachinternen Abkürzungen und Codes. Solche sollten vermieden
und/oder ausgedeutscht werden (z.B. textuelle
Aufzähltypen/Enumeration statt Zahlen). Präzise (Fach-)Begriffe sind
wichtig, sie müssen aber trotzdem mit vertretbarem Aufwand
verständlich sein.

LG, S.

Am 3. Februar 2011 16:10 schrieb Frederik Ramm frede...@remote.org:
 Hallo,

 On 02/03/2011 02:59 PM, Sven Anders wrote:

 Du vermutest Probleme, wenn jemand eine Schema ändert etc. aber bislang
 sagst du nicht ich will das und das ändern und das beißt sich mit TMC.

 Ich moechte, dass OSM nach Moeglichkeit auch weiterhin ohne Fuehrerschein
 bedienbar ist. Dass man sich ein bisschen reinfuchsen muss in die Art, wie
 OSM tickt - was sind Tags, was sind Ways usw., laesst sich nicht vermeiden.
 Aber dass man sich dazu noch - je nachdem, was man gerade editiert - in
 verschiedene Fachdatenwelten hineinfuchsen muss, dass missfaellt mir.

 Ich habe normalerweise keine unterdurchschnittliche Auffassungsgabe, aber
 fuer mich sahen und sehen diese TMC-Daten in OSM wie Kraut und Rueben aus,
 wie etwas, das ich ohne zusaetzliche Software nicht verstehen kann und
 dessen Korrektheit ich nicht pruefen kann.

 Ich habe die Befurechtung, dass dadurch Mapper abgeschreckt werden - und
 mindestens einer hat mir hier ja auch recht gegeben und gesagt, er laesst
 von einer so getaggten Strasse dann lieber die Finger. Das ist genau das,
 was ich vermeiden will.

 Ich mag auch einige andere Sachen nicht, es gibt z.B. eine ganze Anzahl von
 Relationen nach dem neuen OePNV-Schema, an denen gross eine Warnung dran
 steht Bitte nicht aendern, bevor Du nicht die Seite XYZ gelesen hast. Das
 ist auch schon sowas, wo ein paar Leute sich in OSM eine kleine Mauer bauen
 und sagen hier darf nur mitmachen, wer die folgenden Bedingungen erfuellt.
 Mir ist schon klar, dass das manchmal notwendig ist, aber es ist ein
 notwendiges Uebel mit der Betonung auf Uebel.

 Ein bisschen muss TMC hier als Stellvertreter fuer viele andere aehnliche
 Situationen herhalten, die noch kommen werden - aber, auch das wurde gesagt,
 Marcus hatte ja angeblich mit dem TMC-Import auch vor, in gewisser Weise
 richtungsweisend zu sein. Und da muss ich sagen, in *diese* Richtung -
 naemlich mehr und mehr unverstaendliche Spezialtags, die dem Mapper jede
 Sicherheit rauben - moechte ich nur sehr ungern gehen. Ich habe die ernste
 Befuerchtung, dass das unserem Projekt die Basisdemokratie raubt, dieses
 jeder kann ganz einfach mitmachen. Das finde ich aber elementar wichtig.

 Fuer mich kommt so ein Node mit 4 TMC-Tags an wie eine Reviermarkierung.
 Hier nichts aendern, dieser Node bedeutet was bestimmtes, und was genau,
 das wirst Du auch dann nicht verstehen, wenn Du auf die Wikiseite geschaut
 hast.

 Ich halte mich fuer nicht ganz bloed, aber ein einfaches
 auf-die-Wikiseite-Schauen hat mir nicht gereicht, um zu verstehen, was das
 alles soll. Und ich bin ein alter OSM-Hase. Wie soll das also erst bei einem
 Neuling ankommen? Der schlaegt doch die Haende ueberm Kopf zusammen und geht
 lieber wieder.

 Es wäre doch toll, wenn alle nur noch OSM benutzen, wenn z.B. die
 Telekom an jeder Telefonzelle gleich erfassen würde, ob diese gerade
 geht, oder defekt ist, wäre das doch ein Vorteil für alle die OSM Daten
 benutzen.

 Nein, das sehe ich ganz anders, zumindest ist unsere Technologie fuer sowas
 nicht ausgelegt - dann muessten wir viel mehr filtern koennen und z.B.
 dafuer sorgen koennen, dass ein Tileserver nicht saemtliche
 Telefonzellen-Stoerungsmeldungen gefuettert bekommt und so weiter. Ich sehe
 generell mit Besorgnis, was Leute alles in OSM stopfen moechten - meistens
 aus Faulheit oder Inkompetenz: Ich habe hier diesen Datensatz mit
 Vogelbeobachtungen, aber weil ich nicht in der Lage bin, eine Karte zu
 rendern, auf der diese Vogelbeobachtungen ueber einen OSM-Hintergrund
 eingezeichnet werden, will ich lieber die Vogelbeobachtungen zu OSM
 hochladen, dann kann ich das komfortabel in meinem Renderer einstellen.

 Entschuldigung ich reite darauf vielleicht etwas rumm, aber ich
 hab immer noch den verstehe immer noch nicht, warum du bei dem Thema so
 Radikal argumentierst.

 Vielleicht ist das jetzt einigermassen klar geworden. Die 175000 TMC-Tags in
 der Datenbank allein wuerden eine solche Haltung vielleicht noch nicht

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


Hallo,

   ich aegere mich ziemlich ueber die TMC-Daten in der OSM-Datenbank. 
Ich habe nicht die Uebersicht, wer da alles dran arbeitet und dran 
gearbeitet hat, also es besteht die Gefahr, dass ich jetzt einigen 
ehrbaren Mappern auf die Fuesse trete, aber wenn's nach mir geht, muss 
das Zeug raus.


Wir haben fast aussschliesslich menschenlesbare Daten in OSM. Schnapp 
Dir ein beliebiges Objekt, und Du kannst in aller Regel verstehen, was 
die Tags daran bedeuten.


Wir sind keine Datenbank fuer irgendwelche externen Daten, die in OSM 
nicht wartbar sind, Daten, die man im RL nicht verifizieren kann.


Vielleicht kann mir mal einer den folgenden Vorgang erklaeren.

Da ist also eine harmlose Ampel in Dortmund, Node-ID 270090818, getaggt 
als highway=traffic_signals.


Dann kommt am 31, Januar der User ruhri daher und ergaenzt das Tag:

TMC:cid_58:tabcd_1:LocationCode = 47739

Wo hat er das her? Steht das auf einem Aufkleber an der Ampel? Wenn 
nicht (wenn es aus einer externen Liste/Datenbank kommt), warum muss das 
dann in OSM stehen - kann das nicht derjenige, der die Daten auswerten 
will, dann aus genau dieser externen Liste hinzufuegen?


Fuenf Stunden spaeter kommt ein TMCbot - der uebrigens, soweit ich 
sehen kann, keiner der ueblichen Anforderungen an Bots genuegt - und 
behauptet qua Changeset-Kommentar: Korrektur von Schreib- und 
Datenintegritätsfehlern in Key/Value-Paaren des deutschen TMC Schemas. 
Was er aber tatsaechlich tut, ist, noch drei weitere Tags hinzuzufugegen:


TMC:cid_58:tabcd_1:Class = Point
TMC:cid_58:tabcd_1:LCLversion = 9.00
TMC:cid_58:tabcd_1:PrevLocationCode = 28866

Wo hat er sich die jetzt wieder hergeholt? Ist es nicht offensichtlich, 
dass es sich bei diesem Node um einen Point handelt? Was besagt diese 
LCLversion, und woher weiss der Bot, dass der User ruhri 9.00 gemeint hat?


Grundsaetzlich bin ich ja fuer Anarchie beim Tagging. Aber was wir hier 
haben, ist ganz offensichtlich irgendeine externe Spezialdatenbank, die 
unter massiven Eingriffen in OSM irgendwie auf OSM abgebildet wird, und 
zwar so, dass man nicht nur tonnenweise unverstaendlichen Code in OSM 
kippen muss (highway=traffic_signals versteht jeder, aber 
TMC:cid_58:tabcd_1 versteht nur ein Computer), sondern auch noch 
taeglich Bots laufen lassen muss, um diese Daten irgendwie in Schuss zu 
halten.


Wenn jemand ein paar tausend Fotos hat und an irgendwelche Nodes in 
Deutschland sowas dranpappt wie foto_url=..., dann sagt ja keiner was 
(das versteht vorallem auch jeder). Aber von diesen TMC-Tags gibt es 
mittlerweile 175000 in Deutschland.


Die Botschaft, die bei einem neuen Mapper da ankommt, ist doch: Oh, ein 
kryptisch getaggtes Objekt. Das fass ich mal lieber nicht an.


Mir erschliesst sich der Nutzen dieser Tags nicht - kann mir jemand mal 
eine praktische Anwendung zeigen, die diese Tags benutzt?


Mir sieht das nach einem grossangelegten Designfehler aus. Da haette man 
von vornherein ein OSM-externes Mapping TMC-OSM bauen muessen, statt 
praktisch die ganze TMC-Datenbank auf OSM aufzupropfen.


Ich will jetzt nicht die Revolution anzetteln und morgen alle TMC-Daten 
loeschen (und ich aergere mich, dass ich der Geschichte nicht viel 
frueher widersprochen habe). Aber wenn es nicht irgendwelche 
ueberwaeltigenden Gruende dafuer gibt, warum diese Daten in OSM bleiben 
muessen, dann bin ich sehr dafuer, dass diejenigen, die diese Daten 
verwenden, sich da irgendwie etwas basteln, was weniger invasiv ist. 
Wenn jetzt an einem Objekt z.B. nur eine TMC-ID dranstehen wuerde und 
alles weitere - was fuer eine Klasse, was ist die naechste ID, die 
vorherige ID, wassweissich - waere extern, koennte man damit ja schon leben.


Ich suche also sozusagen eine Exit-Strategie. Ich will herausfinden, 
was und wem diese Daten nutzen, und dann ein Konzept machen, wie wir die 
Daten aus OSM entfernen koennen, ohne diesen Nutzen zu ruinieren.


Ausser natuerlich, alle ausser mir finden diese TMC-Daten ganz knorke 
und haetten lieber noch viel mehr Tags der Art 
BPF:grq_23:tiwwhs_2:MegaCode = 281763.


Bye
Frederik

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Fred Jelk


Hallo Frederik,

ich selber finde die TMC-Daten ganz ok. - auch wenn diese kryptisch sind 
und für Menschen nicht verständlich... Unten sind noch ergänzende Worte...


Am 02.02.2011 11:10, schrieb Frederik Ramm:

Hallo,

Mir erschliesst sich der Nutzen dieser Tags nicht - kann mir jemand 
mal eine praktische Anwendung zeigen, die diese Tags benutzt?
Wenn ich mich nicht irre, werden die TMC-Daten von openrouteservice 
ausgewertet




Mir sieht das nach einem grossangelegten Designfehler aus. Da haette 
man von vornherein ein OSM-externes Mapping TMC-OSM bauen muessen, 
statt praktisch die ganze TMC-Datenbank auf OSM aufzupropfen.
Da sehe ich dann das Problem, wenn man ein Navigerät nutzen will, das 
auch die TMC-Daten auswertet.




___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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


Hallo,

On 02/02/11 11:34, Fred Jelk wrote:

Mir sieht das nach einem grossangelegten Designfehler aus. Da haette
man von vornherein ein OSM-externes Mapping TMC-OSM bauen muessen,
statt praktisch die ganze TMC-Datenbank auf OSM aufzupropfen.



Da sehe ich dann das Problem, wenn man ein Navigerät nutzen will, das
auch die TMC-Daten auswertet.


Kein Navi benutzt OSM-Daten direkt; bei allen ist ein 
Vorverarbeitungsschritt noetig. Wenn das Navi tatsaechlich die TMC-Daten 
aus OSM verwenden kann, muss das entsprechende Vorverarbeitungsprogramm 
die Daten richtig extrahieren - und koennte das genauso gut aus einer 
externen Datenbank, nehme ich jetzt mal an.


Bye
Frederik

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden André Joost


Am 02.02.11 11:10, schrieb Frederik Ramm:

Hallo,

ich aegere mich ziemlich ueber die TMC-Daten in der OSM-Datenbank. Ich
habe nicht die Uebersicht, wer da alles dran arbeitet und dran
gearbeitet hat, also es besteht die Gefahr, dass ich jetzt einigen
ehrbaren Mappern auf die Fuesse trete, aber wenn's nach mir geht, muss
das Zeug raus.



+1




Wenn jemand ein paar tausend Fotos hat und an irgendwelche Nodes in
Deutschland sowas dranpappt wie foto_url=..., dann sagt ja keiner was
(das versteht vorallem auch jeder). Aber von diesen TMC-Tags gibt es
mittlerweile 175000 in Deutschland.


Komisch, auf den Wiki-Seiten ist von 42537 Objekten in DE die Rede. Wenn 
man natürlich jede Fahrbahn und Ampel einzeln taggt...


Du kannst aber ruhri2010 gerne nach seiner Motivation fragen. Mir kommt 
er wie ein OSMkoholic vor ;-) Seine ÖPNV-Kreationen sind jedenfalls 
nicht unbedingt von Detail- oder Ortskenntnis geprägt.



Ausser natuerlich, alle ausser mir finden diese TMC-Daten ganz knorke
und haetten lieber noch viel mehr Tags der Art
BPF:grq_23:tiwwhs_2:MegaCode = 281763.


Nö, sowas muss nicht sein.

Gruß,
André Joost




___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Henning Scholland


Hallo
Solche kryptischen Dinge gibt es bei Importen recht häufig. Die 
Hausnummern in Dänemark haben zich Tags, die man in OSM nicht bräuchte. 
In Italien schwirren auch einige herum.
Ich verstehe, dass man irgendsowas braucht, um bspw. später Updates zu 
fahren. Aber meiner Meinung nach gehört so eine übersetzung in eine 
externe Datenbank und dann neben den OSM-üblichen Tags eine eindeutige 
ID in unsere Datenbank. Diese ID kann dann auch gerne kryptische Values 
und keys haben.


Daher zu deinen Ausführungen über TMC-Daten ein +1. Die TMC-Daten an 
sich scheinen ja frei zugänglich zu sein, sodass man diese Daten ähnlich 
wie auch die Höhendaten aus der externen Datenbank mit der in OSM 
hinterlegten ID ziehen kann.


Viele Grüße
Henning


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Wolfgang

Hallo,
Am Mittwoch 02 Februar 2011 11:10:25 schrieb Frederik Ramm:
 Hallo,
 
[ ]
 
 Vielleicht kann mir mal einer den folgenden Vorgang erklaeren.
 
 Da ist also eine harmlose Ampel in Dortmund, Node-ID 270090818, getaggt
 als highway=traffic_signals.
 
 Dann kommt am 31, Januar der User ruhri daher und ergaenzt das Tag:
 
 TMC:cid_58:tabcd_1:LocationCode = 47739

Ich antworte jetzt mal, obwohl ich den TMC-Kram inhaltlich auch nicht ganz 
verstehe. So weit ich weiß, gibt es aber im Wiki dazu eine Erklärung. Ganz 
grob für den ahnungslosen Mapper: Es sind Codes, die im Verkehrsfunk gesendet 
werden, um Hindernisse (Stau, Sperrung etc), die im Rundfunk so kodiert 
gesendet werden, einer geografischen Position auf einem Weg zuordnen zu 
können. Diese Geschichte funktioniert auf meinem Nüvi bereits insofern, dass 
es die Hindernisse anzeigt. Was jetzt noch fehlt, ist die Berücksichtigung in 
der Routenplanung. Da hoffe ich auf Fortschritte bei mkgmap.

 
 Wo hat er das her? Steht das auf einem Aufkleber an der Ampel? Wenn
 nicht (wenn es aus einer externen Liste/Datenbank kommt), warum muss das
 dann in OSM stehen - kann das nicht derjenige, der die Daten auswerten
 will, dann aus genau dieser externen Liste hinzufuegen?

Das kann er nur bedingt. Wenn ein ahnungsloser Mapper eine Ampel, die keine 
TMC-Codes hat, löscht und ein paar Meter neu einträgt, ist das für die 
Kartenansicht ok. Wenn aber in der externen TMC-Datenbank die ID der Ampel 
vermerkt ist, muss jedes mal manuell die TMC-ID auf die neue OSM-ID gesetzt 
werden. Das ist deutschlandweit kaum zu machen. So bleibt aber zu hoffen, dass 
der Mapper vorher wenigstens vorsichtshalber die Tags der alten Ampel auf die 
neue kopiert oder die Ampel verschiebt, statt sie zu löschen.

 
 Fuenf Stunden spaeter kommt ein TMCbot - der uebrigens, soweit ich
 sehen kann, keiner der ueblichen Anforderungen an Bots genuegt - und
 behauptet qua Changeset-Kommentar: Korrektur von Schreib- und
 Datenintegritätsfehlern in Key/Value-Paaren des deutschen TMC Schemas.
 Was er aber tatsaechlich tut, ist, noch drei weitere Tags hinzuzufugegen:
 
 TMC:cid_58:tabcd_1:Class = Point
 TMC:cid_58:tabcd_1:LCLversion = 9.00
 TMC:cid_58:tabcd_1:PrevLocationCode = 28866
 
[ ]
 
 Wenn jemand ein paar tausend Fotos hat und an irgendwelche Nodes in
 Deutschland sowas dranpappt wie foto_url=..., dann sagt ja keiner was
 (das versteht vorallem auch jeder). Aber von diesen TMC-Tags gibt es
 mittlerweile 175000 in Deutschland.
 
 Die Botschaft, die bei einem neuen Mapper da ankommt, ist doch: Oh, ein
 kryptisch getaggtes Objekt. Das fass ich mal lieber nicht an.

Das ist auch gar nicht so schlecht. Ein neuer Mapper sollte in so einem Fall 
jemanden fragen, der schon länger dabei ist.

 
 Mir erschliesst sich der Nutzen dieser Tags nicht - kann mir jemand mal
 eine praktische Anwendung zeigen, die diese Tags benutzt?

Unser Tagging-Stil ist doch das berühmte Wir taggen nicht für  Insofern 
ist es egal, ob es dafür zur Zeit eine Anwendung gibt. Im Übrigen hoffe ich, 
dass mkgmap irgendwann in der Lage sein wird, den TMC-Kram so aufzubereiten, 
dass die Garmin-Navis das komplett verstehen.

[ ]
 Wenn jetzt an einem Objekt z.B. nur eine TMC-ID dranstehen wuerde und
 alles weitere - was fuer eine Klasse, was ist die naechste ID, die
 vorherige ID, wassweissich - waere extern, koennte man damit ja schon
  leben.

Das wäre wahrscheinlich die beste Lösung.

 
 Ich suche also sozusagen eine Exit-Strategie. Ich will herausfinden,
 was und wem diese Daten nutzen, und dann ein Konzept machen, wie wir die
 Daten aus OSM entfernen koennen, ohne diesen Nutzen zu ruinieren.
 
 Ausser natuerlich, alle ausser mir finden diese TMC-Daten ganz knorke
 und haetten lieber noch viel mehr Tags der Art
 BPF:grq_23:tiwwhs_2:MegaCode = 281763.

Einen Vorteil haben die tags noch: Sieht auf Präsentationen wesentlich 
professioneller aus als highway=traffic_light.

:-)

Gruß, Wolfgang

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Pascal Neis


Hi,

Fred Jelk schrieb:

Am 02.02.2011 11:10, schrieb Frederik Ramm:

Hallo,

Mir erschliesst sich der Nutzen dieser Tags nicht - kann mir jemand 
mal eine praktische Anwendung zeigen, die diese Tags benutzt?


Wenn ich mich nicht irre, werden die TMC-Daten von openrouteservice 
ausgewertet



derzeit verwendet ORS diese OSM TMC Tags noch nicht, ich
arbeite aber daran und wollte dies in Zukunft integrieren.
Ich habe mich in der Vergangenheit etwas intensiver mit TMC
und OSM beschäftigt und für die FOSSGIS auch einen Vortrag
darüber eingereicht. Frederik kommt mit seiner Diskussion
jetzt etwas früh ;), ich wollte bei der FOSSGIS nach meinem
Vortrag auch eine Diskussion diesbzgl. starten, etwas
überspitzt: Macht es Sinn, wie (ob) derzeit die TMC Daten
in OSM eingearbeitet werden?

viele gruesse
pascal

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Peter Wendorff


Am 02.02.2011 11:53, schrieb Henning Scholland:

Hallo
Solche kryptischen Dinge gibt es bei Importen recht häufig. Die 
Hausnummern in Dänemark haben zich Tags, die man in OSM nicht 
bräuchte. In Italien schwirren auch einige herum.
Ich verstehe, dass man irgendsowas braucht, um bspw. später Updates zu 
fahren. Aber meiner Meinung nach gehört so eine übersetzung in eine 
externe Datenbank und dann neben den OSM-üblichen Tags eine eindeutige 
ID in unsere Datenbank. Diese ID kann dann auch gerne kryptische 
Values und keys haben.
Ich würde bei 1:1-Zuordnungen nicht einmal eine ID in die OSM-Datenbank 
einfügen, sondern diese Verknüpfung in der extra-DB oder einer dritten 
Verknüpfungsinstanz halten.
Daher zu deinen Ausführungen über TMC-Daten ein +1. Die TMC-Daten an 
sich scheinen ja frei zugänglich zu sein, sodass man diese Daten 
ähnlich wie auch die Höhendaten aus der externen Datenbank mit der in 
OSM hinterlegten ID ziehen kann.

Ich hab im Wiki mal nachgelesen.
Die Daten sind nicht ganz frei verfügbar, aber die Erlaubnis zu 
Verwendung in OSM ist wohl da.


Das Wiki dokumentiert eigentlich insgesamt recht gut, was da gemacht 
wird und welches Tagging-Schema verwendet wird.


Ob man das gerne so hätte oder nicht, ist eine andere Frage; Frederiks 
Kritik, die Daten seien nicht lesbar, stimme ich durchaus zu.


Die Argumente im Wiki sind allerdings auch nicht ganz von der Hand zu 
weisen; und immerhin wird mit TMC: ein eindeutiges Prefix verwendet.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden André Riedel

Ich bin gegen ein Löschen der TMC-Daten.

Richtig ist zwar, dass relativ viele Information zusätzlich
gespeichert werden, welche nicht immer notwendig sind, da sie einfach
von einem Bot hinzugefügt werden können. Aber ein genereller Abgleich
ist nicht fehlerfrei möglich.

Marcus Wohlschon (der Initiator) hat bereits einige Automatismen
untersucht. Deutschland dient daher in erster Linie zum Test von
Import/Verknüpfung von TMC in/mit OSM. Bei Straßen mit einem way
oder einfachen Kreuzungen ist eine automatische Verknüpfung in 99%
möglich. Komplizierter wird es bei mehrspurigen Straßen (Autobahnen)
mit getrennten Ways für Hin- und Rückweg sowie Kreuzungen mehrspuriger
Straßen.

Visualisierung und Stand des TMC-Imports:
http://osm-tmc.anders-hamburg.de/?zoom=13lat=51.05703lon=13.73706layers=B0T

Die Diskussion sollte daher nicht in die Richtung, Wie können wir die
Daten so schnell wie möglich löschen? sondern mehr in Richtung Wie
können wir das Tagging vereinfachen/lesbarer gestalten? gehen.

Ciao André

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Andreas Labres

On 02.02.11 12:33, Pascal Neis wrote:
 ich wollte bei der FOSSGIS nach meinem
 Vortrag auch eine Diskussion diesbzgl. starten, etwas
 überspitzt: Macht es Sinn, wie (ob) derzeit die TMC Daten
 in OSM eingearbeitet werden? 

Ich kenne die Natur dieser TMC Daten/Location Codes nicht, grundsätzlich würde
ich meinen, eine Referenzierung dieser Location Code bezeichnet diese(s)
Element(e) in OSM würde grundsätzlich Sinn machen. Sodaß eine auswertende App
verstehen kann: auf Stück X der Autobahn ist Stau, daher zeichne ich dort eine
rote Line (oder ein Router weiß, diese Kanten verwende ich nicht oder bewerte
ich mit Aufschlag).

Sollten die TMC-Daten aber nur Punkte/Flächen definieren, macht es keinen Sinn,
das kann man dann anhand der Lage verschneiden.

Vielleicht kannst Du (oder jemand andere mit Detailwissen) das mal näher
erklären, bitte?

Servus, Andreas


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden M∡rtin Koppenhoefer

Am 2. Februar 2011 11:10 schrieb Frederik Ramm frede...@remote.org:
 Wir haben fast aussschliesslich menschenlesbare Daten in OSM. Schnapp Dir
 ein beliebiges Objekt, und Du kannst in aller Regel verstehen, was die Tags
 daran bedeuten.


ich kenne die Details der TMC-Daten nicht, aber durch das TMC-Präfix
ist ja klar, in welche Richtung das gehört, von daher finde ich das
jetzt nicht so tragisch.


 Wenn jemand ein paar tausend Fotos hat und an irgendwelche Nodes in
 Deutschland sowas dranpappt wie foto_url=..., dann sagt ja keiner was (das
 versteht vorallem auch jeder).


wenn aber jeder Facebook-nutzer im Schnitt 100 Fotos in OSM verortet,
würde man vielleicht schon was sagen. Zumindest sind das erstmal keine
Geodaten (ohne das Foto), sondern Linksammlungen. Ähnlich verhält es
sich zwar auch mit TMC, aber die Daten sind wenigstens öffentlich
zugänglich, was man bei vielen der verlinkten Fotos nicht sagen kann.


 Aber von diesen TMC-Tags gibt es mittlerweile
 175000 in Deutschland.


ohne die Qualität der Daten zu kennen, hört sich das doch erstmal
beeindruckend ein. Die Italiener sind jedenfalls neidisch auf die
Daten ;-)

Gruß Martin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Wolfgang

Hallo,
Am Mittwoch 02 Februar 2011 12:34:46 schrieb Peter Wendorff:
 Am 02.02.2011 11:53, schrieb Henning Scholland:
  Hallo
  Solche kryptischen Dinge gibt es bei Importen recht häufig. Die
  Hausnummern in Dänemark haben zich Tags, die man in OSM nicht
  bräuchte. In Italien schwirren auch einige herum.
  Ich verstehe, dass man irgendsowas braucht, um bspw. später Updates zu
  fahren. Aber meiner Meinung nach gehört so eine übersetzung in eine
  externe Datenbank und dann neben den OSM-üblichen Tags eine eindeutige
  ID in unsere Datenbank. Diese ID kann dann auch gerne kryptische
  Values und keys haben.
 
 Ich würde bei 1:1-Zuordnungen nicht einmal eine ID in die OSM-Datenbank
 einfügen, sondern diese Verknüpfung in der extra-DB oder einer dritten
 Verknüpfungsinstanz halten.

Sobald in OSM ein Node gelöscht wird, ist die Zuordnung für die Katz. Das 
funktioniert nicht, zumal man dann in OSM gar nicht erkennen kann, dass am 
Node etwas dranhängt. Wenn ich einen Node in einem Straßenverlauf lösche, 
nehme ich einen ohne tags. 

Gruß, Wolfgang

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Pascal Neis


Hi,

Andreas Labres schrieb:

On 02.02.11 12:33, Pascal Neis wrote:

ich wollte bei der FOSSGIS nach meinem
Vortrag auch eine Diskussion diesbzgl. starten, etwas
überspitzt: Macht es Sinn, wie (ob) derzeit die TMC Daten
in OSM eingearbeitet werden? 


Ich kenne die Natur dieser TMC Daten/Location Codes nicht, grundsätzlich würde
ich meinen, eine Referenzierung dieser Location Code bezeichnet diese(s)
Element(e) in OSM würde grundsätzlich Sinn machen. Sodaß eine auswertende App
verstehen kann: auf Stück X der Autobahn ist Stau, daher zeichne ich dort eine
rote Line (oder ein Router weiß, diese Kanten verwende ich nicht oder bewerte
ich mit Aufschlag).


ich greife meinem Vortrag jetzt mal etwas vor:
Bei dem was Andreas oben beschreibt liegt z.B.
bereits ein Problem vor, weil dies so derzeit nicht
ganz einfach aus OSM herauszubekommen ist, es aber
so benötigt werden würde. Meiner Meinung nach sollte
man etwas überdenken wie man die TMC Codes einträgt.
TMC Staus oder Verkehrsbehinderungen beziehen sich
im Normalfall immer auf Straßenstücke. Diese werden
durch einen LocationCode From und To angegeben.
Diese Information ist so aber derzeit nicht bei uns
in den Daten drin und lässt sich auch eher nur
mühselig aus den OSM Daten ableiten. Dazu kommen dann
noch Faktoren wie OSM Relations und tlw. nicht
richtig eingetragene TMC Codes oder unsauber
getrennte OSM Ways ...

viele gruesse
pascal

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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


Hallo,

On 02/02/11 13:12, Wolfgang wrote:

Ich würde bei 1:1-Zuordnungen nicht einmal eine ID in die OSM-Datenbank
einfügen, sondern diese Verknüpfung in der extra-DB oder einer dritten
Verknüpfungsinstanz halten.


Sobald in OSM ein Node gelöscht wird, ist die Zuordnung für die Katz. Das
funktioniert nicht, zumal man dann in OSM gar nicht erkennen kann, dass am
Node etwas dranhängt. Wenn ich einen Node in einem Straßenverlauf lösche,
nehme ich einen ohne tags.


Das ist allerdings ein allgemeines Problem, das immer wieder aufkommt - 
wie kann man von extern in OSM hinein linken und dabei halbwegs 
fehlertolerant sein (d.h. ohne in OSM ein Loesch- und Editierverbot des 
verlinkten Objekts zu fordern).


Natuerlich kann man das Problem umgehen, indem man aus OSM heraus auf 
die externe Datenbank linkt - aber das skaliert nicht, oder im 
Volksmund: Wenn das jeder machen wuerde ;)


Bye
Frederik

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Andreas Labres

On 02.02.11 14:05, Pascal Neis wrote:
 TMC Staus oder Verkehrsbehinderungen beziehen sich
 im Normalfall immer auf Straßenstücke.

Das wäre auch mein Verständnis/meine praktische Erfahrung mit TMC. Und die gilt
es in OSM identifizierbar zu machen (IMO). Wenn dazu die Strategie des Taggens
geändert werden muß, sollte man das tun.

Servus, Andreas


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

On Wed, 2011-02-02 14:19:50 +0100, Andreas Labres l...@lab.at wrote:
 On 02.02.11 14:05, Pascal Neis wrote:
  TMC Staus oder Verkehrsbehinderungen beziehen sich
  im Normalfall immer auf Straßenstücke.
 
 Das wäre auch mein Verständnis/meine praktische Erfahrung mit TMC.
 Und die gilt es in OSM identifizierbar zu machen (IMO). Wenn dazu
 die Strategie des Taggens geändert werden muß, sollte man das tun.

...und in ganz NRW gibts Nebel und Eisregen. Sowas kommt nicht nur
gesprochen vom Radio-Moderator, sondern wird eben auch via TMC
übertragen.

In TMC (via Radio bzw. teilweise auch via Sat-Radio zu empfangen)
werden letztlich drei Zahlen geschickt. Zwei davon (wobei eine leer
sein kann) ist der Location Code, die dritte Zahl gibt den Grund (und
ggf. die geschätzte Dauer) an.

Problematisch ist, daß die Punkte/Strecken/Polygone nicht trivial auf
die OSM-Gegenstücke übertragbar sind. Es gibt beispielsweise
straßentechnisch nicht das Kreuz A2/A1, sondern ein ganzes Bündel an
Ab- und Auffahrten. Um dann das Stück Strecke zwischen
(beispielsweise) diesem Kreuz und einer Abfahrt davor (wo
möglicherweise der Stau beginnt) herauszufinden, ist in den guten
OSM-Daten eben etwas mehr Aufwand nötig, weil u.a. die Fahrtrichtung
berücksichtigt werden muß.

Daher ists auch nicht so einfach machbar, einfach einen Punkt aufs
das Kreuz zu setzen und den Location Code dabeizuschreiben...

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:   ...und wenn Du denkst, es geht nicht mehr,
the second  :  kommt irgendwo ein Lichtlein her.


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

On Wed, 2011-02-02 14:22:50 +0100, Frederik Ramm frede...@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  jbg...@lug-owl.de  +49-172-7608481
 Signature of:Arroganz verkürzt fruchtlose Gespräche.
 the second  :   -- Jan-Benedict Glaw


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Martin Simon

Am 2. Februar 2011 14:07 schrieb Frederik Ramm frede...@remote.org:
 Sobald in OSM ein Node gelöscht wird, ist die Zuordnung für die Katz. Das
 funktioniert nicht, zumal man dann in OSM gar nicht erkennen kann, dass am
 Node etwas dranhängt. Wenn ich einen Node in einem Straßenverlauf lösche,
 nehme ich einen ohne tags.

 Das ist allerdings ein allgemeines Problem, das immer wieder aufkommt - wie
 kann man von extern in OSM hinein linken und dabei halbwegs fehlertolerant
 sein (d.h. ohne in OSM ein Loesch- und Editierverbot des verlinkten Objekts
 zu fordern).

Wieso merkt sich die externe Datenbank dann nicht einfach die
Koordinaten des OSM-Objektes, solange es da ist (und ggf. den groben
Objekttyp und ref/name) und löst einen Bugreport aus, wenn sie
feststellt, daß das verlinkte OSM-Objekt nicht mehr Existiert, seine
Position um mehr als 100m verändert hat oder Objekttyp/ref/name
geändert wurde?

Damit könnte die externe Datenbank Updates erhalten, ohne in OSM
schreiben zu müssen und bei Veränderungen in OSM, auf die die externe
Datenbank linkt, könnte für *deren* Maintainer Alarm ausgelöst
werden. :-)
In einfachen Fällen nach bestimmten Kriterien (z.B. shop-Node gelöscht
und als way mit gleichen tags an gleicher Position (+- X m) wieder
hochgeladen) könnte man die Verlinkung eventuell sogar automatisch
nachführen.

Am besten wäre es vermutlich, für solche Fälle eine API zu haben, über
die sich externe Datenbanken über Veränderungen bestimmter
abonnierter Objekte in OSM informieren können - dann wäre es auch
einfacher, externe Datenbanken wie Fahrpläne, Öffnungszeiten,
Veranstaltungskalender etc. mit OSM-Objekten zu verknüpfen...

Gruß,

Martin (der keine Ahnung hat, ob und wie sowas tatsächlich umgesetzt
werden könnte)

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Wolfgang

Hallo,
Am Mittwoch 02 Februar 2011 14:07:53 schrieb Frederik Ramm:
 Hallo,
 

 
 Natuerlich kann man das Problem umgehen, indem man aus OSM heraus auf
 die externe Datenbank linkt - aber das skaliert nicht, oder im
 Volksmund: Wenn das jeder machen wuerde ;)
 

Das sehe ich in diesem Fall komplett anders. DIe TMC-Geschichte gehört zu den 
zentralen Daten, die zumindest mit OSM eng vermascht werden müssen. Routing 
mit Verkehrsinfo ist einfach Stand der Technik. Darum einen Bogen zu machen, 
weil man die Radiowellen oder tags in der Natur nicht sieht, damit man nichts 
auf den ersten Blick unverständliches lesen muss, ist für mich indiskutabel. 
Manche tags gehören einfach rein, auch wenn sie nur virtuell vorhanden sind.

Zur Erinnerung: Die tmc-Tags sind keine Erfindung irgendwelcher OSM-Spezies, 
sondern vorgegebene virtuelle Marken, die der Nutzer, der OSM-Daten für sein 
Navi verwenden möchte, braucht.

Drin lassen oder sehr eng verlinken, auch aus OSM heraus!

Gruß, Wolfgang

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Bernd Wurst

Hallo.

Am Mittwoch 02 Februar 2011, 15:56:03 schrieb Wolfgang:
 DIe TMC-Geschichte gehört zu den 
 zentralen Daten, die zumindest mit OSM eng vermascht werden müssen.
 Routing  mit Verkehrsinfo ist einfach Stand der Technik.

Aber ist nicht einerseits die Datenübertragung des TMC und auch die 
Herangehensweise wie die TMC-Codes definiert sind stark veraltete Technik und 
wird das nicht in Zukunft sowieso anders laufen?

Also es ist ja abzusehen, dass die UKW-Übertragung alsbald von einer Internet-
Übertragung abgelöst wird, fast alle jetzt neu entwickelten Geräte haben ja 
mobilen Internetzugang. Wäre die Frage ob die TMC-Codes für diese 
Ü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.

Weiß jemand wie TMCpro hier arbeitet? Auch mit (den selben) Location-Codes?

Gruß, Bernd

-- 
Fachbegriffe der Informatik (#286): Googlehupf
   Abstand zwischen zwei Suchergebnissen.
(Markus Kempken)


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

On Wed, 2011-02-02 16:19:59 +0100, Bernd Wurst be...@bwurst.org wrote:
 Am Mittwoch 02 Februar 2011, 15:56:03 schrieb Wolfgang:
  DIe TMC-Geschichte gehört zu den 
  zentralen Daten, die zumindest mit OSM eng vermascht werden müssen.
  Routing  mit Verkehrsinfo ist einfach Stand der Technik.
 
 Aber ist nicht einerseits die Datenübertragung des TMC und auch die 
 Herangehensweise wie die TMC-Codes definiert sind stark veraltete Technik und 
 wird das nicht in Zukunft sowieso anders laufen?

Veraltet? Naja, Das Nutzdaten-pro-Bit-Verhältnis ist bei dem, was
übertragen wird, echt verdammt gut!  Wenn veraltet und anders
laufen bedeutet, daß mehr bloat kommt, dann...

 Also es ist ja abzusehen, dass die UKW-Übertragung alsbald von einer Internet-
 Übertragung abgelöst wird, fast alle jetzt neu entwickelten Geräte haben ja 
 mobilen Internetzugang. Wäre die Frage ob die TMC-Codes für diese 

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.

 Ü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 ;-)

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
the second  :


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Frank Gruender

Moin,

Am 02.02.2011 15:56, schrieb Wolfgang:
 Hallo,
 Am Mittwoch 02 Februar 2011 14:07:53 schrieb Frederik Ramm:
 Natuerlich kann man das Problem umgehen, indem man aus OSM heraus auf
 die externe Datenbank linkt - aber das skaliert nicht, oder im
 Volksmund: Wenn das jeder machen wuerde ;)
 
 Das sehe ich in diesem Fall komplett anders. DIe TMC-Geschichte gehört zu den 
 zentralen Daten, die zumindest mit OSM eng vermascht werden müssen. Routing 
 mit Verkehrsinfo ist einfach Stand der Technik. Darum einen Bogen zu machen, 
 weil man die Radiowellen oder tags in der Natur nicht sieht, damit man nichts 
 auf den ersten Blick unverständliches lesen muss, ist für mich indiskutabel. 
 Manche tags gehören einfach rein, auch wenn sie nur virtuell vorhanden sind.
 
 Zur Erinnerung: Die tmc-Tags sind keine Erfindung irgendwelcher OSM-Spezies, 
 sondern vorgegebene virtuelle Marken, die der Nutzer, der OSM-Daten für sein 
 Navi verwenden möchte, braucht.
 
 Drin lassen oder sehr eng verlinken, auch aus OSM heraus!

muß mich schon stark wundern, das hört sich nach Relevanz-Diskussionen
ala Wikipedia an.

TMC ist funktional direkt auf Navigationssysteme ausgelegt und nicht für
Mikrowellen und Waschmaschinen. Die Aktualität dürfte in der Regel
größer als bei Telefonnummern irgendwelcher Restaurants sein. OSM ist
gerade für Navigationssyteme und für Landkarten gedacht.

Und die Logik: Kenn ich nicht, ess ich nicht kann wohl kein Grund
sein, TMC-Daten zu löschen. Da fallen mir auf Anhieb Tags ein, die weder
mit Landkarten, noch Navis etwas zu haben, aber die Krücke muß ich wohl
hier nicht bemühen.

*entsetzt* Elwood






___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Bernd Wurst

Hallo.

Am Mittwoch 02 Februar 2011, 16:35:38 schrieb Jan-Benedict Glaw:
  Aber ist nicht einerseits die Datenübertragung des TMC und auch die
  Herangehensweise wie die TMC-Codes definiert sind stark veraltete Technik
  und wird das nicht in Zukunft sowieso anders laufen?
 Veraltet? Naja, Das Nutzdaten-pro-Bit-Verhältnis ist bei dem, was
 übertragen wird, echt verdammt gut!  Wenn veraltet und anders
 laufen bedeutet, daß mehr bloat kommt, dann...

Das mag sein, aber macht das in der Praxis was aus?
Also viel zu oft geht die Daten-Sparsamkeit in die Richtung, dass dann 
irgendwelche proprietären oder zumindest fast nicht re-implementierbaren 
Algorithmen zum Zug kommen.

Siehe meinen naiven Vorschlag, das ist zwar vermutlich etwas bloated aber 
trivial auszuwerten ohne jedliche Dritt-Daten, Chiffre-Listen oder sonstiges 
Zeug wofür man jederzeit Geld verlangen könnte. Selbst ein GPS-Gerät ohne 
jegliche Karte könnte einem sagen wo man nicht hin fahren soll.

Zudem hier ja nur Broadcast zur Verfügung steht, bei einer IP-Verbindung würde 
man naheliegender Weise ein Poll-Verfahren benutzen und nur das runterladen 
was einen interessiert.


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

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?


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

Gruß, Bernd

-- 
Ich moechte Windows kaufen. Sind Sie verrueckt?
Gehoert das zu den Lizenzbedingungen?


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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


Hallo,

On 02/02/11 16:52, Frank Gruender wrote:

TMC ist funktional direkt auf Navigationssysteme ausgelegt und nicht für
Mikrowellen und Waschmaschinen. Die Aktualität dürfte in der Regel
größer als bei Telefonnummern irgendwelcher Restaurants sein. OSM ist
gerade für Navigationssyteme und für Landkarten gedacht.


Das ist doch aber kein Argument. TMC ist keine inhaerente Eigenschaft 
der Strassen und Wege, die wir vor uns sehen. TMC ist eine komplett 
separate Datenbank, die mit OSM erstmal nichts zu tun hat und die sich 
irgendeine dritte Stelle ausgedacht hat. Eine von ziemlich vielen, wie 
ich annehme. Ich bin nicht ueberzeugt, dass diese Datenbank nur nutzbar 
gemacht werden kann, indem sie komplett in OSM importiert und dort 
gepflegt wird.



Und die Logik: Kenn ich nicht, ess ich nicht kann wohl kein Grund
sein, TMC-Daten zu löschen. Da fallen mir auf Anhieb Tags ein, die weder
mit Landkarten, noch Navis etwas zu haben, aber die Krücke muß ich wohl
hier nicht bemühen.


Grundsaetzlich haben die meisten Leute Respekt vor fremden Daten, die 
sie nicht kennen. Trotzdem muss man davon ausgehen, dass 
unverstaendliche und un-ueberpruefbare Daten oefter mal unter die Raeder 
geraten oder verfaelscht werden, auch voellig unabsichtlich. Das, was 
wir im Augenblick haben, ist ganz bestimmt keine tragfaehige Loesung, 
und wenn es, wie jemand anders sagte, ein Pilotschema zur Erfassung 
von TMC in anderen Laendern sein sollte, dann wuerde ich sagen, es ist 
gescheitert.


Aber ich bin sicher, dass es eine Loesung gibt, die es ermoeglicht, die 
TMC-Datenbank z.B. bei der Datenaufbereitung fuers Navi hinzuzuladen, 
statt die TMC-Datenbank komplett in OSM zu stopfen und damit (a) allen 
auf die Nerven zu fallen und (b) Datenfehlern Tuer und Tor zu oeffnen.


Jan-Benedict, habe ich Dich richtig verstanden, dass ein TMC-Code 
praktisch sowas bezeichnet wie eine etwas abstrakte Strassenkreuzung? 
Das haben wir doch z.B. bei Mautpunkten auch - da wird die Maut zwischen 
der Anschlusstelle A und der Anschlusstelle B berechnet, und diese 
Anschlusstellen sind ja bei uns in OSM auch keine Nodes, sondern ein 
Sammelsurium an Nodes, motorway_links, usw.


Wenn ich nun z.B. eine Relation haette, die mir besagt: Die folgenden 15 
Objekte machen zusammen die Anschlusstelle 13 der A8 aus, und das ganze 
Ding hat den TMC-Code soundso - wuerde mir das dann reichen? Oder hat 
die Anschlusstelle 13 verschiedene TMC-Codes, je nachdem, in welche 
Richtung man sie betrachtet?


Und warum TMC:cid_58:tabcd_1:... - muss man davon ausgehen, dass es die 
gleichen LocationCodes auch im Namensraum TMC:cid_59:tabcd_1 oder 
TMC:cid_58:tabcd_2 gibt?


Und nochmal meine Frage von eingangs: Der Mapper hatte zunaechst nur 
LocationCode = 47739 gesetzt. Der Bot hat dann PrevLocationCode = 28866 
ergaenzt. Wo hat der Bot diese Information her - und wenn es einen 
Algorithmus gibt, nach dem der Bot das ermitteln konnte, warum muss es 
dann explizit in der Datenbank stehen? Koennte es sein, dass der 
Algorithmus falsche Ergebnisse liefert und ich das dann von Hand im 
Einzelfall auf PrevLocationCode = 28867 korrigieren muss oder so?


Bye
Frederik


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Fabian Schmidt



Am 02.02.11 schrieb Jan-Benedict Glaw:


Einfache Mappings sind mit TMC so nicht zu machen.


was ist, wenn Du die Location-Codes der Punkte an die verbindenden Ways 
hängst? z.B. bei oneways (Autobahnen):

  tmc_ref=12345-54321 / tmc_ref=54321-12345
und bei normalen Straßen
  tmc_ref=12345-54321

Und ggf. noch zusätzlich die Segment-ID:
  tmc_sref=2468


Fabian.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Henning Scholland


Am 02.02.2011 15:26, schrieb Jan-Benedict Glaw:

On Wed, 2011-02-02 14:19:50 +0100, Andreas Labresl...@lab.at  wrote:

On 02.02.11 14:05, Pascal Neis wrote:

TMC Staus oder Verkehrsbehinderungen beziehen sich
im Normalfall immer auf Straßenstücke.

Das wäre auch mein Verständnis/meine praktische Erfahrung mit TMC.
Und die gilt es in OSM identifizierbar zu machen (IMO). Wenn dazu
die Strategie des Taggens geändert werden muß, sollte man das tun.

...und in ganz NRW gibts Nebel und Eisregen. Sowas kommt nicht nur
gesprochen vom Radio-Moderator, sondern wird eben auch via TMC
übertragen.

In TMC (via Radio bzw. teilweise auch via Sat-Radio zu empfangen)
werden letztlich drei Zahlen geschickt. Zwei davon (wobei eine leer
sein kann) ist der Location Code, die dritte Zahl gibt den Grund (und
ggf. die geschätzte Dauer) an.

Problematisch ist, daß die Punkte/Strecken/Polygone nicht trivial auf
die OSM-Gegenstücke übertragbar sind. Es gibt beispielsweise
straßentechnisch nicht das Kreuz A2/A1, sondern ein ganzes Bündel an
Ab- und Auffahrten. Um dann das Stück Strecke zwischen
(beispielsweise) diesem Kreuz und einer Abfahrt davor (wo
möglicherweise der Stau beginnt) herauszufinden, ist in den guten
OSM-Daten eben etwas mehr Aufwand nötig, weil u.a. die Fahrtrichtung
berücksichtigt werden muß.

Daher ists auch nicht so einfach machbar, einfach einen Punkt aufs
das Kreuz zu setzen und den Location Code dabeizuschreiben...

MfG, JBG
So wie ich das Verstanden hab sind die TMC-Objekte in Abschnitte 
unterteilt. Auf diesen Abschnitten befinden sich (mehrere) OSM-Ways. 
Dann ist doch kein Problem, an allen OSM-Objekten eine TMC-ID zu taggen, 
je nach Zugehörigkeit und in einer seperaten Datenbank dann eine 
Zuordnung zwischen den ganzen TMC-Eigenschaften und dieser ID zu 
hinterlegen. Will man nun die Daten auswerten, findet man in den 
OSM-Daten die ID und sucht sich die passenden TMC-Eigenschaften aus der 
Datenbank heraus.

Bei Ampel-Nodes ist obiges auch ohne Probleme möglich.

Viele Grüße,
Henning


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden NopMap

Hallo!

Ich seh das eher generisch. Beim Durchforsten von Tags, die häufig vorkommen
aber nicht gerendert werden, bin ich auf viele unterschiedliche kryptische
Referenzen, IDs und Spezialtaggings gestoßen, meist mit eigenem Prefix,
deren Sinnhaftigkeit sich dem Normalmapper nicht erschließt. Manches sieht
aus wie Daten aus einem Import, manches riecht nach lokalen Referenzsystemen
oder Spezialinformationen vielleicht für Eisenbahner? Funker? Kanalarbeiter?
verständlich und nützlich. Auf jeden Fall kryptisch ohne tiefere Recherche
nicht zu entschlüsseln. Unter TMC können sich die meisten was vorstellen,
bei den anderen Tags sagt mir noch nicht mal das prefix was. :-)

Entweder ist es so, daß es jedem frei steht, Spezialinformationen zu den
OSM-Daten hinzuzufügen. Dann sind die TMC-Tags eine nützliche Anwendung
dafür.

Oder das ist nicht so. Dann müßte eine allgmeine Policy formuliert werden,
welche Art von Daten willkommen sind und welche nicht. Die müßte
gleichermaßen für alle Spezialanwendungen gelten.

Solange es die nicht gibt, kann man vielleicht darüber diskutieren, ob sich
TMC-Infos besser abbilden lassen und die TMC-Entwickler damit unterstützen.
Aber ich sehe keinen Unterschied zwischen der Behandlung von TMC Infos und
allen anderen Spezialinfos - im Gegenteil, einen Nutzen bei der Erstellung
von Navi-DBs kann ich mir gut vorstellen.

bye
Nop

--
View this message in context:
http://gis.638310.n2.nabble.com/Koennen-wir-die-TMC-Daten-rauswerfen-tp5984176p5985681.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden André Riedel

Am 2. Februar 2011 17:16 schrieb Frederik Ramm frede...@remote.org:
 Und warum TMC:cid_58:tabcd_1:... - muss man davon ausgehen, dass es die
 gleichen LocationCodes auch im Namensraum TMC:cid_59:tabcd_1 oder
 TMC:cid_58:tabcd_2 gibt?

cid ... Land 58

Es kann vorkommen, dass Straßen oder Bereiche im Grenzgebiet in den
TMC-Listen mehrerer Länder vorkommen. Diese haben dann auch einen
unterschiedlichen TMC-Code.

tabcd ... Liste 1

In jedem Land kann es verschiedene Definitionen von wichtigen Straßen
und Knotenpunkten geben. Dies ist in Deutschland mit TMC und TMCpro
gegeben.

Um jetzt bei jedem Element die unterschiedlichen TMC-Codes anzugeben,
wurde analog zu fuel:*=yes ein System mit TMC:Land:Liste=Code
eingeführt.

Eine Alternative aber noch schlechter zu lesen wäre:
TMC = Land:Liste:Code:Richtung; Land2:Liste:Code:Richtung; ...

 Und nochmal meine Frage von eingangs: Der Mapper hatte zunaechst nur
 LocationCode = 47739 gesetzt. Der Bot hat dann PrevLocationCode = 28866
 ergaenzt. Wo hat der Bot diese Information her - und wenn es einen
 Algorithmus gibt, nach dem der Bot das ermitteln konnte, warum muss es dann
 explizit in der Datenbank stehen? Koennte es sein, dass der Algorithmus
 falsche Ergebnisse liefert und ich das dann von Hand im Einzelfall auf
 PrevLocationCode = 28867 korrigieren muss oder so?

In den meisten Fällen kann man das einfach ergänzt werden. Hier ist
jedoch die Frage ob das Notwendig ist. Auf den Wiki-Seiten sind diese
Dinge daher als optional gekennzeichnet.

http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany#Tagging_Schema

Bei einer Straße mit baulich getrennten Fahrspuren und
unterschiedlichen Auf- und Abfahrten ist zumindest die Informationen
der Richtung obligatorisch.

Ciao André

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

On Wed, 2011-02-02 17:02:37 +0100, Bernd Wurst be...@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  jbg...@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.


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Stephan Wolff


Am 02.02.2011 15:37, schrieb Jan-Benedict Glaw:

Die übrigen Nutzer merken nicht viel von den TMC-Tags.


Was soll ein Mapper denn tun, wenn er eine Straße mit
TMC-Tags ändern will. Wenn eine Kreuzung zum Kreisverkehr
umgebaut wurde, eine Straße mit zwei getrennten Fahrbahnen
bislang nur als eine Linie erfasst war oder umgekehrt
statt einer fälschlich zwei Fahrbahnen erfasst waren,
dann ist es sehr schwer, die TMC-Tags anzupassen.

Der Mapper kann
- Änderungen nicht in OSM eingeben.
  Dann verlieren wir Informationen.
- sich in die TMC-Tags einarbeiten.
  Vermutlich sinkt die Motivation des Mappers und er
  produziert doch keine gültigen TMC-Tags
- die vorhandenen TMC-Tags willkürlich auf einen neuen
  Punkt setzen.
  Dann hat man in einer TMC-basierte Auswertung falsche
  Ergebnisse, aber ein Validator merkt nichts, da das
  Tag vorhanden und etwa richtig positioniert ist.

Ich habe einmal die zweite Variante versucht und bin dann
zur dritten Möglichkeit gewechselt. Trotzdem habe ich in
solchen Situationen ein schlechtes Gewissen, da ich mit
der Verbesserung der highway-Daten auch einen tückischen
Fehler in die TMC-Struktur einbaue.

 Im schlimmsten Fall gehen sie verloren.

Manchmal sind falsche Daten schlimmer als fehlende.

Viele Grüße, Stephan


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

On Wed, 2011-02-02 18:23:00 +0100, Henning Scholland o...@aighes.de wrote:
 Am 02.02.2011 15:26, schrieb Jan-Benedict Glaw:
  Problematisch ist, daß die Punkte/Strecken/Polygone nicht trivial auf
  die OSM-Gegenstücke übertragbar sind. Es gibt beispielsweise
  straßentechnisch nicht das Kreuz A2/A1, sondern ein ganzes Bündel an
  Ab- und Auffahrten. Um dann das Stück Strecke zwischen
  (beispielsweise) diesem Kreuz und einer Abfahrt davor (wo
  möglicherweise der Stau beginnt) herauszufinden, ist in den guten
  OSM-Daten eben etwas mehr Aufwand nötig, weil u.a. die Fahrtrichtung
  berücksichtigt werden muß.

 So wie ich das Verstanden hab sind die TMC-Objekte in Abschnitte  
 unterteilt. Auf diesen Abschnitten befinden sich (mehrere) OSM-Ways.  
 Dann ist doch kein Problem, an allen OSM-Objekten eine TMC-ID zu taggen,  
 je nach Zugehörigkeit und in einer seperaten Datenbank dann eine  
 Zuordnung zwischen den ganzen TMC-Eigenschaften und dieser ID zu  
 hinterlegen. Will man nun die Daten auswerten, findet man in den  
 OSM-Daten die ID und sucht sich die passenden TMC-Eigenschaften aus der  
 Datenbank heraus.

Für Straßen kann man grob sagen, daß es deren Enden meistens mit
Kreuzungen oder Ab-/Auffahrten übereinstimmen. Bei Regionen ist das
nicht mehr ganz so einfach.

Es fällt mir ehrlich gesagt recht schwer, umgangssprachlich zu
beschreiben, wie die TMC-Daten funktionieren; mit Stift und Papier
ist das gut zu veranschaulichen.

Das Hauptproblem ist, daß die TMC'schen Wegpunkte gerichtet sind und
eine hierarchische Struktur haben. Das ist ersteinmal sehr
anschaulich, aber der Detaillierungsgrad der OSM-Daten ist häufig
höher, als das TMC-Raster. Besonders auffällig ist das bei
Autobahn-Ab- und -Auffahrten. TMC gibt der Ab-/Auffahrt (bzw. dem
ganzen Kreuz) nur einen Punkt, während wir mit den ganzen
Zubringer-Wegen etc. da schnell viele dutzend Nodes haben. Und je nach
Richtung (wenn man von TMC-Daten auf einen OSM-Straßenabschnitt, der
gerade gesperrt ist, kommen möchte) gibt es dann also nicht die eine
TMC-Position, sondern man muß auf Basis der Positiv-/Negativ-Richtung
zwischen den (beispielsweise) beiden Autobahn-Fahrbahnen unterscheiden
können.

Eine TMC-Meldung könnte sein:

(1234) ist in Positiv-Richtung bis (3212) gesperrt.

Nun muß man von (1234) ausgehend die doppelt verkettete Liste solange
in Positiv-Richtung weitergehen, bis man bei (3212) angekommen ist.
Wird die Autobahn da z.B. kurzzeitig zur Landstraße mit nur einer
Fahrbahn, haben wir in den OSM-Daten da viele lustige ein- und
zweispurige (Richtige Spur wählen!) Wege...

 Bei Ampel-Nodes ist obiges auch ohne Probleme möglich.

Ampeln (also _reine_ Ampeln) sind allerdings keine TMC-Punkte.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: 17:45 @Eimann Hrm, das E90 hat keinen Lebenszeit Call-Time 
Counter mehr
the second  : 17:46 @jbglaw Eimann: Wofür braucht man das?
  17:46 @jbglaw Eimann: Für mich ist an 'nem Handy wichtig, daß 
ich mein
  Gegeüber hören kann. Und daß mein Gegenüber mich 
versteht...
  17:47 @KrisK jbglaw: was du meinst ist wodka.
  17:47 @KrisK jbglaw: es klingelt und man hört stimmen


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Sven Anders


Am 02.02.2011 11:10, schrieb Frederik Ramm:

Hallo,

ich aegere mich ziemlich ueber die TMC-Daten in der OSM-Datenbank. Ich
habe nicht die Uebersicht, wer da alles dran arbeitet und dran
gearbeitet hat, also es besteht die Gefahr, dass ich jetzt einigen
ehrbaren Mappern auf die Fuesse trete, aber wenn's nach mir geht, muss
das Zeug raus.


Da fühle ich mich doch sehr angesprochen.
Ich hab auch die restliche Diskussion in diesem Thread überflogen und 
viel gutes dazu gelesen.


Mein Eindruck ist: Marcus hat sich sehr viel Mühe gemacht ein 
funktionierendes TMC Schema zu entwerfen. Leider gab es sehr wenig 
Kommentare dazu. Alle die ich gerne dazu um eine Meinung gefragt hätte, 
haben immer nur abgewunken, und gesagt, mit TMC beschäftige ich mich 
nicht, da habe ich keine Zeit zu etc..


Ich meine mich zu erinnern, das ich auch dich gefragt hatte.

Bei TMC ist halt das Problem: Eine Anwendung macht erst Sinn, wenn man 
die Daten hat, die Daten kann man erst Sinnvoll in ein Schema pressen, 
wenn man weiß was die Anwendung können soll.


Deshalb habe ich den (bestimmt ausbaufähigen) TMC Validator geschrieben, 
der dazu geführt hat, das diese Daten importiert werden/wurden.


Also haben wir erstmal Daten eingegeben. Jetzt, nachdem das Konzept von 
vielen Freiwilligen unterstützt wirst, kommst du Provokant ;-) daher und 
sagst, ich möchte alles rauswerfen.




Die Botschaft, die bei einem neuen Mapper da ankommt, ist doch: Oh, ein
kryptisch getaggtes Objekt. Das fass ich mal lieber nicht an.


Ja genau so wie z.B. Grenzen (an denen irgendwelche Relationen hängen 
die ja so kompliziert sind ...)




Mir erschliesst sich der Nutzen dieser Tags nicht - kann mir jemand mal
eine praktische Anwendung zeigen, die diese Tags benutzt?



Mir sieht das nach einem grossangelegten Designfehler aus. Da haette man
von vornherein ein OSM-externes Mapping TMC-OSM bauen muessen, statt
praktisch die ganze TMC-Datenbank auf OSM aufzupropfen.


Danke, das du das erst jetzt sagst. Es wäre ja praktischer erst über ein 
Schema zu diskutieren und dann Daten zu importieren. Aber damals hast du 
Dich nicht beteiligt.



Ich will jetzt nicht die Revolution anzetteln und morgen alle TMC-Daten
loeschen (und ich aergere mich, dass ich der Geschichte nicht viel
frueher widersprochen habe).


Warum schreibst du das dann ein paar Absätze höher genau so.

Egal, ich bin dir dankbar, das du das Thema auf die Tagesordnung 
gebracht hast. Denn ich denke am TMC Konzept gibt es durchaus noch 
Verbesserungsbedarf. (Wie bei der Linienbündel-Diskussion, den ÖPNV 
Relationen, ...) Viele der Punkte die du ansprischt, wie z.B. wenig 
sprechende Namen und das Einfügen von optionalen Daten via Bot sind 
vermutlich besser lösbar, aber ich hab mir das Konzept von Marcus 
angesehn und fand es nach durchsicht der TMC Daten-Struktur verständlich.




Aber wenn es nicht irgendwelche
ueberwaeltigenden Gruende dafuer gibt, warum diese Daten in OSM bleiben
muessen, dann bin ich sehr dafuer, dass diejenigen, die diese Daten
verwenden, sich da irgendwie etwas basteln, was weniger invasiv ist.
Wenn jetzt an einem Objekt z.B. nur eine TMC-ID dranstehen wuerde und
alles weitere - was fuer eine Klasse, was ist die naechste ID, die
vorherige ID, wassweissich - waere extern, koennte man damit ja schon
leben.


Lass uns den Vortrag von Pascal abwarten.
Oder  mach einen besseren Vorschlag. Aber der Vorschlag einfach alles 
wieder raus-Löschen zählt IMHO nicht, das würden auch viele Mapper nicht 
verstehen, die diese Daten eingegeben haben, und das gerne auf Ihrem 
Navi benutzen können wollen.


Ich denke allerdings das die Pflicht für einen Vorschlag nicht unbedingt 
bei diejenigen, die diese Daten verwenden liegt, sondern bei Dir, denn 
Dich stört ja die jetzige Form.


Die Form wie die Daten eingegeben werden, kann dazu benutzt werden um 
TMC Meldungen in OSM zu visualisieren. Natürlich gebe es 
Verbesserungspotentzial, aber das gab es ja beim (alten) ÖPNV Schema 
auch, da trifft man sich und baut etwas um etc. Aber man löscht nicht 
einfach alles (schon eine Mail mit diesem Subjekt finde ich sehr 
provokativ). Ich vermute auch das die Verbesserungen eher dazu führen 
werden, das mehr Objekte mit TMC Daten getaggt werden würden.

(Statt einen Punkt evtl. ganze Streckenabschnitte?)


Ich suche also sozusagen eine Exit-Strategie. Ich will herausfinden,
was und wem diese Daten nutzen, und dann ein Konzept machen, wie wir die
Daten aus OSM entfernen koennen, ohne diesen Nutzen zu ruinieren.


 Ausser natuerlich, alle ausser mir finden diese TMC-Daten ganz knorke
 und haetten lieber noch viel mehr Tags der Art
 BPF:grq_23:tiwwhs_2:MegaCode = 281763.

Damit eröffnest du aber ganz klar eine Relevanz-Diskussion.
Ich will nur eine Datenbank für alle Geo-Informationen. Die soll 
OpenStreetMap heißen. Und da dürfen auch kryptische Tags rein, die ich 
nicht verstehe, solange sie sich nicht mit meinen beißen.


Wenn z.B. der Xyz Verlag OSM Karten verwenden möchte und dafür einen Tag

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

2011-02-02 Diskussionsfäden M∡rtin Koppenhoefer

Am 2. Februar 2011 14:07 schrieb Frederik Ramm frede...@remote.org:

 Natuerlich kann man das Problem umgehen, indem man aus OSM heraus auf die
 externe Datenbank linkt - aber das skaliert nicht, oder im Volksmund: Wenn
 das jeder machen wuerde ;)


Komischerweise hast Du bei Photos eine andere Meinung. TMC ist halt
m.E. nicht irgendeine externe Datenbank, sondern eine für das Routing
und die Navigation extrem relevante

Gruß Martin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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


Hallo,

On 02/02/11 19:34, Jan-Benedict Glaw wrote:

Für Straßen kann man grob sagen, daß es deren Enden meistens mit
Kreuzungen oder Ab-/Auffahrten übereinstimmen. Bei Regionen ist das
nicht mehr ganz so einfach.


Aber Regionen koennten ja wiederum sehr gut in einer vollstaendig 
externen Datenbank auf Koordinaten gemappt werden, oder? Also z.B. 
Region 1234 = Polygon(Koordinatenpaar, Koordinatenpaar, ...) - das ist 
ja nun nicht notwendig, dass wir da die exakte Relation Niedersachsen 
in OSM ansprechen, falls mal wieder in ganz Niedersachens 
ueberfrierende Naesse ist. Oder?



Eine TMC-Meldung könnte sein:

(1234) ist in Positiv-Richtung bis (3212) gesperrt.


Welche Zusatzinformation hat in Positiv-Richtung hier? Schliesslich 
gibt es nur einen Weg von 1234 nach 3212 - oder wuerde, wenn die andere 
Richtung betroffen ist, nicht 3212 bis 1234 geschrieben, sondern 1234 
in Negativ-Richtung bis 3212?


Bye
Frederik


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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


Hallo,

On 02/02/11 21:16, Sven Anders wrote:

Mein Eindruck ist: Marcus hat sich sehr viel Mühe gemacht ein
funktionierendes TMC Schema zu entwerfen.


Marcus hat ein Schema fuer Maschinen entworfen. OSM ist aber fuer 
Menschen. Fuer Menschen ist dieses Schema nicht wartbar.



Leider gab es sehr wenig
Kommentare dazu. Alle die ich gerne dazu um eine Meinung gefragt hätte,
haben immer nur abgewunken, und gesagt, mit TMC beschäftige ich mich
nicht, da habe ich keine Zeit zu etc..

Ich meine mich zu erinnern, das ich auch dich gefragt hatte.


Das ist sehr gut moeglich. Wie gesagt, normalerweise finde ich es auch 
das richtige Verhalten, Leute, die sich mit etwas auskennen, einfach mal 
machen zu lassen, und wuerde mich selber jetzt da nicht einmischen. Es 
draengt sich mir aber mehr und mehr der Verdacht auf, dass dieses 
Problem sehr suboptimal geloest wurde und an anderen Stellen Probleme 
schafft, und dass man daher jetzt einen Kurswechsel einleiten (oder die 
Notbremse ziehen) muss, bevor das Problem immer groesser wird.



Bei TMC ist halt das Problem: Eine Anwendung macht erst Sinn, wenn man
die Daten hat, die Daten kann man erst Sinnvoll in ein Schema pressen,
wenn man weiß was die Anwendung können soll.

Deshalb habe ich den (bestimmt ausbaufähigen) TMC Validator geschrieben,
der dazu geführt hat, das diese Daten importiert werden/wurden.


Bist Du auch davon ueberzeugt, dass diese Daten in OSM direkt enthalten 
sein muessen, um genutzt werden zu koennen?



Ich denke allerdings das die Pflicht für einen Vorschlag nicht unbedingt
bei diejenigen, die diese Daten verwenden liegt, sondern bei Dir, denn
Dich stört ja die jetzige Form.


Sicher ist weder das eine noch das andere hundertprozentig richtig.


Damit eröffnest du aber ganz klar eine Relevanz-Diskussion.
Ich will nur eine Datenbank für alle Geo-Informationen. Die soll
OpenStreetMap heißen.


Ich hingegen werde nicht muede, jedem zu sagen, dass alles, was 
sinnvollerweise ausserhalb von OSM gepflegt werden kann, auch ausserhalb 
von OSM gepflegt werden sollte. Ich habe den Eindruck, dass ein grosser 
Teil der heute in OSM erfassten TMC-Daten dazu gehoert.


Dass es sowas gibt wie das Autobahnkreuz Wiesbaden und wo das liegt 
und welche Auf- und Abfahrten dazugehoeren, das sind Geodaten von 
allgemeiner Bedeutung, die auch ganz klar bei uns reingehoeren.


Dass dieses Autobahnkreuz in bestimmten externen Datensaetzen einen 
bestimmten Identifier hat, sehe ich zwar in OSM nicht so gern, aber ich 
wuerde mal sagen, als Kompromiss kann man das mit erfassen -


mautknoten_id=12344
tmc_id=8326765
aldi_sued_distributionsnetz_id=1827
deutsche_telekom_tarifknoten_id=abc7261
rmv_tarifzonengrenz_id=99182

und so weiter. Wenn das irgendwann ueberhand nimmt, kommt der Punkt, an 
dem man von externen Systemen fordern muss, dass sie sich was anderes 
ausdenken, aber erstmal geht es.


Wo ich aber die Grenze ziehe, ist, wenn diese kompletten externen 
Datenbanken mit in OSM abgebildet werden (wenn jetzt zusaetzlich noch 
vermerkt werden soll, in welcher Richtung der naechste Mautknoten liegt, 
wie viele Tarifkilometer der entfernt ist, undsoweiter). *Das* sind 
keine Geodaten mehr.



Und da dürfen auch kryptische Tags rein, die ich
nicht verstehe, solange sie sich nicht mit meinen beißen.


Aber nicht, wenn Du irgendwann damit rechnen musst, durch die 
Verfeinerung einer Strassengeometrie ploetzlich die akribisch erstellte 
next-node-id-previous-node-id-Struktur von jemand anders kaputt zu 
machen und der sich dann bei Dir beschwert.


Bye
Frederik

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2011-02-02 Diskussionsfäden Ulf Lamping


Am 02.02.2011 22:56, schrieb Frederik Ramm:

Hallo,

On 02/02/11 21:16, Sven Anders wrote:

Bei TMC ist halt das Problem: Eine Anwendung macht erst Sinn, wenn man
die Daten hat, die Daten kann man erst Sinnvoll in ein Schema pressen,
wenn man weiß was die Anwendung können soll.

Deshalb habe ich den (bestimmt ausbaufähigen) TMC Validator geschrieben,
der dazu geführt hat, das diese Daten importiert werden/wurden.


Bist Du auch davon ueberzeugt, dass diese Daten in OSM direkt enthalten
sein muessen, um genutzt werden zu koennen?


Ich bin davon überzeugt, das diese Daten direkt in OSM enthalten sein 
sollten, wenn der Aufwand für einen potentiellen Anwender der Daten 
ungleich geringer ist als diese seperat zu pflegen. Das ist hier aus 
meiner Sicht der Fall.



Und da dürfen auch kryptische Tags rein, die ich
nicht verstehe, solange sie sich nicht mit meinen beißen.


Aber nicht, wenn Du irgendwann damit rechnen musst, durch die
Verfeinerung einer Strassengeometrie ploetzlich die akribisch erstellte
next-node-id-previous-node-id-Struktur von jemand anders kaputt zu
machen und der sich dann bei Dir beschwert.


Da stimme ich dir vollkommen zu.

Gruß, ULFL

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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