Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Am 06.02.2011 17:22, schrieb Sven Anders: Nachdem ich mich durch den Wald an Nachrichten zu diesem Thema gewühlt habe und es so aussieht als ob sich langsam was sinnvolles aus der Diskussion ergibt, habe ich noch ein paar Anmerkungen: > Ja, genau das habe ich mit dem Aufbau des TMC Validators [1] bezweckt. > Er hat sicherlich viele Schwächen und zeigt z.Z. auch an manchen Stellen > blödsinn an (weil ich mal wieder Basteln musste, arbeite aber schon an > einer Korrektur). Klingt gut. Warum vergißt der TMC-Validator eigentlich so häufig seine Daten ? Achtet der nicht nur auf Veränderungen ? > Sicherlich fallen bei Pascals Auswertungen von OSM-TMC auch noch > Validator daten an. > > Allerdings brauchte man vermutlich noch eine Meta Datenbank dazu, um die > ungereimtheiten im TMC zu dokumentieren. > > (z.B. Straßen die zwar in TMC Daten noch existieren, in der realität > aber nicht mehr). oder erst im Bau sind, bzw in Planung und manchmal nie in die Realität umgesetz werden. Auch kenne ich Stellen, wo zur Zeit noch der alte Datensatz aktuell ist, weil man sonst von der Bundesstraße abbiegt und direkt im Baustellenstau landet. So haben wir auch schon einige Fehler in den TMC-Daten entdenkt. > Und das Tagging-Schema ist ja noch nicht einmal in sich konsistent (es > gibt z.B. keine Einigkeit darüber wo der Knotenpunkt für eine > Autobahn-Auffahrt am sinnvollsten gesetzt werden sollte.) Endlich wird das auch erwähnt. Für mich sind TMC-Points die Wege zwischen Ab- und Auffahrt und nicht nur ein Knoten. Eine Kreuzung ist in OSM häufig nicht nur Knoten. fly [1] http://osm-tmc.anders-hamburg.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?
Am 06.02.2011 17:22, schrieb Sven Anders: Und das Tagging-Schema ist ja noch nicht einmal in sich konsistent (es gibt z.B. keine Einigkeit darüber wo der Knotenpunkt für eine Autobahn-Auffahrt am sinnvollsten gesetzt werden sollte.) Wenn Du die Beschleunigungs-Verzögerungsspuren meinst bei der Abfahrt an der Stelle wo die durchgezogene Linie beginnt und an der Auffahrt an der Stelle wo sie aufhört. So hat man im Stau noch die Chance die Autobahn an der letzt möglichen Position zu verlassen bzw. das Navi kann bis dahin noch die Alternativroute vorschlagen. 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?
Am 07.02.2011 13:05, schrieb M∡rtin Koppenhoefer: Das Problem liegt beim Ausblenden halt immer darin, dass die Daten auch wenn sie grundverschieden sind, sich in aller Regel doch aufeinander beziehen. Wenn irgendwo ein Kino als Punkt eingezeichnet ist, und man die benachbarte Straße verschiebt, ändert sich falls man nicht aufpasst eben auch die Straßenseite des Kinos. Und wenn das jetzt ausgeblendet war, dann hat man einen Fehler generiert, ohne es zu bemerken. Ich will nicht ausblenden - dabei gebe ich dir vollständig recht. Ich will die Übersichtlichkeit OHNE Ausblenden verbessern. Was jetzt genau bei TMC sonst noch stört, sei dahingestellt - ein Argument war aber, "drei Attribute für einen node sind zu viele für TMC". Während ich einigen hier (u.A. Frederik) zutraue oder von ihnen weiß, dass sie auch die technische Verarbeitung der Daten damit meinen, halte ich das in bestimmten Fällen vor allem für ein Problem beim Editieren, weil man eben nicht mehr alle Werte sehen kann. Ich arbeite an 'nem Netbook mit "nur" ca 700 px Nutzbarer Höhe. Wenn ich da in JOSM jetzt die üblichen vier oder fünf Fensterchen rechts geöffnet habe, dann sind ca 6 Einträge in der Attributliste sichtbar - im Zweifelsfall 5 davon eine schön vollständige Adresse: addr:city addr:country addr:housenumber addr:postcode addr:street Die Daten sind wichtig - aber ein kleines plus vor einer Ausklappbaren Zeile + Addresse = sowiesoweg 14 würde es auch tun - ausklappen kann man immer noch; und man könnte den Editor auch speichern lassen, ob ein addr:*-Folding jetzt eingeklappt sein soll oder nicht. Ich bin prinzipiell dem Ausblenden sehr skeptisch gegenübergestellt weil ich die Gefahr von diesen "Topologiefehlern" sehe. Wer an einer Stelle editiert sollte sich auch soweit nötig mit dem auseinandersetzen, was es dort schon gibt. Sonst laufen wir Gefahr, dass alles sich eben doch zu einer zusammenhanglosen POI- und Way-Sammlung entwickelt, die untereinander beziehungslos ist, und dann könnte man wirklich gleich mehrere parallele Datenbanken (mit den ganzen implizierten Fehlern und Asynchronitäten) haben. +1 Schon deutlich positiver sehe ich das Zusammenklappen von Informationen: da stünde dann z.B. nur noch name mit einem Symbol und beim Anclicken würden name:de, name:int, name:en, name:fr, name:it, name:ru und alle anderen Namen angezeigt. Genau das ist meine Idee - und name ist ein schönes Beispiel dafür; auch wenn viele Objekte noch wenig internationale Namen haben. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Am 6. Februar 2011 20:26 schrieb Peter Wendorff : > Ganz kurzer Hinweis: > Die "Idee" mit der Unterstützung von Namensräumen im Editor habe ich vor > drei Tagen hier geäußert (Betreff war "Doppelpunkt"). > Die Reaktionen waren eher mäßig und skeptisch bezüglich der generellen > Umsetzbarkeit. Das Problem liegt beim Ausblenden halt immer darin, dass die Daten auch wenn sie grundverschieden sind, sich in aller Regel doch aufeinander beziehen. Wenn irgendwo ein Kino als Punkt eingezeichnet ist, und man die benachbarte Straße verschiebt, ändert sich falls man nicht aufpasst eben auch die Straßenseite des Kinos. Und wenn das jetzt ausgeblendet war, dann hat man einen Fehler generiert, ohne es zu bemerken. Ich bin prinzipiell dem Ausblenden sehr skeptisch gegenübergestellt weil ich die Gefahr von diesen "Topologiefehlern" sehe. Wer an einer Stelle editiert sollte sich auch soweit nötig mit dem auseinandersetzen, was es dort schon gibt. Sonst laufen wir Gefahr, dass alles sich eben doch zu einer zusammenhanglosen POI- und Way-Sammlung entwickelt, die untereinander beziehungslos ist, und dann könnte man wirklich gleich mehrere parallele Datenbanken (mit den ganzen implizierten Fehlern und Asynchronitäten) haben. Schon deutlich positiver sehe ich das Zusammenklappen von Informationen: da stünde dann z.B. nur noch name mit einem Symbol und beim Anclicken würden name:de, name:int, name:en, name:fr, name:it, name:ru und alle anderen Namen angezeigt. > Kritisiert wurde das Konzept z.B. am Beispiel source:*, weil sich dabei > unterschiedliche Source-Tags auf völlig unterschiedliche Attribute beziehen > und nicht im "üblichen" Sinn eine Kategorie bilden. Das ist Ansichtssache: man kann source:* ja allesamt als Quellen bezeichnen, also Metadaten und keine eigentlichen Daten, von daher ist das durchaus eine Kategorie. Man kann das natürlich auch anders sehen. 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?
Hier nochmals mein letzter Senf dazu bis zur FOSSGIS :->: * Namensräume ein/ausblenden im Editor wären wohl nützlich. * Wanderwege und ÖPNV-Relationen widersprechen meines Wissens nicht der Knoten-Kanten-Relationen-Tags-Struktur von OSM. * Die aktuellen TMC-Tags missbrauchen den Prefix m.E.: "tmc:" is für mich der Prefix; alles andere sind strukturierte Werte. * Das aktuelle TMC-Schema überlagert OSM mit einer eigenen (Sub-)Tag-Struktur und einer linearen Segmentierung (was das OSM-Schema eindeutig verkomplizieren würde). * Eine Relevanzdiskussion muss leider sein, auch wenn auch mich Realtime und Verkehrsdaten faszinieren. Die Wiki-Seite DE:Nutzung_von_OSM_durch_FIS könnte mind. ein Anfang für "Nicht-Eignungskriterien" sein. André wrote: > 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. Ich würde diesen "Kompromiss" nicht vorschnell verwerfen. Das etabliert die Verknüpfung und signalisiert dem Mapper (und den OSM-Tools), dass da was "dranhängt". LG, S. Am 6. Februar 2011 20:26 schrieb Peter Wendorff : > Ganz kurzer Hinweis: > Die "Idee" mit der Unterstützung von Namensräumen im Editor habe ich vor > drei Tagen hier geäußert (Betreff war "Doppelpunkt"). > Die Reaktionen waren eher mäßig und skeptisch bezüglich der generellen > Umsetzbarkeit. > > Da Du selbst dich da nicht beteiligt hast, hier das einfach noch als > Hinweis; falls Du da Ideen beisteuern willst. > > Kritisiert wurde das Konzept z.B. am Beispiel source:*, weil sich dabei > unterschiedliche Source-Tags auf völlig unterschiedliche Attribute beziehen > und nicht im "üblichen" Sinn eine Kategorie bilden. > > Gruß > Peter > > Am 06.02.2011 12:14, schrieb Henning Scholland: >> >> Garry und Frederik Ramm schrieben eine Menge >> >> Hallo >> Eure Diskussion ist zwar schön und gut, doch sie führt irgendwie zu >> nichts. >> >> So wie ich Frederik verstehe, geht es ihm darum, dass das ganze zu komplex >> ist und Mapper abschreckt, weil sie Angst ahben Fehler zu machen. Das kann >> ich durchaus verstehen. Das bedeutet aber nicht, dass man die Daten nicht in >> OSM abbilden sollte. >> >> Die Editoren bräuchten eine Unterstützung für die Namensräume. Man müsste >> in den Objekteigenschaften sinnvolle Gliederungen einführen. Ein Beispiel >> wären aufklappende Tabellen. Was in anderen Programmen schon länger gemacht >> wird, wenn man solche tabellarischen Eigenschaften hat. >> Der Mapper hat dann eine schnelle Übersicht, welche Eigenschaften des >> Objekt enthält. Bspw. Oberflächen, Buslinien und Verkehrsdaten. Die >> Eigenschaften können auch in Relationen abgelegt worden sein. Hier wäre eine >> einheitliche Darstellung aller Eigenschaften wünschenswert. Das die Buslinie >> in einer Relation getagt ist, ist dem Mapper an sich egal. Ähnliches gilt >> auch für Multipolygone. Auch hier ist nur interessant, dass die Fläche ein >> Wald ist. Wie das in den Daten hinterlegt ist, ist uninteressant. >> >> Da keiner all diese Gruppen auswendig kennen kann, sollte es bspw. eine >> Übersicht in wiki-Form geben, wo kurz erklärt wird was es ist und worauf es >> ankommt: Absolute Lagegenauigkeit oder doch eher relative Lagegenauigkeit zu >> Objekt XY. >> >> Das würde das Mappen einfacher und OSM flexiblerer machen. >> >> Schönes Wochenende noch, >> Henning >> >> >> ___ >> 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 mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Ganz kurzer Hinweis: Die "Idee" mit der Unterstützung von Namensräumen im Editor habe ich vor drei Tagen hier geäußert (Betreff war "Doppelpunkt"). Die Reaktionen waren eher mäßig und skeptisch bezüglich der generellen Umsetzbarkeit. Da Du selbst dich da nicht beteiligt hast, hier das einfach noch als Hinweis; falls Du da Ideen beisteuern willst. Kritisiert wurde das Konzept z.B. am Beispiel source:*, weil sich dabei unterschiedliche Source-Tags auf völlig unterschiedliche Attribute beziehen und nicht im "üblichen" Sinn eine Kategorie bilden. Gruß Peter Am 06.02.2011 12:14, schrieb Henning Scholland: Garry und Frederik Ramm schrieben eine Menge Hallo Eure Diskussion ist zwar schön und gut, doch sie führt irgendwie zu nichts. So wie ich Frederik verstehe, geht es ihm darum, dass das ganze zu komplex ist und Mapper abschreckt, weil sie Angst ahben Fehler zu machen. Das kann ich durchaus verstehen. Das bedeutet aber nicht, dass man die Daten nicht in OSM abbilden sollte. Die Editoren bräuchten eine Unterstützung für die Namensräume. Man müsste in den Objekteigenschaften sinnvolle Gliederungen einführen. Ein Beispiel wären aufklappende Tabellen. Was in anderen Programmen schon länger gemacht wird, wenn man solche tabellarischen Eigenschaften hat. Der Mapper hat dann eine schnelle Übersicht, welche Eigenschaften des Objekt enthält. Bspw. Oberflächen, Buslinien und Verkehrsdaten. Die Eigenschaften können auch in Relationen abgelegt worden sein. Hier wäre eine einheitliche Darstellung aller Eigenschaften wünschenswert. Das die Buslinie in einer Relation getagt ist, ist dem Mapper an sich egal. Ähnliches gilt auch für Multipolygone. Auch hier ist nur interessant, dass die Fläche ein Wald ist. Wie das in den Daten hinterlegt ist, ist uninteressant. Da keiner all diese Gruppen auswendig kennen kann, sollte es bspw. eine Übersicht in wiki-Form geben, wo kurz erklärt wird was es ist und worauf es ankommt: Absolute Lagegenauigkeit oder doch eher relative Lagegenauigkeit zu Objekt XY. Das würde das Mappen einfacher und OSM flexiblerer machen. Schönes Wochenende noch, Henning ___ 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?
Hallo, Sven Anders wrote: Frederik, ist es für dich okay, das wir mit einem Neuentwurf für ein TMC Schema bis nach der Fossgis warten? Oder sollen wir schon jetzt einen Neuentwurf anfangen? "fuer mich ok"? Ich bin ja schon froh, wenn mir ueberhaupt jemand zuhoert ;) 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?
Am 06.02.2011 10:01, schrieb Bodo Meissner: Oder vielleicht gibt es externe Prüfmechanismen, mit denen man regelmäßig automatisch feststellen kann, ob die TMC-Tags noch konsistent sind. Ja, genau das habe ich mit dem Aufbau des TMC Validators [1] bezweckt. Er hat sicherlich viele Schwächen und zeigt z.Z. auch an manchen Stellen blödsinn an (weil ich mal wieder Basteln musste, arbeite aber schon an einer Korrektur). Sicherlich fallen bei Pascals Auswertungen von OSM-TMC auch noch Validator daten an. Allerdings brauchte man vermutlich noch eine Meta Datenbank dazu, um die ungereimtheiten im TMC zu dokumentieren. (z.B. Straßen die zwar in TMC Daten noch existieren, in der realität aber nicht mehr). Und das Tagging-Schema ist ja noch nicht einmal in sich konsistent (es gibt z.B. keine Einigkeit darüber wo der Knotenpunkt für eine Autobahn-Auffahrt am sinnvollsten gesetzt werden sollte.) Frederik, ist es für dich okay, das wir mit einem Neuentwurf für ein TMC Schema bis nach der Fossgis warten? Oder sollen wir schon jetzt einen Neuentwurf anfangen? Gruß Sven [1] http://osm-tmc.anders-hamburg.de/ Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1OY1AACgkQnMz9fgzDSqd1qQCfVAkrUH2GX9un5U1KDZN+knvw tmAAn33mhwY9DszRQjTccosEVKDCNniD =rix2 -END PGP SIGNATURE- ___ 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?
Garry und Frederik Ramm schrieben eine Menge Hallo Eure Diskussion ist zwar schön und gut, doch sie führt irgendwie zu nichts. So wie ich Frederik verstehe, geht es ihm darum, dass das ganze zu komplex ist und Mapper abschreckt, weil sie Angst ahben Fehler zu machen. Das kann ich durchaus verstehen. Das bedeutet aber nicht, dass man die Daten nicht in OSM abbilden sollte. Die Editoren bräuchten eine Unterstützung für die Namensräume. Man müsste in den Objekteigenschaften sinnvolle Gliederungen einführen. Ein Beispiel wären aufklappende Tabellen. Was in anderen Programmen schon länger gemacht wird, wenn man solche tabellarischen Eigenschaften hat. Der Mapper hat dann eine schnelle Übersicht, welche Eigenschaften des Objekt enthält. Bspw. Oberflächen, Buslinien und Verkehrsdaten. Die Eigenschaften können auch in Relationen abgelegt worden sein. Hier wäre eine einheitliche Darstellung aller Eigenschaften wünschenswert. Das die Buslinie in einer Relation getagt ist, ist dem Mapper an sich egal. Ähnliches gilt auch für Multipolygone. Auch hier ist nur interessant, dass die Fläche ein Wald ist. Wie das in den Daten hinterlegt ist, ist uninteressant. Da keiner all diese Gruppen auswendig kennen kann, sollte es bspw. eine Übersicht in wiki-Form geben, wo kurz erklärt wird was es ist und worauf es ankommt: Absolute Lagegenauigkeit oder doch eher relative Lagegenauigkeit zu Objekt XY. Das würde das Mappen einfacher und OSM flexiblerer machen. Schönes Wochenende noch, 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?
Am 06.02.2011 01:58, schrieb Frederik Ramm: 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. Vergleich zu maxspeed: Hier könnte man auch alle verkehrsschildbedingte maxspeed-Tags durch mappen der entsprechenden Schilder ersetzen. Diese Schilder kann man dann auch alle statt in OSM abzulegen in eine externe Datenbank auslagern. OSM wäre etwas entrümpelt - und die Lust der (Freizeit)-Anwendungsprogrammierer maxspeed in eine Anwendung zu implementieren dahin... 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? Klares jein, weil: Das ist kein TMC-verursachtes Problem, das fing schon zur OSM-Urzeiten an als es darum ging einem Einsteiger zu erklären was unter highway=trunk oder highway=unclassified zu vestehen ist und auch heute noch gelegentlich zu Uneinigkeiten bei den Profis führt. Diese Einstiegshürde wurde entschärft in dem man in JOSM deutsche Begriffe (Landesstrasse,Kreisstrasse,..) eingesetzt hat - unter inkaufnahme der dadurch entstehenden Fehler weil es teilweise doch grössere Abweichungen gibt. Wenn man jetzt für TMC im Editor einfach nur sowas wie "Verkehrsnachrichtendienst" anzeigen lassen würde hätte man eine ähnliche Entschärfung. 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. Ohne diesen Studenten jetzt zu nahe treten zu wollen - einem Buschmann musst Du auch erstmal erklären was eine Ampel ist und was es mit den Farben auf sich hat, sonst tut er sich auch schwer in einer Stadt sicher zu bewegen... 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? Kommt aber mehr als Drohung wie Frage rüber: "Wenn nicht gleich eine Erklärung kommt so dass ich das für gut befinde lösche ich die Daten". Vielleicht verbessert es Dein Verständnis wenn Du noch ein paar weiter Bedingungen kennst die TMC geformt haben: RDS, das Radiodatensystem wurde in den 80er Jahren eingeführt um digitale Daten mit geringer Bandbreite zusammen mit dem normalen Musik/Sprachprogramm eines UKW Senders(Kanal) wie z.B. SWR3 zu übertragen. Das RDS-System unterstütz dabei mehrere Datenkanäle wie z.B. (grob aus dem Gedächtniss)Uhrzeit, Sendernamen, Musikart, Programmname, aktueller Musiktitel... und eben auch TMC (TrafficMessageChanel). TMC sollte es ermöglichen Verkehrsnachrichten ständig aktuell und unabhängig von den in der Regel halbstündlichen Verkehrsmeldungen per Radiosprecher zu übertragen. Da die Bandbreite nur relativ wenige Bytes pro Minute(!) zu übertragen erlaubt mussten Verkehrsmeldungen möglichst kompakt übertragen werden was eben
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Hallo. Am Sonntag 06 Februar 2011, 10:01:04 schrieb Bodo Meissner: > Die Warnmeldung könnte dann aussagen: "Lieber User, mit diesem Objekt hier > ist irgendwas, was Du nicht verstehst, aber es macht nichts, wenn hier > etwas kaputtgeht. Darum kümmern sich ggf. die Spezialisten." Und was soll das dann dem Benutzer sagen? Soll er jetzt Änderungen machen oder nicht? Das ist FUD erster Güte. Gruß, Bernd -- Die Frauen ändern zwar manchmal ihre Ansichten, aber nie ihre Absichten. - Curt Goetz (dt. Schriftsteller) 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 05.02.2011 19:32, schrieb Frederik Ramm: > 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?" > André Reichelt wrote: > >> 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. Vielleicht läßt sich das technisch so einrichten, daß sich nicht der "normale" User mit Änderungen an den den Spezialtags auseinandersetzen muß, sondern die Leute, die sich damit auskennen. Die Warnmeldung könnte dann aussagen: "Lieber User, mit diesem Objekt hier ist irgendwas, was Du nicht verstehst, aber es macht nichts, wenn hier etwas kaputtgeht. Darum kümmern sich ggf. die Spezialisten." Könnte man vielleicht irgendwelche "Trigger" einbauen, daß bei Löschungen oder "wichtigen Änderungen" von Objekten mit Tags aus dem TMC-Namensraum eine Benachrichtigung ausgelöst wird. Das könnte vielleicht eine Mail an eine TMC-Mailingliste sein oder eine Eintragung auf einer Wiki-Seite. Dann müßten sich natürlich Leute finden, die diese Änderungsmeldungen prüfen und ggf. korrigieren. Was eine "wichtige Änderung" ist, müßte natürlich definiert werden. (Eine leichte Verschiebung einer Straße mit TMC-Tags gehört sicher nicht dazu.) Ähnliches könnte man für Relationen machen. Oder vielleicht gibt es externe Prüfmechanismen, mit denen man regelmäßig automatisch feststellen kann, ob die TMC-Tags noch konsistent sind. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1OY1AACgkQnMz9fgzDSqd1qQCfVAkrUH2GX9un5U1KDZN+knvw tmAAn33mhwY9DszRQjTccosEVKDCNniD =rix2 -END PGP 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?
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?
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 zwa
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
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?
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?
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
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
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?
Am 5. Februar 2011 19:32 schrieb Frederik Ramm : > 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?
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?
Hallo, 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! Als weiteren Schritt sollten wir uns überlegen eine Möglichkeit zu schaffen, bestimmte Tags komplett ausblenden zu lassen. Wer sagt denn, dass TMC-Tags überhaupt angezeigt werden müssen? Es muss ein Schalter im Optionsdialog her, mit dem man komplette Namensräume direkt wegblenden kann. Tags wie TMC dürfen auch gerne von Hause aus ausgeblendet sein, da nur die Wenigsten an diesen Tags Änderungen vornehmen werden und dann eine manuelle Aktivierung einfacher ist. 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. 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. Jedenfalls ist das Löschen der TMC-Tags für mich *keine* Lösung, zumal diese, wie ja hier mehrfach gut begründet wurde, eine außerordentliche Relevanz haben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
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 : > 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
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
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?
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?
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?
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?
On Thu, 2011-02-03 12:13:29 +0100, Florian Lohoff 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?
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?
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 : > 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@openstre
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
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?
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?
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?
Am 3. Februar 2011 10:05 schrieb Henning Scholland : > 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?
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?
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?
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?
On 02.02.11 22:39, Frederik Ramm wrote: > 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? Das sehe ich auch so. Punkte oder Regionen (Areas) kann man problemlos extern auf Koordinaten mappen und dann kann ein Router o.ä. seine Route damit verschneiden (oder Punkte auf Nähe prüfen); und ein Renderer kann die Flächen rot schraffieren oder was er halt will. Das, was IMO die "Challenge" ist, ist die Zuordnung zu Straßenstücken (von A nach B; das ist in der Praxis auch die Regel). Sodaß der Renderer dann die richtige Seite der Autobahn von A nach B rot und mit einem Warnschild (Achtung Stau, Achtung Glatteis,...) darstellen kann und der Router weiß, welche Straßenstücke er auslassen soll oder ob seine Route über so ein "bewarntes" Straßenstück läuft. 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 02.02.2011 16:35, Jan-Benedict Glaw wrote: On Wed, 2011-02-02 16:19:59 +0100, Bernd Wurst wrote: Am Mittwoch 02 Februar 2011, 15:56:03 schrieb Wolfgang: Ü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 ;-) doch, passt rein. Nennt sich TPEG-Loc. Hier zum Nachlesen: http://de.wikipedia.org/wiki/Transport_Protocol_Experts_Group#Unabh.C3.A4ngigkeit_vom_Kartenmaterial_.28TPEG-Loc.29 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?
Hallo Bernd, On 02.02.2011 16:19, Bernd Wurst wrote: 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? Weiß jemand wie TMCpro hier arbeitet? Auch mit (den selben) Location-Codes? das was du suchst nennt sich TPEG. Schicke Sache, wenn du im Stadtverkehr siehst wo sich gerade der Verkehr staut. Die Auflösung geht bis auf Häuserblock-Ebene. In Korea hat das jedes billig-Navi. In Deutschland ist es erst am kommen. 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?
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
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
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?
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?
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?
Am 2. Februar 2011 14:07 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" ;) 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?
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
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
On Wed, 2011-02-02 18:23:00 +0100, Henning Scholland 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?
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 17:02:37 +0100, Bernd Wurst 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?
Am 2. Februar 2011 17:16 schrieb Frederik Ramm : > 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?
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?
Am 02.02.2011 15:26, schrieb Jan-Benedict Glaw: On Wed, 2011-02-02 14:19:50 +0100, Andreas Labres 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?
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?
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?
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?
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?
On Wed, 2011-02-02 16:19:59 +0100, Bernd Wurst 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?
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?
Am 2. Februar 2011 14:07 schrieb Frederik Ramm : >> 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?
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?
On Wed, 2011-02-02 14:22:50 +0100, Frederik Ramm 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?
On Wed, 2011-02-02 14:19:50 +0100, Andreas Labres 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?
Hi, 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. 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 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... 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. 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. Aber ich warte dann mal ab bis zu Pascals Vortrag auf der FOSSGIS und schau mal, was die Leute da so sagen. Da koennen wir dann gleiche noch eine BoF-Session anschliessen und ueberlegen, wie wir das loesen koennen. Die Argumente im Wiki sind allerdings auch nicht ganz von der Hand zu weisen; und immerhin wird mit TMC: ein eindeutiges Prefix verwendet. 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. 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?
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?
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?
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, 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?
Am 2. Februar 2011 11:10 schrieb Frederik Ramm : > 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?
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?
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=13&lat=51.05703&lon=13.73706&layers=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?
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?
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?
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?
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?
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?
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?
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
[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