Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Mein lieber Ulf, Können wir hier nicht redlich diskutieren? Denn wir sind in vielen Teilen glaub' ich einig. Also: Ich sage nur, dass es von Vorteil wäre, wenn in OSM die Inhalte (Semantik) verständlich beschrieben. Dies erst recht, wenn es sich um eine komplexere Materie handelt, es wenig zugängliche Literatur gibt und es sich um ein (an sich lobenswertes) grösseres Vorhaben handelt. Das gilt für TMC zu auch auch für OePNV. Wer das als Papierkram auffasst oder wem ein Internetprotokoll mehr liegt, soll sich mit anderen zusammentun. Du schreibst zur Forderung nach einfachen Modellen: Ich glaube nicht das dies der wirklich kritische Punkt ist. Was denn? und weiter: Über das Problem sinnvoll eine externe DB mit unserer zu verzahnen, also mit Minimum an manuellem Aufwand und benutzbar für Datenanwender, hatten wir doch schon häufiger gesprochen und bislang m.W. noch keine wirklich brauchbare Lösung gefunden. Hat das schon jemand vergeblich vesucht? Wenn handeln besser als reden ist, dann hier! Zurück zu TMC Modell: Man könnte nun klären, ob die Tables-Angabe nötig ist. Das hat meines Wissens nicht mit länderübergreifenden Meldungen zu tun, sondern mit der Tatsache, dass ein Land mehr als ein Table haben kann. Wenn nein, ergäbe das den Tag tmc:locationcode=countryid_58:52864. Das müsste für die Variante Verknüpfung mit externer DB reichen. Wenn die aktuelle Variante so bleibt, hätte ich da noch eine ganze Reiher grundlegender Fragen: Wenn so bleibt, wie es jetzt angelegt ist und es gibt zwei Tables (oder zwei Länder) und je zwei LCLVersionen, dann müssten wir mit zwei, vier, sechs Tag-Gruppen à je sechs Tags rechnen, oder? Da lohnt es sich m.E., sich das nochmals zu überlegen. Da wird z.B. offenbar eine Relation an einen Node gehängt: http://www.openstreetmap.org/browse/relation/374604 relation id=374604 ... member type=node ref=10210539 role=/ tag k=TMC:cid_58:tabcd_1:Class v=Point/ tag k=TMC:cid_58:tabcd_1:Direction v=both/ tag k=TMC:cid_58:tabcd_1:LCLversion v=8.00/ tag k=TMC:cid_58:tabcd_1:LocationCode v=35722/ tag k=TMC:cid_58:tabcd_1:NextLocationCode v=46160/ tag k=type v=tmc/ /relation Da scheint etwas redundant (oder aber überlagernd) zu sein, wenn man mit dem Mitglieder-Knoten 10210539 vergleicht http://www.openstreetmap.org/browse/node/10210539 : node id=10210539 lat=53.4710971 lon=9.9011535 ... tag k=highway v=traffic_signals/ tag k=TMC:cid_58:tabcd_1:Class v=Point/ tag k=TMC:cid_58:tabcd_1:LCLversion v=8.00/ tag k=TMC:cid_58:tabcd_1:LocationCode v=25005/ tag k=TMC:cid_58:tabcd_1:PrevLocationCode v=25004/ tag k=TMC:cid_58:tabcd_1:NextLocationCode v=25006/ tag k=TMC:cid_58:tabcd_1:Direction v=both/ /node * Das sind praktisch dieselben Tags aber mit anderen Values(?). * Macht das Sinn, eine (oder mehrere) Relation(en) pro Node? * Warum fehlt bei der Relation PrevLocationCode? * Für was brauchts Class Point, wenn es schon ein Node ist? Wäre das nicht viel eleganter: node id=10210539 lat=53.4710971 lon=9.9011535 ... tag k=highway v=traffic_signals/ tag k=tmc:de:locationcode v=25005/ tag k=tmc:de:prevlocationcode v=25004/ tag k=tmc:de:nextlocationcode v=25006/ tag k=tmc:de:direction v=both/ /node d.h. ohne zus. Relation., ohne Tablecode und ohne LCLversion und mit bekannten Länder-Code ISO-3166 (anstelle '58'). Für die Editoren-Erweiterungs-Diskussion wäre das ein Hinweis, Prefixe wenn schon aufklappbar, dann mit mehreren Stufen darzustellen, also aufgeklappt (und mit zweitem LocationCode für die Niederlande): o highway = traffic_signals + tmc + de o locationcode = 25005 o prevlocationcode = 25004 + nl o locationcode = 11013 LG, S. Am 7. Februar 2011 02:51 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Am 07.02.2011 01:21, schrieb Frederik Ramm: Hi, Stefan Keller wrote: = Daher könnte z.B. folgendes etwas sinniger sein: tmc:locationcode=countryid_58:tablecode_1:52864. Ich denke, man koennte auch den Mut zur Luecke haben und einfach nur tmc_location_code=52864 schreiben oder so. Ok, man kriegt damit keine laenderuebergreifenden Meldungen abgebildet, aber kommen die so oft vor? Frag mal die Leute in Trier, die können dir da ein Lied von singen ;-) Ebenso mit dieser table (ulkigerweise dachte ich anfangs wegen tabcd immer, das waere ein Beispielwert, a-b-c-d...) - wenn es wirklich mal zu dem unwahrscheinlichen Fall kommt, dass wir zwei Tables parallel in OSM abbilden muessen, kann man das Problem *dann* loesen. (Es entspricht nicht der Tradition von OSM, ein komplexes Modell aufzubauen fuer Zeugs, das noch gar nicht gebraucht wird und bei dem unklar ist, ob es ueberhaupt jemals gebraucht wird - man macht erstmal was einfaches und kann das dann spaeter immer noch erweitern.) Ich glaube nicht das dies der wirklich kritische Punkt ist. Also ich koennte mir durchaus vorstellen, dass es gelingt, den groessten Teil des TMC-OSM-Matchings komplett
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 8. Februar 2011 10:36 schrieb Stefan Keller sfkel...@gmail.com: * Das sind praktisch dieselben Tags aber mit anderen Values(?). Jedes TMC-Segment (=Straßen) besitzt eigene TMC-Punkte. Eine Kreuzung zweier Straßen zeichnet sich daher durch die Existenz zweier Punkte an der gleichen Koordinate aus. * Macht das Sinn, eine (oder mehrere) Relation(en) pro Node? Bedingt durch die TMC-Definition ja. * Warum fehlt bei der Relation PrevLocationCode? Da es der Anfang der Straße ist. * Für was brauchts Class Point, wenn es schon ein Node ist? Ein OSM-Node und eine TMC-Point sind unterschiedliche Dinge. Aber abgesehen davon müssen diese Informationen nicht in OSM, da jede TMC-ID einmalig vergeben wird. (In OSM kann es einen Node mit ID=1 oder einen Way mit ID=1 geben) Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Danke. Du hast geantwortet: * Warum fehlt bei der Relation PrevLocationCode? Da es der Anfang der Straße ist. Aber warum gibt es dann nebst der TMC-Relation auch am OSM-Node tmc-Tags (mit nextlocationcode)? Wären da ein (oder doch auch am Anfang zwei?) Relationenn nicht klarer - und der OSM-Node ist erst noch entlastet? Und was bedeutet both (wenn es doch der Anfang ist)? Wäre das nun eine Möglichkeit (ohne tmc-Tags am Node und weiterhin ohne Class und LCLversion)? node id=10210539 lat=53.4710971 lon=9.9011535 ... tag k=highway v=traffic_signals/ /node relation id=374604 ... member type=node ref=10210539 role= / tag k=tmc:de:locationcode v=25005/ tag k=tmc:de:prevlocationcode v=25004/ tag k=tmc:de:nextlocationcode v=25006/ tag k=tmc:de:direction v=both/ /relation LG, S. Am 8. Februar 2011 15:07 schrieb André Riedel riedel.an...@gmail.com: Am 8. Februar 2011 10:36 schrieb Stefan Keller sfkel...@gmail.com: * Das sind praktisch dieselben Tags aber mit anderen Values(?). Jedes TMC-Segment (=Straßen) besitzt eigene TMC-Punkte. Eine Kreuzung zweier Straßen zeichnet sich daher durch die Existenz zweier Punkte an der gleichen Koordinate aus. * Macht das Sinn, eine (oder mehrere) Relation(en) pro Node? Bedingt durch die TMC-Definition ja. * Warum fehlt bei der Relation PrevLocationCode? Da es der Anfang der Straße ist. * Für was brauchts Class Point, wenn es schon ein Node ist? Ein OSM-Node und eine TMC-Point sind unterschiedliche Dinge. Aber abgesehen davon müssen diese Informationen nicht in OSM, da jede TMC-ID einmalig vergeben wird. (In OSM kann es einen Node mit ID=1 oder einen Way mit ID=1 geben) Ciao André ___ 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] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Ok; du kannst ja nicht wissen, dass ich wohl mehr technische Elaborate lese und schreibe als die meisten hier. Ich könnte auch ins Institut fahren und ISO-Specs. lesen oder die Leute von Viasuisse selber fragen, die ich nächstens treffe. Aber es geht ja nicht um mich, oder? Ich habe mir gestern nochmals eine weitere Stunde(!) Zeit genommen und ich muss nach wie vor feststellen: keine Chance, so etwas in einer Viertelstunde zu verstehen. Wer's immer noch nicht glaubt, der soll mir sagen wie man alleine aufgrund der OSM-Wiki-Seite und maximal einer Liste von Weblinks dort (wenn es sie denn gäbe), herauslesen kann wie man Tag TMC:cid_58:tabcd_1:LocationCode (mit Wert 52864) interpretiert! * Wo steht, dass CID ein Field ist? Was haben Fields in Tag-Namen überhaupt zu suchen? Was ist die Country-ID z.B. für Norwegen? * Warum braucht es tabcd_1? Woher weiss man, dass es nur die gibt und man nicht mit tabcd_99 rechen muss? * etc. ... der Tag und die von mir zitieren Sätze stehen dabei nur exemplarisch da. Ich bin mit dir einverstanden, dass es schön wäre, wenn man auch eine Anleitung hätte, wie Mapper mit diesen Tags umzugehen haben oder wie man damit eigene Software schreibt. Aber ich muss es nochmals sagen: Zurzeit kann kaum einer das TMC-Tag-Schema verstehen, so wie es aktuell beschrieben ist. == Genau dies ist aber für mich eine klare Vorbedingung, um Daten in OSM einzubetten, die grösserem Stil eingepflegt werden sollen. == Ein Tagging Schema muss u.a. verständlich, zugänglich und nach den Regeln der Kunst verfasst sein. Unter verständlich verstehe ich, dass das Wichtigste erläutert ist, um das Prinzip des Schemas zu verstehen. Und unter zugänglich verstehe ich, ausgehend von einer OSM-Wiki-Seite (also http://wiki.openstreetmap.org/wiki/Key:TMC, die nicht wie aktuell zum Teil-Tag LocationCode weitergeleitet wird). Die Regeln der Kunst sind in OSM etwas schwieriger zu definieren :- Unterlagen zu TMC findet man nur spärlich: Kaum Event Lists und Location Tables Das Wenige, das ich gefunden habe, waren Specs. zum TMC-ExchangeFormat und zur ISO_14819-2:2003 sowie als Einstieg http://www.tm.tfh-wildau.de/~sbruntha/wiki/index.php/RDS-TMC - obwohl auch da das Konzeptionelle fehlt. Und wer sich mal wirklich die Zähne ausbeissen will, dem seien einzigen TMC-Daten verraten, die ich nach erwähnter Stunde im Web gefunden habe: http://www.vegvesen.no/en/Professional/Technology/RDS+TMC . Für den Link für deutsche Daten auf www.bast.de muss man sein Email preisgeben und wohl warten... (da kommt ein Bestellformular). Auf http://wiki.openstreetmap.org/wiki/Key:TMC sollte m.E. zuerst das Konzept erläutert werden. Das beginnt mit einer Aussage, dass es sich um ein topologisches Netz mit linearem Bezugssystem handelt und dass man trennen soll zwischen TMC-Geometrien (um die es hier geht) und RDS-TMC-Meldungen. Dann könnten die Tags erläutert werden - wenn sie denn nach den Regeln der Kunst modelliert, bzw. codiert wären. Dann Beispiele etc. Hier erste Überlegungen am aktuellen Beispiel Tag TMC:cid_58:tabcd_1:LocationCode=52864): Dieser Tag ist kein selbstdokumentierender Name und der Doppelpunkt in Tags ist für Prefix reserviert. Weitere Doppelpunkte in Tags verwirren Mensch und Maschine. = Daher könnte z.B. folgendes etwas sinniger sein: tmc:locationcode=countryid_58:tablecode_1:52864. Das ist jetzt erst ein erster Vorschlag und ich würde sehr gerne weiter mithelfen, doch ist mir eine weitere Frage aufgefallen, die uns wieder zur Relevanzdiskussion zurückführt: = Wollen wir innerhalb in OSM wirklich eine weitere, überlagernde Knoten-Kanten-Topologie - wie dies die TMC-Daten darstellen - pflegen, je mit eigenen Tags (in TMC: TYPES) wie Water area;Urban street;... und Untertags(??) (in TMC: SUBTYPES) wie Motorway;Ring motorway;...? = Entspricht TMC den Eignungskriterien (http://wiki.openstreetmap.org/wiki/DE:Nutzung_von_OSM_durch_FIS)? Ich bin nun nach wie vor etwas unentschlossen. Sollen wir nun: * So etwas schweren Herzens (und mit Begründung) ganz missbilligen? * Nur ein Teil davon, d.h. die IDs in OSM verwalten - z.B. die LocationCodes (Points) an Nodes? * Oder alles dies in OSM gutheissen (denn zwei, drei melden sich immer, die so etwas gut finden)? LG, S. Am 5. Februar 2011 10:28 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Am 05.02.2011 02:22, schrieb Stefan Keller: Also so können wir den Relevanz-Thread nicht stehen lassen: Habe mal versucht mich ins Schema einzuarbeiten und muss jetzt sagen, dass dieses TMC ein Negativbeispiel ist - so wie die Tags daherkommen und wie sie (nicht) erklärt sind. Bereits beim erst besten Tag, z.B. TMC:LocationCode steht auf http://wiki.openstreetmap.org/wiki/Key:TMC:LocationCode Man betrachte mal dort den Satz (CID) is replaced by the country-id (e.f. 58 for Germany): Was ist e.f.? Was ist (CID)? Auf was bezieht sich das? (aha rechts steht da etwas kryptisches TMC:cid_(CID):tabcd_(TABCD):LocationCode). Dann wird die Erklärung von CID zwei Sätze weiter unten
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Hi, Stefan Keller wrote: = Daher könnte z.B. folgendes etwas sinniger sein: tmc:locationcode=countryid_58:tablecode_1:52864. Ich denke, man koennte auch den Mut zur Luecke haben und einfach nur tmc_location_code=52864 schreiben oder so. Ok, man kriegt damit keine laenderuebergreifenden Meldungen abgebildet, aber kommen die so oft vor? Ebenso mit dieser table (ulkigerweise dachte ich anfangs wegen tabcd immer, das waere ein Beispielwert, a-b-c-d...) - wenn es wirklich mal zu dem unwahrscheinlichen Fall kommt, dass wir zwei Tables parallel in OSM abbilden muessen, kann man das Problem *dann* loesen. (Es entspricht nicht der Tradition von OSM, ein komplexes Modell aufzubauen fuer Zeugs, das noch gar nicht gebraucht wird und bei dem unklar ist, ob es ueberhaupt jemals gebraucht wird - man macht erstmal was einfaches und kann das dann spaeter immer noch erweitern.) Ich bin nun nach wie vor etwas unentschlossen. Sollen wir nun: * So etwas schweren Herzens (und mit Begründung) ganz missbilligen? * Nur ein Teil davon, d.h. die IDs in OSM verwalten - z.B. die LocationCodes (Points) an Nodes? * Oder alles dies in OSM gutheissen (denn zwei, drei melden sich immer, die so etwas gut finden)? Zwischen missbilligen und gutheissen gibt es ja auch noch tolerieren - so nach dem Motto, das ist zwar Murks, und eigentlich ist das auch jedem klar, aber wir haben grad nichts besseres. Also ich koennte mir durchaus vorstellen, dass es gelingt, den groessten Teil des TMC-OSM-Matchings komplett extern zu machen, so dass man den gewuenschten Nutzen auch erzielen kann, ohne dass TMC-Tags in OSM sind. Wenn sich rausstellt, dass das weitgehend (aber nicht 100%) geht, dann koennte man sich ja eventuell darauf beschraenken, an den Stellen, wo es nicht automatisch geht, zu taggen. Und wenn es gar nicht geht, dann muss halt irgendwas in OSM drin bleiben - aber eine Nachbildung des externen Graphen in OSM halte ich, wie mehrfach gesagt, fuer falsch. Eventuell ist das gemacht worden, weil es so schwierig ist, an die Originaldaten heranzukommen (Du schriebst, man muesse erst ein Bestellformular ausfuellen?). 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] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Betreffend Location Table und Event List schrieb Frederik : (Du schriebst, man muesse erst ein Bestellformular ausfuellen?) Einzig wie gesagt Norwegen habe ich gefunden. Für Deutschland: http://www.bast.de/cln_007/nn_213316/DE/Aufgaben/abteilung-f/referat-f4/Location-Code-List/location-code-list-nutzungsbedingungen.html In der Schweiz sind die Daten ziemlich sicher der Viasuisse vorbehalten, wobei man schauen könnte, ob sich die D-AC-H-Daten nicht hinter dem Tool der Schweizer Firma Geologix herausholen lassen: http://www.geologix.ch/website.php?nav=,products,E,10 (ebenfalls auf Bestellung :-), Bei Österreich habe ich nichts mehr herausgefunden ausser wer zuständig wäre: http://de.wikipedia.org/wiki/Traffic_Message_Channel#.C3.96sterreich LG, S. Am 7. Februar 2011 01:21 schrieb Frederik Ramm frede...@remote.org: Hi, Stefan Keller wrote: = Daher könnte z.B. folgendes etwas sinniger sein: tmc:locationcode=countryid_58:tablecode_1:52864. Ich denke, man koennte auch den Mut zur Luecke haben und einfach nur tmc_location_code=52864 schreiben oder so. Ok, man kriegt damit keine laenderuebergreifenden Meldungen abgebildet, aber kommen die so oft vor? Ebenso mit dieser table (ulkigerweise dachte ich anfangs wegen tabcd immer, das waere ein Beispielwert, a-b-c-d...) - wenn es wirklich mal zu dem unwahrscheinlichen Fall kommt, dass wir zwei Tables parallel in OSM abbilden muessen, kann man das Problem *dann* loesen. (Es entspricht nicht der Tradition von OSM, ein komplexes Modell aufzubauen fuer Zeugs, das noch gar nicht gebraucht wird und bei dem unklar ist, ob es ueberhaupt jemals gebraucht wird - man macht erstmal was einfaches und kann das dann spaeter immer noch erweitern.) Ich bin nun nach wie vor etwas unentschlossen. Sollen wir nun: * So etwas schweren Herzens (und mit Begründung) ganz missbilligen? * Nur ein Teil davon, d.h. die IDs in OSM verwalten - z.B. die LocationCodes (Points) an Nodes? * Oder alles dies in OSM gutheissen (denn zwei, drei melden sich immer, die so etwas gut finden)? Zwischen missbilligen und gutheissen gibt es ja auch noch tolerieren - so nach dem Motto, das ist zwar Murks, und eigentlich ist das auch jedem klar, aber wir haben grad nichts besseres. Also ich koennte mir durchaus vorstellen, dass es gelingt, den groessten Teil des TMC-OSM-Matchings komplett extern zu machen, so dass man den gewuenschten Nutzen auch erzielen kann, ohne dass TMC-Tags in OSM sind. Wenn sich rausstellt, dass das weitgehend (aber nicht 100%) geht, dann koennte man sich ja eventuell darauf beschraenken, an den Stellen, wo es nicht automatisch geht, zu taggen. Und wenn es gar nicht geht, dann muss halt irgendwas in OSM drin bleiben - aber eine Nachbildung des externen Graphen in OSM halte ich, wie mehrfach gesagt, fuer falsch. Eventuell ist das gemacht worden, weil es so schwierig ist, an die Originaldaten heranzukommen (Du schriebst, man muesse erst ein Bestellformular ausfuellen?). 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 07.02.2011 00:40, schrieb Stefan Keller: Ich habe mir gestern nochmals eine weitere Stunde(!) Zeit genommen und ich muss nach wie vor feststellen: keine Chance, so etwas in einer Viertelstunde zu verstehen. Wer's immer noch nicht glaubt, der soll mir sagen wie man alleine aufgrund der OSM-Wiki-Seite und maximal einer Liste von Weblinks dort (wenn es sie denn gäbe), herauslesen kann wie man Tag TMC:cid_58:tabcd_1:LocationCode (mit Wert 52864) interpretiert! * Wo steht, dass CID ein Field ist? Was haben Fields in Tag-Namen überhaupt zu suchen? Was ist die Country-ID z.B. für Norwegen? * Warum braucht es tabcd_1? Woher weiss man, dass es nur die gibt und man nicht mit tabcd_99 rechen muss? * etc. ... der Tag und die von mir zitieren Sätze stehen dabei nur exemplarisch da. http://wiki.openstreetmap.org/wiki/Key:TMC:LocationCode * (CID) is replaced by the country-id (e.g. 58 for Germany) * (TABCD) is replaced by the table-code (e.g. 1 for the only table of Germany). Wenn ich also z.B. einen Node finde mit dem Tag: TMC:cid_58:tabcd_1:LocationCode = 52864 Wird das wohl bedeuten: Dieser Node entspricht der ersten TMC Tabelle von Deutschland und hat dort den Wert 52864. Im Zweifel aber bitte die TMC Profis fragen. Ich bin mit dir einverstanden, dass es schön wäre, wenn man auch eine Anleitung hätte, wie Mapper mit diesen Tags umzugehen haben oder wie man damit eigene Software schreibt. Aber ich muss es nochmals sagen: Zurzeit kann kaum einer das TMC-Tag-Schema verstehen, so wie es aktuell beschrieben ist. Wenn man die Doku nicht verstehen will, dann hat man klar ein Problem damit. Nachfragen wäre vielleicht eine mögliche Lösung gewesen. == Genau dies ist aber für mich eine klare Vorbedingung, um Daten in OSM einzubetten, die grösserem Stil eingepflegt werden sollen.== Ein Tagging Schema muss u.a. verständlich, zugänglich und nach den Regeln der Kunst verfasst sein. Bitte nicht die Wörter muss und sollte verwechseln. Prima, dann schmeissen wir die ÖPNV Daten demnächst alle wieder raus. DAS Schema ist nämlich auch kaum zu verstehen und das davon 2-3 Varianten im Wiki stehen macht die Sachen noch schlimmer. Unterlagen zu TMC findet man nur spärlich: Kaum Event Lists und Location Tables Das Wenige, das ich gefunden habe, waren Specs. zum TMC-ExchangeFormat und zur ISO_14819-2:2003 sowie als Einstieg http://www.tm.tfh-wildau.de/~sbruntha/wiki/index.php/RDS-TMC - obwohl auch da das Konzeptionelle fehlt. Und wer sich mal wirklich die Zähne ausbeissen will, dem seien einzigen TMC-Daten verraten, die ich nach erwähnter Stunde im Web gefunden habe: http://www.vegvesen.no/en/Professional/Technology/RDS+TMC . Für den Link für deutsche Daten auf www.bast.de muss man sein Email preisgeben und wohl warten... (da kommt ein Bestellformular). Das allgemein so wenig Literatur und fast keine Daten zum Thema TMC vorhanden ist, ist jetzt natürlich auch den Autoren der Wikiseiten anzulasten?!? Auf http://wiki.openstreetmap.org/wiki/Key:TMC sollte m.E. zuerst das Konzept erläutert werden. Das beginnt mit einer Aussage, dass es sich um ein topologisches Netz mit linearem Bezugssystem handelt ... und hier wird mir klar, warum mir die Leute lieber sind, die sowas bei OSM einfach voran bringen und nicht wie hier anderen vorschreiben was diese tun sollten. Das diese Leute dann lieber erstmal einen Versuch starten und nicht erst ein Buch über TMC schreiben wollen kann ich gut verstehen, so sind übrigens bei OSM sehr viele Dinge entstanden. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Hallo, Ulf Lamping wrote: Prima, dann schmeissen wir die ÖPNV Daten demnächst alle wieder raus. DAS Schema ist nämlich auch kaum zu verstehen und das davon 2-3 Varianten im Wiki stehen macht die Sachen noch schlimmer. Das lese ich jetzt zum wiederholten Mal. Das ist aber kein Argument, oder genauer: Es ist tatsaechlich ein Argument, aber maximal eines fuer die Entfernung von OePNV-Daten und nicht eins fuer die Erhaltung von TMC. Ausserdem liegt dem Argument die Annahme zugrunde, das es allgemeingueltige Kriterien gaebe, die einzelne Themen in ihrer Relevanz vergleichbar machen (wenn wir X erlauben, muessen wir auch Y erlauben, wenn wir A rauswerfen, muessen wir auch B rauswerfen). Ich moechte darauf hinweisen, dass ich weder behauptet noch gefordert habe, dass es solche Kritierien gibt - ich habe nur auf die m.E. bestehenden Nachteile beim TMC-Tagging hingewiesen, und andere haben das zu einer Relevanzdiskussion aufgebauscht, weil sie annahmen, dass man nicht ueber einen konkreten Fall diskutieren kann, ohne ein allgemeines Regelwerk im Hintergrund zu haben. Ich hingegen habe kein Problem damit. 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] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 07.02.2011 01:21, schrieb Frederik Ramm: Hi, Stefan Keller wrote: = Daher könnte z.B. folgendes etwas sinniger sein: tmc:locationcode=countryid_58:tablecode_1:52864. Ich denke, man koennte auch den Mut zur Luecke haben und einfach nur tmc_location_code=52864 schreiben oder so. Ok, man kriegt damit keine laenderuebergreifenden Meldungen abgebildet, aber kommen die so oft vor? Frag mal die Leute in Trier, die können dir da ein Lied von singen ;-) Ebenso mit dieser table (ulkigerweise dachte ich anfangs wegen tabcd immer, das waere ein Beispielwert, a-b-c-d...) - wenn es wirklich mal zu dem unwahrscheinlichen Fall kommt, dass wir zwei Tables parallel in OSM abbilden muessen, kann man das Problem *dann* loesen. (Es entspricht nicht der Tradition von OSM, ein komplexes Modell aufzubauen fuer Zeugs, das noch gar nicht gebraucht wird und bei dem unklar ist, ob es ueberhaupt jemals gebraucht wird - man macht erstmal was einfaches und kann das dann spaeter immer noch erweitern.) Ich glaube nicht das dies der wirklich kritische Punkt ist. Also ich koennte mir durchaus vorstellen, dass es gelingt, den groessten Teil des TMC-OSM-Matchings komplett extern zu machen, so dass man den gewuenschten Nutzen auch erzielen kann, ohne dass TMC-Tags in OSM sind. Über das Problem sinnvoll eine externe DB mit unserer zu verzahnen, also mit Minimum an manuellem Aufwand und benutzbar für Datenanwender, hatten wir doch schon häufiger gesprochen und bislang m.W. noch keine wirklich brauchbare Lösung gefunden. Du kennst das Bild mit dem und hier geschieht ein Wunder Kasten kurz vor der Fertigstellung? http://www.ethikpartei.ch/miracle1.jpg Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 05.02.2011 02:22, schrieb Stefan Keller: Also so können wir den Relevanz-Thread nicht stehen lassen: Habe mal versucht mich ins Schema einzuarbeiten und muss jetzt sagen, dass dieses TMC ein Negativbeispiel ist - so wie die Tags daherkommen und wie sie (nicht) erklärt sind. Bereits beim erst besten Tag, z.B. TMC:LocationCode steht auf http://wiki.openstreetmap.org/wiki/Key:TMC:LocationCode Man betrachte mal dort den Satz (CID) is replaced by the country-id (e.f. 58 for Germany): Was ist e.f.? Was ist (CID)? Auf was bezieht sich das? (aha rechts steht da etwas kryptisches TMC:cid_(CID):tabcd_(TABCD):LocationCode). Dann wird die Erklärung von CID zwei Sätze weiter unten gleich wieder abgeschwächt: Note: the unique CID(e.g. 58) used here is not the transmitted but a non-unique CCID(e.g. 0xD) and mapped to the CID via COUNTRIES.DAT of the LCL.. Man lasse sich diesen Satz durch die Zunge gehen... Dann diese Aneinanderreihung von Doppelpunkten... Keine Chance das zu verstehen - Das die Beschreibung verbessert werden kann, ist bei OSM selten die Frage ;-) Die Art, wie du hier über die Beschreibung herziehst, zeigt aber eher dein Unverständnis beim Lesen einer eher technischen Dokumentation (was ein System wie TMC nun mal ist). Ob wir hier eher eine andere Art von Beschreibung brauchen steht allerdings auf einem anderen Blatt. Der allererste Satz auf der Seite lautet: This key is used to add the TMC location-code to a map-element TMC/TMC_Import_Germany#Tagging_Schema. ... mit einem Link auf dieses Tagging Schema. Erstmal dort die Einleitung zu lesen hilft wirklich weiter (beantwortet aber auch nicht alles). Der Satz: (CID) is replaced by the country-id (e.f. 58 for Germany) legt nahe, daß hier schlicht ein Tippfehler ist und es besser: (CID) is replaced by the country-id (e.g. 58 for Germany) heissen sollte (hab's korrigiert). Aus diesem Satz kann man schon gut herauslesen, daß CID dann wohl eine Abkürzung für country-id sein dürfte und 58 dabei der Wert ist, der Deutschland repräsentiert. Die Beschreibung ist allerdings aus anderen Gründen unzureichend. Ich kann herauslesen wie die Tags zustandekommen. Damit kann ich aber weder meine eigene TMC Software schreiben (die Abbildung der TMC Empfangsdaten auf die Tags bleibt unklar) - was allerdings auch nicht unbedingt hier stehen muß. Auch ist es keine gute Anleitung wie ein Mapper mit diesen Tags umzugehen hat. Das Problem haben wir aber auch bei vielen anderen Tag Beschreibungen. auch mit den Links unten nicht: 4 von 5 auf der deutschen und englischen TMC-Seite sind tot... Ich habe hier nicht einen roten Link?!? Man könnte sicher hier und da Sachen vereinfachen, aber so krass wie du es darstellst ist es nun auch nicht ... Gruß, ULFL P.S: Das die Beschreibung etwas kryptisch ist, liegt sicher auch daran, das bislang kaum einer danach gefragt hat. Ich kann mich zumindest nicht dran erinnern, daß hier vorher schonmal solche Fragen wie deine gefragt wurden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 04.02.2011 00:28, schrieb Stefan Keller: Daher meine Gretchenfrage an die TMC-Befürworter: = Dürfen alle - auch wir Nicht-Bots (:-) - TMC-Daten erfassen und verändern? = Wie flüchtig sind TMC-in-OSM-Daten? TMC-Daten haben über längere Zeit bestand - es geht ja nicht um die Verkehrsmeldung an sich sondern um die Geo-Referenzierungsdaten auf die sich dann die ausgestrahlten TMC-Verkehrsdaten beziehen. DIe TMC-(Geo)Daten werden ja in den Empfangsgeräte (Werksnavis in den Autos) fest abgelegt und bleiben dort teilweise über Jahre unverändert. Vorhandene Daten können daher nicht ständig verändert werden. Und an alle: Wie flüchtig dürfen OSM-Daten sein? Eine Woche? Ein Tag? Zwei Stunden? Kommt darauf an...Aufbauten für eine Massen-Veranstaltung kann man sicher auch mal eintragen (z.B: Budenaufbau auf einer Festwiese) wenn sie danach wieder gleich entfernt werden. Allles im Tagerbereich macht allerdings wenig Sinn. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 03.02.2011 23:49, schrieb M∡rtin Koppenhoefer: Am 3. Februar 2011 23:03 schrieb Tobias Knerro...@tobias-knerr.de: Ein eher harmloser Fall: Ein Knoten an der Einmündung in einen Platz, der als Ampel getaggt ist und mehrere TMC-Tags trägt. Die Ampel ist allerdings so nicht ganz richtig, denn es gibt keine zwei separaten Ampelanlagen an den Enden des Platzes, sondern nur einen einzigen (sehr breiten) Fußgängerüberweg. Eventuell werde ich diese Ampel also irgendwann löschen wollen. ... das ist eigentlich kein Problem, wenn Du nur die Ampel löschen willst, dann reicht es ja, highway=traffic_lights zu entfernen. Um die TMC-tags brauchst Du Dich nicht zu kümmern. ...nach der Diskussion hier oder mit dem Wissen, was GENAU TMC ist, ja. Vorher könnte TMC auch eine Eigenschaft der Ampel sein. Aber ich gebe zu, dass die tags nicht direkt schön sind. Angerührt habe ich die bisher auch noch nicht. Gruß Martin ___ 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] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 4. Februar 2011 09:47 schrieb Peter Wendorff wendo...@uni-paderborn.de: das ist eigentlich kein Problem, wenn Du nur die Ampel löschen willst, dann reicht es ja, highway=traffic_lights zu entfernen. Um die TMC-tags brauchst Du Dich nicht zu kümmern. ...nach der Diskussion hier oder mit dem Wissen, was GENAU TMC ist, ja. Vorher könnte TMC auch eine Eigenschaft der Ampel sein. ja, ich habe kurz daran gedacht (Tobias hatte das ja angedeutet), aber wenn man einen tag nicht kennt, kann man ja auch kurz mal nachsehen, z.B. http://www.google.com/search?client=ubuntuchannel=fsq=TMC http://de.wikipedia.org/wiki/TMC http://wiki.openstreetmap.org/wiki/TMC abgesehen davon, dass TMC im Bereich Navigation und im Bereich OSM den allermeisten bekannt sein dürfte. Es gibt sehr viele Tags und Relationen, die komplizierter und nichtssagender sind als TMS meiner Meinung nach. Wie schon geschrieben: falls das aktuelle Schema nicht optimal ist, kann man das gerne optimieren (und z.B. leslicher gestalten, weniger/andere Abkürzungen und Ländercodes, andere Modellierung, etc.), aber bitte nicht einfach löschen (was für alle Tags gelten sollte, die man nicht kennt oder vesteht). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Also so können wir den Relevanz-Thread nicht stehen lassen: Habe mal versucht mich ins Schema einzuarbeiten und muss jetzt sagen, dass dieses TMC ein Negativbeispiel ist - so wie die Tags daherkommen und wie sie (nicht) erklärt sind. Bereits beim erst besten Tag, z.B. TMC:LocationCode steht auf http://wiki.openstreetmap.org/wiki/Key:TMC:LocationCode Man betrachte mal dort den Satz (CID) is replaced by the country-id (e.f. 58 for Germany): Was ist e.f.? Was ist (CID)? Auf was bezieht sich das? (aha rechts steht da etwas kryptisches TMC:cid_(CID):tabcd_(TABCD):LocationCode). Dann wird die Erklärung von CID zwei Sätze weiter unten gleich wieder abgeschwächt: Note: the unique CID(e.g. 58) used here is not the transmitted but a non-unique CCID(e.g. 0xD) and mapped to the CID via COUNTRIES.DAT of the LCL.. Man lasse sich diesen Satz durch die Zunge gehen... Dann diese Aneinanderreihung von Doppelpunkten... Keine Chance das zu verstehen - auch mit den Links unten nicht: 4 von 5 auf der deutschen und englischen TMC-Seite sind tot... Ich sehe effektiv auch keinen Ansatz, das zu verbessern ausser einem kompletten Neuentwurf (und die Verbesserung muss von denjenigen kommen, die das TMC im OSM wollen). Wenn diese TMC-Tags so bleiben wie sie jetzt sind, dann fragt sich schon, ob das Sinn macht in OSM. Wenn man zu einem Tag - ausgehend von der OSM-Wiki Seite - auch nach längerem Recherchieren nicht herausfindet, was er bedeutet - geschweige denn wie man einen ändert, dann sehe ich kaum einen Unterschied dazu, Binhexdaten oder Geheimdienst-Botschaften zuzulassen. Wenn sich Frederik ursprünglich über die kryptischen Uploads ärgerte, dann ärgern mich solche kryptischen Spezifikationen (aber ich bin nicht nachtragend ;-). Und bitte versteht mich nicht falsch: Ich möchte ich ja so Fachinformationen fördern... LG, S. Am 4. Februar 2011 12:08 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 4. Februar 2011 09:47 schrieb Peter Wendorff wendo...@uni-paderborn.de: das ist eigentlich kein Problem, wenn Du nur die Ampel löschen willst, dann reicht es ja, highway=traffic_lights zu entfernen. Um die TMC-tags brauchst Du Dich nicht zu kümmern. ...nach der Diskussion hier oder mit dem Wissen, was GENAU TMC ist, ja. Vorher könnte TMC auch eine Eigenschaft der Ampel sein. ja, ich habe kurz daran gedacht (Tobias hatte das ja angedeutet), aber wenn man einen tag nicht kennt, kann man ja auch kurz mal nachsehen, z.B. http://www.google.com/search?client=ubuntuchannel=fsq=TMC http://de.wikipedia.org/wiki/TMC http://wiki.openstreetmap.org/wiki/TMC abgesehen davon, dass TMC im Bereich Navigation und im Bereich OSM den allermeisten bekannt sein dürfte. Es gibt sehr viele Tags und Relationen, die komplizierter und nichtssagender sind als TMS meiner Meinung nach. Wie schon geschrieben: falls das aktuelle Schema nicht optimal ist, kann man das gerne optimieren (und z.B. leslicher gestalten, weniger/andere Abkürzungen und Ländercodes, andere Modellierung, etc.), aber bitte nicht einfach löschen (was für alle Tags gelten sollte, die man nicht kennt oder vesteht). Gruß Martin ___ 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
[Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 03.02.2011 16:10, schrieb Frederik Ramm: 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. Ja, aber ich mappe doch nicht für den Tileserver. Ich erinnere mich an eine Diskussion mit Sven Sommerkamp, der mir verbieten wollte straßenbegleitende Radwege in OSM als extra Way anzulegen, weil ansonsten sein Garmin nicht mehr in Hamburg routen konnte[1]. Das kann doch kein ernst zu nehmendes Argument sein. Ich will jetzt nicht die Dikssion über straßenbegleitende Radwege weider aufwecken. Ich finde die Diskussion hat ähnlichen Character. Die Wheelmap-Leute haben einen echten Mehrwert, wenn sie wissen, ob ein Fahrstuhl funktioniert, okay ist nicht die Telefonzelle, aber genau so eine Information. Mache Fahrstühle gehen in Hamburg über 6 Monate nicht. Da ist dann überhaupt die Frage ob man den Fahrstuhl nicht löschen sollte. 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. Und jeder kann eigene Vorgelbeobachtungen hinzufügen und man kann es gemeinsam auswerten. Ist doch prima. Ich finde daran erstmal nichts inkompetent. Und Faulheit ist doch auch gut, ich bin gerne Faul. Ich hab gerade den Eindruck das du dich zuviel um Tileserver/OSM verarbeitende Jobs kümmerst und deshalb dich das Ansteigen der OSM-Daten nervt, das kann ich gut verstehen, der osm-tmc Validator läuft auch nicht rund, weil ich mit dem Umschreiben der Programme die das Erzugen nicht hinterher komme und die Daten so stark wachsen. Ich finde aber gerade das es eine Stärke von OSM ist solche Daten hinzu zu fügen. Wir sind eine Geodatenbank für fast alles das bedeutet, das wir natürlich auch viel Nischenkram drinn haben. Ich hab bislang für OSM damit geworben, das mein bei uns auch Nischenkram (DSL-Anschlußkästen,Hundekottütenspender etc.) verarbeiten kann. Gibt es hier noch andere Stellungnahmen zum Thema Relevanz in OSM? Was soll in unsere Datenbank und was nicht? Gruß Sven [1] http://lists.openstreetmap.org/pipermail/talk-de/2009-May/046344.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Habe wie schon an anderer Stelle erwähnt, extra dazu eine Wiki-Seite eröffnet: http://wiki.openstreetmap.org/wiki/DE:Nutzung_von_OSM_durch_FIS ! Manchmal ist es auch nützlich, gute Beispiele anzuführen: Gibt es solche? LG, S. Am 3. Februar 2011 17:23 schrieb Sven Anders s...@anders-hamburg.de: Am 03.02.2011 16:10, schrieb Frederik Ramm: 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. Ja, aber ich mappe doch nicht für den Tileserver. Ich erinnere mich an eine Diskussion mit Sven Sommerkamp, der mir verbieten wollte straßenbegleitende Radwege in OSM als extra Way anzulegen, weil ansonsten sein Garmin nicht mehr in Hamburg routen konnte[1]. Das kann doch kein ernst zu nehmendes Argument sein. Ich will jetzt nicht die Dikssion über straßenbegleitende Radwege weider aufwecken. Ich finde die Diskussion hat ähnlichen Character. Die Wheelmap-Leute haben einen echten Mehrwert, wenn sie wissen, ob ein Fahrstuhl funktioniert, okay ist nicht die Telefonzelle, aber genau so eine Information. Mache Fahrstühle gehen in Hamburg über 6 Monate nicht. Da ist dann überhaupt die Frage ob man den Fahrstuhl nicht löschen sollte. 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. Und jeder kann eigene Vorgelbeobachtungen hinzufügen und man kann es gemeinsam auswerten. Ist doch prima. Ich finde daran erstmal nichts inkompetent. Und Faulheit ist doch auch gut, ich bin gerne Faul. Ich hab gerade den Eindruck das du dich zuviel um Tileserver/OSM verarbeitende Jobs kümmerst und deshalb dich das Ansteigen der OSM-Daten nervt, das kann ich gut verstehen, der osm-tmc Validator läuft auch nicht rund, weil ich mit dem Umschreiben der Programme die das Erzugen nicht hinterher komme und die Daten so stark wachsen. Ich finde aber gerade das es eine Stärke von OSM ist solche Daten hinzu zu fügen. Wir sind eine Geodatenbank für fast alles das bedeutet, das wir natürlich auch viel Nischenkram drinn haben. Ich hab bislang für OSM damit geworben, das mein bei uns auch Nischenkram (DSL-Anschlußkästen,Hundekottütenspender etc.) verarbeiten kann. Gibt es hier noch andere Stellungnahmen zum Thema Relevanz in OSM? Was soll in unsere Datenbank und was nicht? Gruß Sven [1] http://lists.openstreetmap.org/pipermail/talk-de/2009-May/046344.html ___ 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] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 03.02.2011 17:23, schrieb Sven Anders: ... Prinzipiell bin ich deiner Meinung, dass alles hinein darf. Die Frage ist immer nur wie. Wichtig ist mir, dass man es Filtern kann. Daher sollte sich alles in bestimmten Namensräumen befinden und nicht bisherige Nutzung erschweren. Weiterhin sollten sich die Infos bzw. das Schema auf das beschränken, was man zur Auswertung braucht. Meiner Meinung nach sind detailierte Infos in externen (aber gekoppelten) DB's besser aufgehoben. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Hallo, Sven Anders wrote: Ich erinnere mich an eine Diskussion mit Sven Sommerkamp, der mir verbieten wollte straßenbegleitende Radwege in OSM als extra Way anzulegen, weil ansonsten sein Garmin nicht mehr in Hamburg routen konnte[1]. Das kann doch kein ernst zu nehmendes Argument sein. Ich will jetzt nicht die Dikssion über straßenbegleitende Radwege weider aufwecken. Ich finde die Diskussion hat ähnlichen Character. Ich finde, es geht um etwas grundsaetzlich verschiedenes. Die Wheelmap-Leute haben einen echten Mehrwert, wenn sie wissen, ob ein Fahrstuhl funktioniert, okay ist nicht die Telefonzelle, aber genau so eine Information. Mache Fahrstühle gehen in Hamburg über 6 Monate nicht. Da ist dann überhaupt die Frage ob man den Fahrstuhl nicht löschen sollte. Im Idealfall gibt es eine externe Datenbank mit Informationen zu Fahrstuehlen - z.B. vom Fahrstuhlbetreiber -, der man entnehmen kann, ob ein Fahrstuhl gerade geht oder nicht, wann die naechste Wartung geplant ist, welches die Notfallrufnummer fuer diesen Fahrstuhl ist und so weiter. Haben wir vielleicht heute noch nicht, aber Open Government ist in aller Munde, und solche Sachen wird es mehr und mehr geben. Dann wuensche ich mir eine halbwegs verlaessliche Art - unter Umstaenden mit einem Tag, der auf die Aufzug-ID in der betr. Datenbank verweist -, wie man OSM-Daten und die nicht-OSM-Welt verknuepfen kann. Dass man solche Daten *in* OSM direkt erfasst, das kann man als Notloesung machen, solange es noch keine solche frei zugaengliche Aufzugsdatenbank gibt. Du aber hoerst Dich gerade so an, als ob Du selbst dann, wenn eine solche Datenbank verfuegbar waere, lieber einen Bot schriebest, der einmal pro Stunde den Aufzugsstatus aus der Datenbank abfragt und ihn in OSM aktualisiert - nach dem Motto ist doch praktisch. OSM kann und will aber nicht der Sammelpott fuer alle irgendwo frei erhaeltlichen Daten sein - dafuer gibt es einfach zu viel davon, und ich bin bei weitem nicht der einzige, der jede Art von Import kritisch beaeugt. 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. Und jeder kann eigene Vorgelbeobachtungen hinzufügen und man kann es gemeinsam auswerten. Ist doch prima. Ich finde daran erstmal nichts inkompetent. Und Faulheit ist doch auch gut, ich bin gerne Faul. Es gibt freie Datensaetze aller Art, z.B. mit Temperaturentwicklungen oder so, die ganz OSM vom Datenvolumen her locker in den Schatten stellen. Wenn Du moechtest, starte ich mal ein kleines historisches Wetterprojekt in Hamburg, und weil ich gerne faul bin und es zugleich doch spitze ist, wenn andere auch an diese Wetterdaten herankommen, lade ich die gleich zu OSM hoch. Jeder Download, den Du von da an in Hamburg machst, ist 4x so gross wie vorher, die Tiles rendern gar nicht mehr und im Editor siehst Du nur noch Wettermesspunkte ;) also im Ernst, da muss man schon ein bisschen auf dem Boden bleiben, und sowas muss ganz klar extern mit OSM verknuepft statt in OSM hineingekippt werden. Wir fuehren normalerweise keine Relevanzdiskussion, weil die meisten von uns sich einig sind, dass alles, was Menschen vor Ort selber mappen, auch einen Platz in OSM hat. Auch das Vogelhaeuschen. Das koennen wir uns leisten - ein einzelner Mensch kann nur eine begrenzte Menge an Unsinn selber mappen, also brauchen wir uns nicht um die Definition zu pruegeln, was Unsinn ist und was nicht. Aber das heisst nicht, dass wir jedem erlauben koennen, alles zu importieren - denn da kann man mehr Unsinn machen. (Konkret an den TMC-Tags hat mich aber nicht die Menge an sich gestoert, sondern, dass sie die Huerde fuer Mapper m.E. unnoetig erhoehen, wie ich hoffe, im vorigen Posting dargelegt zu haben.) Ich hab gerade den Eindruck das du dich zuviel um Tileserver/OSM verarbeitende Jobs kümmerst und deshalb dich das Ansteigen der OSM-Daten nervt Nein; wenn das mein Grund gewesen waere, dann haette ich das auch gesagt und nicht irgendwelche Ausreden erfunden. 175000 TMC-Tags - das sind insgesamt *halb so viele*, wie der OSM-Datenbank jeden Tag neu hinzugefuegt werden. Wenn ich jetzt alle TMC-Tags loesche, dann ist die Datenmenge nach 12 Stunden wieder so gross wie davor. Mein Hauptproblem mit TMC ist, dass ich diese Daten als invasiv empfinde; sie behindern in meinen Augen die Arbeit mit den Kerndaten. Das ist was andres als wenn jemand einen Hundekottuetenspender irgendwo hinmappt, finde ich. -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 03.02.2011 19:46, schrieb Frederik Ramm: Es gibt freie Datensaetze aller Art, z.B. mit Temperaturentwicklungen oder so, die ganz OSM vom Datenvolumen her locker in den Schatten stellen. Wenn Du moechtest, starte ich mal ein kleines historisches Wetterprojekt in Hamburg, und weil ich gerne faul bin und es zugleich doch spitze ist, wenn andere auch an diese Wetterdaten herankommen, lade ich die gleich zu OSM hoch. Jeder Download, den Du von da an in Hamburg machst, ist 4x so gross wie vorher, die Tiles rendern gar nicht mehr und im Editor siehst Du nur noch Wettermesspunkte ;) also im Ernst, da muss man schon ein bisschen auf dem Boden bleiben, und sowas muss ganz klar extern mit OSM verknuepft statt in OSM hineingekippt werden. (Konkret an den TMC-Tags hat mich aber nicht die Menge an sich gestoert, sondern, dass sie die Huerde fuer Mapper m.E. unnoetig erhoehen, wie ich hoffe, im vorigen Posting dargelegt zu haben.) Nodes mit TMC-Daten dürften überwiegend da zu finden sein wo die Daten in Bezug auf die Strassen schon relativ vollständig sind - nicht gerade der richtige Einstiegspunkt für Anfänger allgemein... Mein Hauptproblem mit TMC ist, dass ich diese Daten als invasiv empfinde; sie behindern in meinen Augen die Arbeit mit den Kerndaten. Das ist was andres als wenn jemand einen Hundekottuetenspender irgendwo hinmappt, finde ich. In meinen Augen sínd TMC-Daten Kerndaten die eine Datendienst-Mensch-Schnittstelle mit verfügbaren Zustands-Daten ermöglichen Schau Doch ab und zu mal wieder was OSM ausgeschrieben heisst... Impliziert das nicht gerade dass dort auch Daten zu finden sind die die Verbindung zwischen Mensch und Maschine im Strassenverkehr herstellen? Lange Zeit wurde ein grosses Geheimniss um die Daten gemacht, jetzt gibt es endlich die Möglichkeit frei an die Daten hernazukommen und Du willst sie wieder ausschliessen? Der Vergleich mit den Temperaturentwicklungen hinkt - die (insbesondere historischen) Temperaturwerte möchte man sicher nicht in OSM haben, deren Messpunkte würder aber vielleicht schon wieder Sinn machen... Jedenfalls enthalten die TMC-Daten ja keine eigentliche Verkehrsdaten sondern die Information wo diese abzubilden sind. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 03.02.2011 17:23, schrieb Sven Anders: Und Faulheit ist doch auch gut, ich bin gerne Faul. Ich auch. Deshalb mag ich die TMC-Tags nicht, machen nur Arbeit. ;) Man kann seine Sicht eben nicht nur auf den Aufwand für denjenigen einschränken, der den Import durchführt. Es wird von Mappern wie mir erwartet, dass sie sich die Mühe machen, bei ihren Bearbeitungen die (für sie evtl. absolut uninteressanten) TMC-Daten intakt zu halten. Im Gegenzug erwarte ich von den Betreibern des TMC-Imports, dass sie mir diese Aufgabe so einfach wie möglich machen. Diesem Teil des Handels wird das TMC-Schema nicht sehr gut gerecht. Es ist kompliziert und nicht laientauglich dokumentiert. Ich hab gerade den Eindruck das du dich zuviel um Tileserver/OSM verarbeitende Jobs kümmerst und deshalb dich das Ansteigen der OSM-Daten nervt, das kann ich gut verstehen, der osm-tmc Validator läuft auch nicht rund, weil ich mit dem Umschreiben der Programme die das Erzugen nicht hinterher komme und die Daten so stark wachsen. Dann nimm mal meine Perspektive. Ich habe mit Tileservern nichts am Hut. Ich war aber kürzlich hier aktiv: http://www.openstreetmap.org/browse/node/595024 Ein eher harmloser Fall: Ein Knoten an der Einmündung in einen Platz, der als Ampel getaggt ist und mehrere TMC-Tags trägt. Die Ampel ist allerdings so nicht ganz richtig, denn es gibt keine zwei separaten Ampelanlagen an den Enden des Platzes, sondern nur einen einzigen (sehr breiten) Fußgängerüberweg. Eventuell werde ich diese Ampel also irgendwann löschen wollen. Da stellen sich mir mehrere Fragen: Zuerst mal - was bedeuten diese Tags? Ok, als ML-Leser habe ich TMC schon mal gehört und bin nach dieser Diskussion hier auch nicht mehr komplett ahnungslos. Das ist allerdings kein geeigneter Maßstab. Wichtiger in der Mappingpraxis sind aber solche Fragen: Wenn ich den Knoten umtagge oder lösche, wohin sollen diese Tags? Gehören die verschiedenen TMC-Tags untrennbar zusammen? Ist die genaue Koordinate wichtig? Ist die Tatsache wichtig, dass der Knoten an der Einmündung zum Platz liegt? Ist es wichtig, auf welcher Seite der abgehenden Einbahnstraße der Knoten liegt? Müssen solche Tags womöglich sogar an Ampeln hängen? Mit diesen Fragen wird man als Mapper ziemlich allein gelassen. Und das rechtfertigt diese Diskussion. Mit dem Etikett Relevanzdiskussion wird man dem nicht gerecht - ich finde die Möglichkeit einer Verknüpfung mit TMC keineswegs irrelevant. Aber die Art, wie das Vorhaben bisher umgesetzt wird, finde ich unschön. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 03.02.2011 23:03, schrieb Tobias Knerr: Man kann seine Sicht eben nicht nur auf den Aufwand für denjenigen einschränken, der den Import durchführt. Es wird von Mappern wie mir erwartet, dass sie sich die Mühe machen, bei ihren Bearbeitungen die (für sie evtl. absolut uninteressanten) TMC-Daten intakt zu halten. Nein, ich erwarte das nicht von dir und auch von keinem anderen. Wenn ich z.B. beim editieren von Straßen irgendwelche Radrouten, Jakobswege oder TMC Infos kaputt mache, dann ist das halt so. Ich editiere jetzt nicht wie ein wilder Berserker und versuche das natürlich passend hinzubekommen, aber wenn wir vor lauter Meta-Informationen uns nicht mehr trauen die eigentlichen Geodaten zu bearbeiten, haben wir ein Problem. Insofern stimme ich Frederik mit dem potenziellen Problem überein - komme aber zu einer ganz anderen Lösung. Wohl auch, weil ich bei der deutschen Wikipedia gesehen habe, wozu der Ansatz: Vereinsdaten ins Vereinswiki, das hat hier nix zu suchen geführt hat. Im Gegenzug erwarte ich von den Betreibern des TMC-Imports, dass sie mir diese Aufgabe so einfach wie möglich machen. Da stimme ich dir zu. Ich habe nichts gegen kryptische Daten in OSM, aber es muß den Leuten klar sein: Je kryptischer, desto schneller wieder kaputt ;-) Gruß, ULFL P.S: Ich bin bei der globalen Auswertung von Tags auf viele kryptische Sachen gestoßen. Die TMC Tags sind wenigstens im Wiki recht ordentlich beschrieben, was man von vielen anderen Kryptotags leider nicht behaupten kann - da half nur Google um zumindest ne Idee zu bekommen, was überhaupt gemeint ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 3. Februar 2011 23:03 schrieb Tobias Knerr o...@tobias-knerr.de: Ein eher harmloser Fall: Ein Knoten an der Einmündung in einen Platz, der als Ampel getaggt ist und mehrere TMC-Tags trägt. Die Ampel ist allerdings so nicht ganz richtig, denn es gibt keine zwei separaten Ampelanlagen an den Enden des Platzes, sondern nur einen einzigen (sehr breiten) Fußgängerüberweg. Eventuell werde ich diese Ampel also irgendwann löschen wollen. ... das ist eigentlich kein Problem, wenn Du nur die Ampel löschen willst, dann reicht es ja, highway=traffic_lights zu entfernen. Um die TMC-tags brauchst Du Dich nicht zu kümmern. Aber ich gebe zu, dass die tags nicht direkt schön sind. Angerührt habe ich die bisher auch noch nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Ich verstehe jetzt bei dieser Relevanz/Grundsatz-Diskussion beide Seiten nicht ganz, weil sich drüben im Thread Koennen wir die TMC-Daten rauswerfen? ja eine Lösung (Frederik nannte es Kompromiss) abzeichnete. Am 3. Februar 2011 16:10 antwortete Frederik: 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 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. Dann fällt also das OePNV-Schema als Beispiel in http://wiki.openstreetmap.org/wiki/DE:Nutzung_von_OSM_durch_FIS weg? Ich habe übrigens manchmal den Eindruck, dass viele Mapper grundsätzlich nicht gerne lesen (insbesondere Wiki-Seiten) :- 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. Da das scheint mir auch wichtig. 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. Hier muss ich Sven zustimmen: OSM soll weiterhin Platz bieten aktuelle Informationen (= aktuell verglichen mit dem maximal Halbjahres-Rhythmus offizieller Geodatenquellen). Ich möchte da nochmals aufs Beispiel Haiti hinweisen mit den Strassen, die von einem Tag auf den andern unpassierbar waren. Ein interessanter Hinweis steckt in der Antwort oben: Der Hauptrenderer soll tatsächlich möglichst wenig Ballast erhalten. = Kann dies nicht geregelt (oder einfach implementiert und kommuiziert) werden, indem Präfix-Tags *nicht* per default weiterverarbeitet werden - insbesondere nicht zum Hauptrenderer? Um auf TMC zurückzukommen: TMC (Traffic Message Channel) ist bekanntlich ein Staumeldesystem für Verkehrsradio, dann v.a. für (Auto-)Navis. TMC ist keine Nischeninformation, bzw. genauso eine wie viele andere. TMC ist höchstens ev. ein Fachinformationssystem (FIS) mit zu kurzlebigen Daten. Wenn wir ein TMC-Schema finden, dass etwas allgemeinverständlicher ist, können alle mitreden. Ich sehe hier - wie auch bei Vogelhäuschen und Fahrstühlen - eine wichtige Frage, die sich sowohl FIS-Macher wie auch OSM-Gralshüter stellen müssen: Es muss möglich sein, dass jedermann (natürlich möglichst korrekte) FIS-Daten erfassen kann. Für mich ist wünschenswert, dass (jeder-)mann Baustellen, Vogelhäuschen und Fahrstuhl-Zustände mappen kann. Aber für Daten, die flüchtiger als weniger als eine Stunde hat OSM vorläufig wohl (noch) keine Ressourcen. Daher meine Gretchenfrage an die TMC-Befürworter: = Dürfen alle - auch wir Nicht-Bots (:-) - TMC-Daten erfassen und verändern? = Wie flüchtig sind TMC-in-OSM-Daten? Und an alle: Wie flüchtig dürfen OSM-Daten sein? Eine Woche? Ein Tag? Zwei Stunden? LG, S. Am 3. Februar 2011 19:46 schrieb Frederik Ramm frede...@remote.org: Hallo, Sven Anders wrote: Ich erinnere mich an eine Diskussion mit Sven Sommerkamp, der mir verbieten wollte straßenbegleitende Radwege in OSM als extra Way anzulegen, weil ansonsten sein Garmin nicht mehr in Hamburg routen konnte[1]. Das kann doch kein ernst zu nehmendes Argument sein. Ich will jetzt nicht die Dikssion über straßenbegleitende Radwege weider aufwecken. Ich finde die Diskussion hat ähnlichen Character. Ich finde, es geht um etwas grundsaetzlich verschiedenes. Die Wheelmap-Leute haben einen echten Mehrwert, wenn sie wissen, ob ein Fahrstuhl funktioniert, okay ist nicht die Telefonzelle, aber genau so eine Information. Mache Fahrstühle gehen in Hamburg über 6 Monate nicht. Da ist dann überhaupt die Frage ob man den Fahrstuhl nicht löschen sollte.
