Re: [Talk-de] Dauer von Datenänderung bis diese gerendert ist
Hallo Frederik, Claudius, Fabian, danke für die ausführliche Erklärung und die Links. Ganz schön komplex, was da alles im Hintergrund geschieht! Erstaunlich wie schnell OSM ist! Das beeindruckt Kursteilnehmer immer wieder. Formulierungen wie keine 10 Minuten oder in wenigen Minuten passen also gut im Zusammenhang mit Aktualität ist ein herausragendes Qualitätsmerkmal von OSM. In Kursen demonstriere ich das: die Teilnehmer ändern etwas mit JOSM, ich erkläre etwas dazu oder beantworte eine Frage - und schon ist das Ergebnis in der Karte sichtbar :-) _Wiki_ Wir könnten doch eine Wikiseite zum Thema Aktualität machen... Wo wir den Weg von der Dateneingabe bis zum Erscheinen auf der Karte beschreiben. Frederik's Info könnten wir als Basis nehmen. Was wäre ein sinnvoller Seitentitel? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Open Windrad Map
Hi, gibt es schon irgendwo eine Karte, auf der man Windräder in niedrigeren Zoomstufen zu sehen bekommt? Gruß, Fabian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Open Windrad Map
Mir sind zwei Karten bekannt, auf denen man die Windräder schon in niedriger Zoomstufe sieht: http://energy.freelayer.net/ http://www.tappenbeck.net/osm/maps/deu/index.php?id=1019 (leider sind beide Karten aber nur für DE) Am 02.02.2011 10:36, schrieb Fabian Schmidt: Hi, gibt es schon irgendwo eine Karte, auf der man Windräder in niedrigeren Zoomstufen zu sehen bekommt? Gruß, Fabian. ___ 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] Koennen wir die TMC-Daten rauswerfen?
Hallo, ich aegere mich ziemlich ueber die TMC-Daten in der OSM-Datenbank. Ich habe nicht die Uebersicht, wer da alles dran arbeitet und dran gearbeitet hat, also es besteht die Gefahr, dass ich jetzt einigen ehrbaren Mappern auf die Fuesse trete, aber wenn's nach mir geht, muss das Zeug raus. Wir haben fast aussschliesslich menschenlesbare Daten in OSM. Schnapp Dir ein beliebiges Objekt, und Du kannst in aller Regel verstehen, was die Tags daran bedeuten. Wir sind keine Datenbank fuer irgendwelche externen Daten, die in OSM nicht wartbar sind, Daten, die man im RL nicht verifizieren kann. Vielleicht kann mir mal einer den folgenden Vorgang erklaeren. Da ist also eine harmlose Ampel in Dortmund, Node-ID 270090818, getaggt als highway=traffic_signals. Dann kommt am 31, Januar der User ruhri daher und ergaenzt das Tag: TMC:cid_58:tabcd_1:LocationCode = 47739 Wo hat er das her? Steht das auf einem Aufkleber an der Ampel? Wenn nicht (wenn es aus einer externen Liste/Datenbank kommt), warum muss das dann in OSM stehen - kann das nicht derjenige, der die Daten auswerten will, dann aus genau dieser externen Liste hinzufuegen? Fuenf Stunden spaeter kommt ein TMCbot - der uebrigens, soweit ich sehen kann, keiner der ueblichen Anforderungen an Bots genuegt - und behauptet qua Changeset-Kommentar: Korrektur von Schreib- und Datenintegritätsfehlern in Key/Value-Paaren des deutschen TMC Schemas. Was er aber tatsaechlich tut, ist, noch drei weitere Tags hinzuzufugegen: TMC:cid_58:tabcd_1:Class = Point TMC:cid_58:tabcd_1:LCLversion = 9.00 TMC:cid_58:tabcd_1:PrevLocationCode = 28866 Wo hat er sich die jetzt wieder hergeholt? Ist es nicht offensichtlich, dass es sich bei diesem Node um einen Point handelt? Was besagt diese LCLversion, und woher weiss der Bot, dass der User ruhri 9.00 gemeint hat? Grundsaetzlich bin ich ja fuer Anarchie beim Tagging. Aber was wir hier haben, ist ganz offensichtlich irgendeine externe Spezialdatenbank, die unter massiven Eingriffen in OSM irgendwie auf OSM abgebildet wird, und zwar so, dass man nicht nur tonnenweise unverstaendlichen Code in OSM kippen muss (highway=traffic_signals versteht jeder, aber TMC:cid_58:tabcd_1 versteht nur ein Computer), sondern auch noch taeglich Bots laufen lassen muss, um diese Daten irgendwie in Schuss zu halten. Wenn jemand ein paar tausend Fotos hat und an irgendwelche Nodes in Deutschland sowas dranpappt wie foto_url=..., dann sagt ja keiner was (das versteht vorallem auch jeder). Aber von diesen TMC-Tags gibt es mittlerweile 175000 in Deutschland. Die Botschaft, die bei einem neuen Mapper da ankommt, ist doch: Oh, ein kryptisch getaggtes Objekt. Das fass ich mal lieber nicht an. Mir erschliesst sich der Nutzen dieser Tags nicht - kann mir jemand mal eine praktische Anwendung zeigen, die diese Tags benutzt? Mir sieht das nach einem grossangelegten Designfehler aus. Da haette man von vornherein ein OSM-externes Mapping TMC-OSM bauen muessen, statt praktisch die ganze TMC-Datenbank auf OSM aufzupropfen. Ich will jetzt nicht die Revolution anzetteln und morgen alle TMC-Daten loeschen (und ich aergere mich, dass ich der Geschichte nicht viel frueher widersprochen habe). Aber wenn es nicht irgendwelche ueberwaeltigenden Gruende dafuer gibt, warum diese Daten in OSM bleiben muessen, dann bin ich sehr dafuer, dass diejenigen, die diese Daten verwenden, sich da irgendwie etwas basteln, was weniger invasiv ist. Wenn jetzt an einem Objekt z.B. nur eine TMC-ID dranstehen wuerde und alles weitere - was fuer eine Klasse, was ist die naechste ID, die vorherige ID, wassweissich - waere extern, koennte man damit ja schon leben. Ich suche also sozusagen eine Exit-Strategie. Ich will herausfinden, was und wem diese Daten nutzen, und dann ein Konzept machen, wie wir die Daten aus OSM entfernen koennen, ohne diesen Nutzen zu ruinieren. Ausser natuerlich, alle ausser mir finden diese TMC-Daten ganz knorke und haetten lieber noch viel mehr Tags der Art BPF:grq_23:tiwwhs_2:MegaCode = 281763. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Open Windrad Map
Am 02.02.2011 10:36, schrieb Fabian Schmidt: Hi, gibt es schon irgendwo eine Karte, auf der man Windräder in niedrigeren Zoomstufen zu sehen bekommt? Ich arbeite an einer Karte zu Kraftwerken und Stromnetzen. Es gibt noch technische Probleme (siehe Thread Performanceprobleme bei Mapnik/SQL) aber vielleicht hilft dir schon die die Karte bis Z=9: http://toolserver.org/~osm/styles/?zoom=11lat=54.2584lon=10.03051layers=F0FFF0FFFB000T 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?
Hallo Frederik, ich selber finde die TMC-Daten ganz ok. - auch wenn diese kryptisch sind und für Menschen nicht verständlich... Unten sind noch ergänzende Worte... Am 02.02.2011 11:10, schrieb Frederik Ramm: Hallo, Mir erschliesst sich der Nutzen dieser Tags nicht - kann mir jemand mal eine praktische Anwendung zeigen, die diese Tags benutzt? Wenn ich mich nicht irre, werden die TMC-Daten von openrouteservice ausgewertet Mir sieht das nach einem grossangelegten Designfehler aus. Da haette man von vornherein ein OSM-externes Mapping TMC-OSM bauen muessen, statt praktisch die ganze TMC-Datenbank auf OSM aufzupropfen. Da sehe ich dann das Problem, wenn man ein Navigerät nutzen will, das auch die TMC-Daten auswertet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Hallo, On 02/02/11 11:34, Fred Jelk wrote: Mir sieht das nach einem grossangelegten Designfehler aus. Da haette man von vornherein ein OSM-externes Mapping TMC-OSM bauen muessen, statt praktisch die ganze TMC-Datenbank auf OSM aufzupropfen. Da sehe ich dann das Problem, wenn man ein Navigerät nutzen will, das auch die TMC-Daten auswertet. Kein Navi benutzt OSM-Daten direkt; bei allen ist ein Vorverarbeitungsschritt noetig. Wenn das Navi tatsaechlich die TMC-Daten aus OSM verwenden kann, muss das entsprechende Vorverarbeitungsprogramm die Daten richtig extrahieren - und koennte das genauso gut aus einer externen Datenbank, nehme ich jetzt mal an. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
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 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?
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] Open Windrad Map
Am 02.02.2011 10:53, schrieb Fred Jelk: Mir sind zwei Karten bekannt, auf denen man die Windräder schon in niedriger Zoomstufe sieht: http://energy.freelayer.net/ http://www.tappenbeck.net/osm/maps/deu/index.php?id=1019 (leider sind beide Karten aber nur für DE) Hi ! = werde vielleicht noch Spanien auf den Weg bringen - was hättest Du den am liebsten noch ? Gruß Jan :-) ___ 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?
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?
Ich bin gegen ein Löschen der TMC-Daten. Richtig ist zwar, dass relativ viele Information zusätzlich gespeichert werden, welche nicht immer notwendig sind, da sie einfach von einem Bot hinzugefügt werden können. Aber ein genereller Abgleich ist nicht fehlerfrei möglich. Marcus Wohlschon (der Initiator) hat bereits einige Automatismen untersucht. Deutschland dient daher in erster Linie zum Test von Import/Verknüpfung von TMC in/mit OSM. Bei Straßen mit einem way oder einfachen Kreuzungen ist eine automatische Verknüpfung in 99% möglich. Komplizierter wird es bei mehrspurigen Straßen (Autobahnen) mit getrennten Ways für Hin- und Rückweg sowie Kreuzungen mehrspuriger Straßen. Visualisierung und Stand des TMC-Imports: http://osm-tmc.anders-hamburg.de/?zoom=13lat=51.05703lon=13.73706layers=B0T Die Diskussion sollte daher nicht in die Richtung, Wie können wir die Daten so schnell wie möglich löschen? sondern mehr in Richtung Wie können wir das Tagging vereinfachen/lesbarer gestalten? gehen. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
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?
Am 2. Februar 2011 11:10 schrieb Frederik Ramm frede...@remote.org: Wir haben fast aussschliesslich menschenlesbare Daten in OSM. Schnapp Dir ein beliebiges Objekt, und Du kannst in aller Regel verstehen, was die Tags daran bedeuten. ich kenne die Details der TMC-Daten nicht, aber durch das TMC-Präfix ist ja klar, in welche Richtung das gehört, von daher finde ich das jetzt nicht so tragisch. Wenn jemand ein paar tausend Fotos hat und an irgendwelche Nodes in Deutschland sowas dranpappt wie foto_url=..., dann sagt ja keiner was (das versteht vorallem auch jeder). wenn aber jeder Facebook-nutzer im Schnitt 100 Fotos in OSM verortet, würde man vielleicht schon was sagen. Zumindest sind das erstmal keine Geodaten (ohne das Foto), sondern Linksammlungen. Ähnlich verhält es sich zwar auch mit TMC, aber die Daten sind wenigstens öffentlich zugänglich, was man bei vielen der verlinkten Fotos nicht sagen kann. Aber von diesen TMC-Tags gibt es mittlerweile 175000 in Deutschland. ohne die Qualität der Daten zu kennen, hört sich das doch erstmal beeindruckend ein. Die Italiener sind jedenfalls neidisch auf die Daten ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
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?
Hi, Andreas Labres schrieb: On 02.02.11 12:33, Pascal Neis wrote: ich wollte bei der FOSSGIS nach meinem Vortrag auch eine Diskussion diesbzgl. starten, etwas überspitzt: Macht es Sinn, wie (ob) derzeit die TMC Daten in OSM eingearbeitet werden? Ich kenne die Natur dieser TMC Daten/Location Codes nicht, grundsätzlich würde ich meinen, eine Referenzierung dieser Location Code bezeichnet diese(s) Element(e) in OSM würde grundsätzlich Sinn machen. Sodaß eine auswertende App verstehen kann: auf Stück X der Autobahn ist Stau, daher zeichne ich dort eine rote Line (oder ein Router weiß, diese Kanten verwende ich nicht oder bewerte ich mit Aufschlag). ich greife meinem Vortrag jetzt mal etwas vor: Bei dem was Andreas oben beschreibt liegt z.B. bereits ein Problem vor, weil dies so derzeit nicht ganz einfach aus OSM herauszubekommen ist, es aber so benötigt werden würde. Meiner Meinung nach sollte man etwas überdenken wie man die TMC Codes einträgt. TMC Staus oder Verkehrsbehinderungen beziehen sich im Normalfall immer auf Straßenstücke. Diese werden durch einen LocationCode From und To angegeben. Diese Information ist so aber derzeit nicht bei uns in den Daten drin und lässt sich auch eher nur mühselig aus den OSM Daten ableiten. Dazu kommen dann noch Faktoren wie OSM Relations und tlw. nicht richtig eingetragene TMC Codes oder unsauber getrennte OSM Ways ... viele gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Hallo, On 02/02/11 13:12, Wolfgang wrote: Ich würde bei 1:1-Zuordnungen nicht einmal eine ID in die OSM-Datenbank einfügen, sondern diese Verknüpfung in der extra-DB oder einer dritten Verknüpfungsinstanz halten. Sobald in OSM ein Node gelöscht wird, ist die Zuordnung für die Katz. Das funktioniert nicht, zumal man dann in OSM gar nicht erkennen kann, dass am Node etwas dranhängt. Wenn ich einen Node in einem Straßenverlauf lösche, nehme ich einen ohne tags. Das ist allerdings ein allgemeines Problem, das immer wieder aufkommt - wie kann man von extern in OSM hinein linken und dabei halbwegs fehlertolerant sein (d.h. ohne in OSM ein Loesch- und Editierverbot des verlinkten Objekts zu fordern). Natuerlich kann man das Problem umgehen, indem man aus OSM heraus auf die externe Datenbank linkt - aber das skaliert nicht, oder im Volksmund: Wenn das jeder machen wuerde ;) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
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
[Talk-de] Kraftwerks-Karte (war: Open Windrad Map)
Eine leichte Thread-Entführung: Am 02.02.2011 11:28, Stephan Wolff: Am 02.02.2011 10:36, schrieb Fabian Schmidt: gibt es schon irgendwo eine Karte, auf der man Windräder in niedrigeren Zoomstufen zu sehen bekommt? Ich arbeite an einer Karte zu Kraftwerken und Stromnetzen. Wäre toll, wenn du dabei auch das erweiterte Schema http://wiki.openstreetmap.org/wiki/Key:generator:source für Quelle und Art der Stromerzeugung unterstützen könntest. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
On Wed, 2011-02-02 14:19:50 +0100, Andreas Labres l...@lab.at wrote: On 02.02.11 14:05, Pascal Neis wrote: TMC Staus oder Verkehrsbehinderungen beziehen sich im Normalfall immer auf Straßenstücke. Das wäre auch mein Verständnis/meine praktische Erfahrung mit TMC. Und die gilt es in OSM identifizierbar zu machen (IMO). Wenn dazu die Strategie des Taggens geändert werden muß, sollte man das tun. ...und in ganz NRW gibts Nebel und Eisregen. Sowas kommt nicht nur gesprochen vom Radio-Moderator, sondern wird eben auch via TMC übertragen. In TMC (via Radio bzw. teilweise auch via Sat-Radio zu empfangen) werden letztlich drei Zahlen geschickt. Zwei davon (wobei eine leer sein kann) ist der Location Code, die dritte Zahl gibt den Grund (und ggf. die geschätzte Dauer) an. Problematisch ist, daß die Punkte/Strecken/Polygone nicht trivial auf die OSM-Gegenstücke übertragbar sind. Es gibt beispielsweise straßentechnisch nicht das Kreuz A2/A1, sondern ein ganzes Bündel an Ab- und Auffahrten. Um dann das Stück Strecke zwischen (beispielsweise) diesem Kreuz und einer Abfahrt davor (wo möglicherweise der Stau beginnt) herauszufinden, ist in den guten OSM-Daten eben etwas mehr Aufwand nötig, weil u.a. die Fahrtrichtung berücksichtigt werden muß. Daher ists auch nicht so einfach machbar, einfach einen Punkt aufs das Kreuz zu setzen und den Location Code dabeizuschreiben... MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: ...und wenn Du denkst, es geht nicht mehr, the second : kommt irgendwo ein Lichtlein her. signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
On Wed, 2011-02-02 14:22:50 +0100, Frederik Ramm frede...@remote.org wrote: On 02/02/11 12:34, Peter Wendorff wrote: Das Wiki dokumentiert eigentlich insgesamt recht gut, was da gemacht wird und welches Tagging-Schema verwendet wird. Also offensichtlich gibt es da eine TMC-Datenbank mit bestimmten Punkten, die Vorgaenger und Nachfolger haben - also sowas wie Ways bei uns. Richtig; zusätzlich gehören die allermeisten Objekte immer auch einem höherwertigen Objekt an. (Autobahn-Abfahrt - Streckenabschnitt - Bundeland) Diese Datenbank ist von sich aus, so wie ich das verstehe, erstmal konsistent, d.h. alle Vorgaenger und Nachfolger existieren tatsaechlich, es gibt keine Luecken usw. Nun ist es eine Sache, die einzelnen Punkte auf OSM abzubilden. Das waere ideal komplett extern, aber es ginge auch noch mit einer TMC-Id an einem OSM-Objekt (dieses OSM-Objekt ist in der TMC-Datenbank der Knoten 12345). Dafuer brauche ich genau ein Tag, das ich noch dazu relativ menschenlesbar gestalten koennte, z.B. tmc_code=12345 Das reicht leider nicht, weil damit die /gerichtete/ Natur der BASt-Liste nicht abgebildet werden kann. Ein TMC-Code alleine sagt Dir noch keine /Richtung/. Wenn ich nun aber - aus welchen Gruenden auch immer - damit beginne, nicht nur ein Mapping zwischen dem externen Graphen und der OSM-Datenbank zu bauen, sondern den externen Graphen direkt in OSM einzubauen, dann gibt das ganz verschiedene Probleme. Ich schaffe damit (logisch betrachtet) ja ein zweites Netz von Ways, die von einem TMC-Knoten zum naechsten fuehren. Das wird nun krude ueber eine Art Vorgaenger-Pointer abgebildet, der, je nachdem, wie die OSM-Datenbank grade dasteht, auch mal ins Leere zeigen kann, weil das entspr. Objekt bei OSM fehlt oder umgetaggt wurde - obwohl ich aus der externen Datenbank ja wissen koennte, welches das betr. Objekt ist... Das wiederum läßt sich anhand der Dumps recht einfach testen. Bliebe herauszufinden, *wieso* hier die Enscheidung getroffen wurde, nicht nur die Nodes zu mappen, sondern auch den Versuch zu unternehmen, den kompletten Graphen mit zu uebernehmen. - Wir haben ja durchaus mehrere Graphen in OSM, zum Beispiel Stromleitungsnetze oder Pipeline-Netze oder die Eisenbahnlinien. Aber die sind alle mit Ways umgesetzt und nicht mit irgendwelchen speziellen numerischen Pointern. Die einzelnen Nodes sind bei TMC nicht so selbständig, wie das bei diesen anderen Netzen der Fall ist. Bei TMC liegt die Intelligenz darin, daß mit einem Knoten und einer Richtung indirekt gleich mal noch der Straßenabschnitt, die Straße, das Bundeland etc. mitgegeben ist. Aus der Richtung folgt damit (insbesondere bei Autobahnen und größeren Bundesstraßen) auch die Fahrbahn. TMC kannt keine Fahrbahn in dem Sinne, sondern nur A2 in Positiv-Richtung und A2 in Negativ-Richtung. Irgendso auf der A2 (welcher der beiden OSM-Spuren jetzt eigentlich?) also ein tag tmc_lcl_code=12345 zu setzen bringt also nichts, weil das entweder auf der Gegenspur fehlen würde oder ihm die Richtung fehlt... Wenn man die zusätzlichen Tags nicht aufbringt, ist die Auswertung noch schlechter machbar, als das jetzt schon per TMC-Liste (von der BASt) zu machen ist.) Also, in mir festigt sich die Ansicht: So, wie es ist, ist es nicht nur nervig fuer die Mapper, sondern auch fuer die TMC-Anwender unnoetig kompliziert; haette man die TMC-Datenbank extern, koennte man damit sogar besser arbeiten. Klares nein. Die übrigen Nutzer merken nicht viel von den TMC-Tags. Im schlimmsten Fall gehen sie verloren. (Daß wer mutwillig TMC-Tags vertauscht, weil es geht, wär' ja eher absurd...) Einfache Mappings sind mit TMC so nicht zu machen. Wie gesagt, bis zu einem gewissen Grad wuerde ich da auch jedem zugestehen, sein eigenes Ding irgnedwo in einer Nische bei OSM zu machen. Eigener Prefix und gut is. Aber hier haben wir es mit einem ziemlichen Kraken zu tun, der noch dazu einen taeglich laufenden Korrektur-Bot braucht, und da hoert fuer mich irgendwann der Spass auf. Der Bot wiederum sollte, nachdem die Daten einmal da sind (und solange die BASt keine neue Listen-Version raushaut) recht unnötig sein. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of:Arroganz verkürzt fruchtlose Gespräche. the second : -- Jan-Benedict Glaw signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Am 2. Februar 2011 14:07 schrieb Frederik Ramm frede...@remote.org: Sobald in OSM ein Node gelöscht wird, ist die Zuordnung für die Katz. Das funktioniert nicht, zumal man dann in OSM gar nicht erkennen kann, dass am Node etwas dranhängt. Wenn ich einen Node in einem Straßenverlauf lösche, nehme ich einen ohne tags. Das ist allerdings ein allgemeines Problem, das immer wieder aufkommt - wie kann man von extern in OSM hinein linken und dabei halbwegs fehlertolerant sein (d.h. ohne in OSM ein Loesch- und Editierverbot des verlinkten Objekts zu fordern). Wieso merkt sich die externe Datenbank dann nicht einfach die Koordinaten des OSM-Objektes, solange es da ist (und ggf. den groben Objekttyp und ref/name) und löst einen Bugreport aus, wenn sie feststellt, daß das verlinkte OSM-Objekt nicht mehr Existiert, seine Position um mehr als 100m verändert hat oder Objekttyp/ref/name geändert wurde? Damit könnte die externe Datenbank Updates erhalten, ohne in OSM schreiben zu müssen und bei Veränderungen in OSM, auf die die externe Datenbank linkt, könnte für *deren* Maintainer Alarm ausgelöst werden. :-) In einfachen Fällen nach bestimmten Kriterien (z.B. shop-Node gelöscht und als way mit gleichen tags an gleicher Position (+- X m) wieder hochgeladen) könnte man die Verlinkung eventuell sogar automatisch nachführen. Am besten wäre es vermutlich, für solche Fälle eine API zu haben, über die sich externe Datenbanken über Veränderungen bestimmter abonnierter Objekte in OSM informieren können - dann wäre es auch einfacher, externe Datenbanken wie Fahrpläne, Öffnungszeiten, Veranstaltungskalender etc. mit OSM-Objekten zu verknüpfen... Gruß, Martin (der keine Ahnung hat, ob und wie sowas tatsächlich umgesetzt werden könnte) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
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?
Hallo. Am Mittwoch 02 Februar 2011, 15:56:03 schrieb Wolfgang: DIe TMC-Geschichte gehört zu den zentralen Daten, die zumindest mit OSM eng vermascht werden müssen. Routing mit Verkehrsinfo ist einfach Stand der Technik. Aber ist nicht einerseits die Datenübertragung des TMC und auch die Herangehensweise wie die TMC-Codes definiert sind stark veraltete Technik und wird das nicht in Zukunft sowieso anders laufen? Also es ist ja abzusehen, dass die UKW-Übertragung alsbald von einer Internet- Übertragung abgelöst wird, fast alle jetzt neu entwickelten Geräte haben ja mobilen Internetzugang. Wäre die Frage ob die TMC-Codes für diese Übertragungen auch nötig sind oder ob die das auf die für mich naheliegendere Weise machen: Von Koordinate [X] bis Koordinate [Y] auf Straße [Z] mit ganz normalen GPS-Koordinaten und einem Straßennamen (A 1) den das Navi auf seine Daten projeziert. Weiß jemand wie TMCpro hier arbeitet? Auch mit (den selben) Location-Codes? Gruß, Bernd -- Fachbegriffe der Informatik (#286): Googlehupf Abstand zwischen zwei Suchergebnissen. (Markus Kempken) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
On Wed, 2011-02-02 16:19:59 +0100, Bernd Wurst be...@bwurst.org wrote: Am Mittwoch 02 Februar 2011, 15:56:03 schrieb Wolfgang: DIe TMC-Geschichte gehört zu den zentralen Daten, die zumindest mit OSM eng vermascht werden müssen. Routing mit Verkehrsinfo ist einfach Stand der Technik. Aber ist nicht einerseits die Datenübertragung des TMC und auch die Herangehensweise wie die TMC-Codes definiert sind stark veraltete Technik und wird das nicht in Zukunft sowieso anders laufen? Veraltet? Naja, Das Nutzdaten-pro-Bit-Verhältnis ist bei dem, was übertragen wird, echt verdammt gut! Wenn veraltet und anders laufen bedeutet, daß mehr bloat kommt, dann... Also es ist ja abzusehen, dass die UKW-Übertragung alsbald von einer Internet- Übertragung abgelöst wird, fast alle jetzt neu entwickelten Geräte haben ja mobilen Internetzugang. Wäre die Frage ob die TMC-Codes für diese UKW gibts für lau. Bzw. gegen GEZ-Gebühr. Wifi und UMTS gibts nur gegen Extra-Geld, die Technik ist (denk' auch an die Navis) teurer und komplizierter. Maximal kommen die Daten noch in DAB (bzw. DAB+) mit rein, aber ich geh' davon aus, daß es TMC noch sehr, sehr lange Zeit geben wird. Übertragungen auch nötig sind oder ob die das auf die für mich naheliegendere Weise machen: Von Koordinate [X] bis Koordinate [Y] auf Straße [Z] mit ganz normalen GPS-Koordinaten und einem Straßennamen (A 1) den das Navi auf seine Daten projeziert. Das paßt nicht in die behördlichen Vorgänge ;-) MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of:http://www.chiark.greenend.org.uk/~sgtatham/bugs.html the second : signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
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?
Hallo. Am Mittwoch 02 Februar 2011, 16:35:38 schrieb Jan-Benedict Glaw: Aber ist nicht einerseits die Datenübertragung des TMC und auch die Herangehensweise wie die TMC-Codes definiert sind stark veraltete Technik und wird das nicht in Zukunft sowieso anders laufen? Veraltet? Naja, Das Nutzdaten-pro-Bit-Verhältnis ist bei dem, was übertragen wird, echt verdammt gut! Wenn veraltet und anders laufen bedeutet, daß mehr bloat kommt, dann... Das mag sein, aber macht das in der Praxis was aus? Also viel zu oft geht die Daten-Sparsamkeit in die Richtung, dass dann irgendwelche proprietären oder zumindest fast nicht re-implementierbaren Algorithmen zum Zug kommen. Siehe meinen naiven Vorschlag, das ist zwar vermutlich etwas bloated aber trivial auszuwerten ohne jedliche Dritt-Daten, Chiffre-Listen oder sonstiges Zeug wofür man jederzeit Geld verlangen könnte. Selbst ein GPS-Gerät ohne jegliche Karte könnte einem sagen wo man nicht hin fahren soll. Zudem hier ja nur Broadcast zur Verfügung steht, bei einer IP-Verbindung würde man naheliegender Weise ein Poll-Verfahren benutzen und nur das runterladen was einen interessiert. UKW gibts für lau. Bzw. gegen GEZ-Gebühr. Wifi und UMTS gibts nur gegen Extra-Geld, die Technik ist (denk' auch an die Navis) teurer und komplizierter. Maximal kommen die Daten noch in DAB (bzw. DAB+) mit rein, aber ich geh' davon aus, daß es TMC noch sehr, sehr lange Zeit geben wird. Ich teile diese Meinung zu UKW, aber schau dir die Praxis an. Youtube und Co sind so ziemlich das schlimmste was man dem Internet antun konnte und trotzdem ist es gemacht worden. Und auch die Öffentlich-rechtlichen Anstalten mischen kräftig mit indem sie eine Infrastruktur betreiben die das Fernsehschauen via IP-Verbindung (und eben nicht Multicast!) ermöglicht. Es gibt heute TV- Receiver ohne jeglichen Tuner (siehe Telekom) und ähnlich wildes Zeug. Und UMTS-Verbindungen werden in den allerwenigsten Fällen individuell abgerechnet, da setzt sich die Trafficpauschale doch sehr durch. Und in einem MB Traffic bekommt man auch viele aufgeblähte Infos unter. Man muss das nicht gut finden, aber das ist die Entwicklung der Dinge. Nicht dass morgen jemand den Schalter umlegt und TMC abschaltet, nein. Aber wenn wir jetzt erst anfangen die Infrastruktur für TMC in den Daten zu bauen, ist es dann noch von Bedeutung wenn es benutzbar wird? Übertragungen auch nötig sind oder ob die das auf die für mich naheliegendere Weise machen: Von Koordinate [X] bis Koordinate [Y] auf Straße [Z] mit ganz normalen GPS-Koordinaten und einem Straßennamen (A 1) den das Navi auf seine Daten projeziert. Das paßt nicht in die behördlichen Vorgänge ;-) TMCpro hat mit behördlichen Vorgängen ja nichts zu tun, das ist ja privatwirtschaftlich organisiert. Auch diese Entwicklung muss man nicht gut finden, aber wenn Behörden banale Dinge zu umständlich machen gibt es halt Firmen die das ganze für Geld einfacher anbieten. Daher erneut die Frage: Nutzt TMCpro ebenfalls diese Technik? Gerüchteweise (habe kein TMCpro-Gerät) soll das ja detailliertere Infos bieten. Gruß, Bernd -- Ich moechte Windows kaufen. Sind Sie verrueckt? Gehoert das zu den Lizenzbedingungen? signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Hallo, On 02/02/11 16:52, Frank Gruender wrote: TMC ist funktional direkt auf Navigationssysteme ausgelegt und nicht für Mikrowellen und Waschmaschinen. Die Aktualität dürfte in der Regel größer als bei Telefonnummern irgendwelcher Restaurants sein. OSM ist gerade für Navigationssyteme und für Landkarten gedacht. Das ist doch aber kein Argument. TMC ist keine inhaerente Eigenschaft der Strassen und Wege, die wir vor uns sehen. TMC ist eine komplett separate Datenbank, die mit OSM erstmal nichts zu tun hat und die sich irgendeine dritte Stelle ausgedacht hat. Eine von ziemlich vielen, wie ich annehme. Ich bin nicht ueberzeugt, dass diese Datenbank nur nutzbar gemacht werden kann, indem sie komplett in OSM importiert und dort gepflegt wird. Und die Logik: Kenn ich nicht, ess ich nicht kann wohl kein Grund sein, TMC-Daten zu löschen. Da fallen mir auf Anhieb Tags ein, die weder mit Landkarten, noch Navis etwas zu haben, aber die Krücke muß ich wohl hier nicht bemühen. Grundsaetzlich haben die meisten Leute Respekt vor fremden Daten, die sie nicht kennen. Trotzdem muss man davon ausgehen, dass unverstaendliche und un-ueberpruefbare Daten oefter mal unter die Raeder geraten oder verfaelscht werden, auch voellig unabsichtlich. Das, was wir im Augenblick haben, ist ganz bestimmt keine tragfaehige Loesung, und wenn es, wie jemand anders sagte, ein Pilotschema zur Erfassung von TMC in anderen Laendern sein sollte, dann wuerde ich sagen, es ist gescheitert. Aber ich bin sicher, dass es eine Loesung gibt, die es ermoeglicht, die TMC-Datenbank z.B. bei der Datenaufbereitung fuers Navi hinzuzuladen, statt die TMC-Datenbank komplett in OSM zu stopfen und damit (a) allen auf die Nerven zu fallen und (b) Datenfehlern Tuer und Tor zu oeffnen. Jan-Benedict, habe ich Dich richtig verstanden, dass ein TMC-Code praktisch sowas bezeichnet wie eine etwas abstrakte Strassenkreuzung? Das haben wir doch z.B. bei Mautpunkten auch - da wird die Maut zwischen der Anschlusstelle A und der Anschlusstelle B berechnet, und diese Anschlusstellen sind ja bei uns in OSM auch keine Nodes, sondern ein Sammelsurium an Nodes, motorway_links, usw. Wenn ich nun z.B. eine Relation haette, die mir besagt: Die folgenden 15 Objekte machen zusammen die Anschlusstelle 13 der A8 aus, und das ganze Ding hat den TMC-Code soundso - wuerde mir das dann reichen? Oder hat die Anschlusstelle 13 verschiedene TMC-Codes, je nachdem, in welche Richtung man sie betrachtet? Und warum TMC:cid_58:tabcd_1:... - muss man davon ausgehen, dass es die gleichen LocationCodes auch im Namensraum TMC:cid_59:tabcd_1 oder TMC:cid_58:tabcd_2 gibt? Und nochmal meine Frage von eingangs: Der Mapper hatte zunaechst nur LocationCode = 47739 gesetzt. Der Bot hat dann PrevLocationCode = 28866 ergaenzt. Wo hat der Bot diese Information her - und wenn es einen Algorithmus gibt, nach dem der Bot das ermitteln konnte, warum muss es dann explizit in der Datenbank stehen? Koennte es sein, dass der Algorithmus falsche Ergebnisse liefert und ich das dann von Hand im Einzelfall auf PrevLocationCode = 28867 korrigieren muss oder so? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
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?
Am 02.02.2011 15:26, schrieb Jan-Benedict Glaw: On Wed, 2011-02-02 14:19:50 +0100, Andreas Labresl...@lab.at wrote: On 02.02.11 14:05, Pascal Neis wrote: TMC Staus oder Verkehrsbehinderungen beziehen sich im Normalfall immer auf Straßenstücke. Das wäre auch mein Verständnis/meine praktische Erfahrung mit TMC. Und die gilt es in OSM identifizierbar zu machen (IMO). Wenn dazu die Strategie des Taggens geändert werden muß, sollte man das tun. ...und in ganz NRW gibts Nebel und Eisregen. Sowas kommt nicht nur gesprochen vom Radio-Moderator, sondern wird eben auch via TMC übertragen. In TMC (via Radio bzw. teilweise auch via Sat-Radio zu empfangen) werden letztlich drei Zahlen geschickt. Zwei davon (wobei eine leer sein kann) ist der Location Code, die dritte Zahl gibt den Grund (und ggf. die geschätzte Dauer) an. Problematisch ist, daß die Punkte/Strecken/Polygone nicht trivial auf die OSM-Gegenstücke übertragbar sind. Es gibt beispielsweise straßentechnisch nicht das Kreuz A2/A1, sondern ein ganzes Bündel an Ab- und Auffahrten. Um dann das Stück Strecke zwischen (beispielsweise) diesem Kreuz und einer Abfahrt davor (wo möglicherweise der Stau beginnt) herauszufinden, ist in den guten OSM-Daten eben etwas mehr Aufwand nötig, weil u.a. die Fahrtrichtung berücksichtigt werden muß. Daher ists auch nicht so einfach machbar, einfach einen Punkt aufs das Kreuz zu setzen und den Location Code dabeizuschreiben... MfG, JBG So wie ich das Verstanden hab sind die TMC-Objekte in Abschnitte unterteilt. Auf diesen Abschnitten befinden sich (mehrere) OSM-Ways. Dann ist doch kein Problem, an allen OSM-Objekten eine TMC-ID zu taggen, je nach Zugehörigkeit und in einer seperaten Datenbank dann eine Zuordnung zwischen den ganzen TMC-Eigenschaften und dieser ID zu hinterlegen. Will man nun die Daten auswerten, findet man in den OSM-Daten die ID und sucht sich die passenden TMC-Eigenschaften aus der Datenbank heraus. Bei Ampel-Nodes ist obiges auch ohne Probleme möglich. Viele Grüße, Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
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 2. Februar 2011 17:16 schrieb Frederik Ramm frede...@remote.org: Und warum TMC:cid_58:tabcd_1:... - muss man davon ausgehen, dass es die gleichen LocationCodes auch im Namensraum TMC:cid_59:tabcd_1 oder TMC:cid_58:tabcd_2 gibt? cid ... Land 58 Es kann vorkommen, dass Straßen oder Bereiche im Grenzgebiet in den TMC-Listen mehrerer Länder vorkommen. Diese haben dann auch einen unterschiedlichen TMC-Code. tabcd ... Liste 1 In jedem Land kann es verschiedene Definitionen von wichtigen Straßen und Knotenpunkten geben. Dies ist in Deutschland mit TMC und TMCpro gegeben. Um jetzt bei jedem Element die unterschiedlichen TMC-Codes anzugeben, wurde analog zu fuel:*=yes ein System mit TMC:Land:Liste=Code eingeführt. Eine Alternative aber noch schlechter zu lesen wäre: TMC = Land:Liste:Code:Richtung; Land2:Liste:Code:Richtung; ... Und nochmal meine Frage von eingangs: Der Mapper hatte zunaechst nur LocationCode = 47739 gesetzt. Der Bot hat dann PrevLocationCode = 28866 ergaenzt. Wo hat der Bot diese Information her - und wenn es einen Algorithmus gibt, nach dem der Bot das ermitteln konnte, warum muss es dann explizit in der Datenbank stehen? Koennte es sein, dass der Algorithmus falsche Ergebnisse liefert und ich das dann von Hand im Einzelfall auf PrevLocationCode = 28867 korrigieren muss oder so? In den meisten Fällen kann man das einfach ergänzt werden. Hier ist jedoch die Frage ob das Notwendig ist. Auf den Wiki-Seiten sind diese Dinge daher als optional gekennzeichnet. http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany#Tagging_Schema Bei einer Straße mit baulich getrennten Fahrspuren und unterschiedlichen Auf- und Abfahrten ist zumindest die Informationen der Richtung obligatorisch. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kraftwerks-Karte (war: Open Windrad Map)
Am 02.02.2011 14:43, schrieb Claudius: Am 02.02.2011 11:28, Stephan Wolff: Ich arbeite an einer Karte zu Kraftwerken und Stromnetzen. Wäre toll, wenn du dabei auch das erweiterte Schema http://wiki.openstreetmap.org/wiki/Key:generator:source für Quelle und Art der Stromerzeugung unterstützen könntest. generator:source und generator:output:electricity werden ausgewertet. Was vermisst du? Gruß, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Löschen von falschen und abgetauten Loipen
Hi! Allgemein gilt ja bei OSM das Prinzip, Dinge zu mappen, die sich irgendwie vor Ort nachvollziehen lassen. Dinge die nicht mehr existieren, werden normalerweise entfernt, z.B. wenn eine Straße umgebaut oder ein Weg verlegt wurde. Es ist auch nicht erwünscht, flüchtige Informationen wie eine regenbedingte Wasserpfütze oder den Landeanflug eines Flugzeugs als way mit einzutragen. Nach dieser Regel wären gemappte Langlaufloipen wieder zu löschen, wenn sie aufgrund von Tauwetter spurlos verschwunden sind. Ab diesem Zeitpunkt stellt der Eintrag nur noch eine Falschinformation dar. Darüber hinaus sind diese toten Ways beim mappen echter Wege und Straßen sehr irritierend, wenn sie mit Wegen verwechselt oder versehentlich angeklickt oder verknüpft werden. Filter im Editor sind nur die halbe Miete, da sie auch alle echten Wege, die zusätzlich ein Loipentag tragen, verschwinden lassen. Es gab mal eine Diskussion, man sollte diese Loipen beibehalten, da sie ja im nächsten Jahr wieder genauso angelegt würden. Ich hab das diesen Winter mal in meiner Gegend beobachtet und festgestellt, daß das nicht der Fall ist. Eine Abfahrtspiste ist durch Baumschneisen und Lifte festgelegt, aber die Langlaufloipen werden nach Lust und Laune bei jedem Spuren neu verlegt. Ich konnte beobachten, daß sich der Verlauf teilweise innerhalb einer Woche zweimal verändert hat. Mal folgen sie einem Weg, mal führen sie an der gleichen Stelle 50m versetzt über eine Wiese. Sie sind noch deutlich kurzlebiger als ich erwartet hätte. Von einer Kontinuität sogar über Jahre hinweg kann nicht die Rede sein. Solche Falschinformationen empfinde ich als ziemlich störend - schließlich versuchen wir ein möglichst korrektes Bild der Realität herzustellen. Von daher würde ich anregen, Langlaufloipen, die abgetaut sind bzw. allgemein formuliert die vor Ort absolut nicht mehr nachvollziehbar sind, konsequenterweise auch aus dem Datenbestand zu löschen. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Loschen-von-falschen-und-abgetauten-Loipen-tp5985807p5985807.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] Löschen von falschen und abgetauten Loipen
NopMap schrieb: Von daher würde ich anregen, Langlaufloipen, die abgetaut sind bzw. allgemein formuliert die vor Ort absolut nicht mehr nachvollziehbar sind, konsequenterweise auch aus dem Datenbestand zu löschen. Konsequent aus deiner Sicht wäre sicher, die erst gar nicht zu erfassen, oder? Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
On Wed, 2011-02-02 17:02:37 +0100, Bernd Wurst be...@bwurst.org wrote: Am Mittwoch 02 Februar 2011, 16:35:38 schrieb Jan-Benedict Glaw: UKW gibts für lau. Bzw. gegen GEZ-Gebühr. Wifi und UMTS gibts nur gegen Extra-Geld, die Technik ist (denk' auch an die Navis) teurer und komplizierter. Maximal kommen die Daten noch in DAB (bzw. DAB+) mit rein, aber ich geh' davon aus, daß es TMC noch sehr, sehr lange Zeit geben wird. Ich teile diese Meinung zu UKW, aber schau dir die Praxis an. Youtube und Co sind so ziemlich das schlimmste was man dem Internet antun konnte und trotzdem ist es gemacht worden. Und auch die Öffentlich-rechtlichen Anstalten mischen Warum? Auf YouTube sieht man genau das, was man sehen möchte, genau dann, wann man es sehen möchte. Eine typische Unicast-Anwendung. TMC, mit UKW als Broadcast-Träger, ist da doch perfekt aufgehoben. Durch die Reichweitenbegrenzung hat man auch nur die lokalen Daten, also z.B. die von ~ einem Bundesland oder von ganz Deutschland. Ist doch genau, was man im Navi braucht. (Und teilweise wird da ja sogar mit zwei tunern gespielt, sodaß auch noch ein zweiter Sender nach TMC-Infos belauscht werden kann.) kräftig mit indem sie eine Infrastruktur betreiben die das Fernsehschauen via IP-Verbindung (und eben nicht Multicast!) ermöglicht. Es gibt heute TV- Receiver ohne jeglichen Tuner (siehe Telekom) und ähnlich wildes Zeug. Und UMTS-Verbindungen werden in den allerwenigsten Fällen individuell abgerechnet, da setzt sich die Trafficpauschale doch sehr durch. Und in einem MB Traffic bekommt man auch viele aufgeblähte Infos unter. TV Co. sind da IMHO bisher kein gutes Beispiel, weil die Content-Mafia^WVertreiber derzeit noch zu sehr damit beschäftigt sind, möglichst für jeden einzelnen User die Hand aufzuhalten. Daher auch so wenig Multicast (wobei das durchaus eingesetzt wird.) Das hat der Regulierer nämlich durchgesetzt, aber die Industrie spricht darüber natürlich nicht gerne. Problematisch find' ich dann noch die, sagen wir, geringe Stabilität der IP-Verbindungen bei hoher Geschwindigkeit. Zellwechsel, Funklöcher. Die Probleme hat man bei UKW gleich mal garnicht--oder zumindest nur in sehr viel größeren Abständen. Man muss das nicht gut finden, aber das ist die Entwicklung der Dinge. Nicht dass morgen jemand den Schalter umlegt und TMC abschaltet, nein. Aber wenn wir jetzt erst anfangen die Infrastruktur für TMC in den Daten zu bauen, ist es dann noch von Bedeutung wenn es benutzbar wird? Ich bin gespannt! Übertragungen auch nötig sind oder ob die das auf die für mich naheliegendere Weise machen: Von Koordinate [X] bis Koordinate [Y] auf Straße [Z] mit ganz normalen GPS-Koordinaten und einem Straßennamen (A 1) den das Navi auf seine Daten projeziert. Das paßt nicht in die behördlichen Vorgänge ;-) TMCpro hat mit behördlichen Vorgängen ja nichts zu tun, das ist ja privatwirtschaftlich organisiert. Auch diese Entwicklung muss man nicht gut finden, aber wenn Behörden banale Dinge zu umständlich machen gibt es halt Firmen die das ganze für Geld einfacher anbieten. Daher erneut die Frage: Nutzt TMCpro ebenfalls diese Technik? Gerüchteweise (habe kein TMCpro-Gerät) soll das ja detailliertere Infos bieten. Zu TMCpro hab' ich keine Infos. Für TMC und (allgemeiner) Digitaldaten-Übertragung im Radio gibts ja dicke Specs, aber zur Pro-Variante hab' ich noch nichts gelesen. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Eine Freie Meinung in einem Freien Kopf the second : für einen Freien Staat voll Freier Bürger. signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
Am 2. Februar 2011 19:11 schrieb malenki o...@malenki.ch: NopMap schrieb: Von daher würde ich anregen, Langlaufloipen, die abgetaut sind bzw. allgemein formuliert die vor Ort absolut nicht mehr nachvollziehbar sind, konsequenterweise auch aus dem Datenbestand zu löschen. Konsequent aus deiner Sicht wäre sicher, die erst gar nicht zu erfassen, oder? Wenn die wirklich nur so kurzfristig sind, wie Nop schreibt, bin ich auch dagegen, sie zu erfassen. 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 15:37, schrieb Jan-Benedict Glaw: Die übrigen Nutzer merken nicht viel von den TMC-Tags. Was soll ein Mapper denn tun, wenn er eine Straße mit TMC-Tags ändern will. Wenn eine Kreuzung zum Kreisverkehr umgebaut wurde, eine Straße mit zwei getrennten Fahrbahnen bislang nur als eine Linie erfasst war oder umgekehrt statt einer fälschlich zwei Fahrbahnen erfasst waren, dann ist es sehr schwer, die TMC-Tags anzupassen. Der Mapper kann - Änderungen nicht in OSM eingeben. Dann verlieren wir Informationen. - sich in die TMC-Tags einarbeiten. Vermutlich sinkt die Motivation des Mappers und er produziert doch keine gültigen TMC-Tags - die vorhandenen TMC-Tags willkürlich auf einen neuen Punkt setzen. Dann hat man in einer TMC-basierte Auswertung falsche Ergebnisse, aber ein Validator merkt nichts, da das Tag vorhanden und etwa richtig positioniert ist. Ich habe einmal die zweite Variante versucht und bin dann zur dritten Möglichkeit gewechselt. Trotzdem habe ich in solchen Situationen ein schlechtes Gewissen, da ich mit der Verbesserung der highway-Daten auch einen tückischen Fehler in die TMC-Struktur einbaue. Im schlimmsten Fall gehen sie verloren. Manchmal sind falsche Daten schlimmer als fehlende. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
On Wed, 2011-02-02 18:23:00 +0100, Henning Scholland o...@aighes.de wrote: Am 02.02.2011 15:26, schrieb Jan-Benedict Glaw: Problematisch ist, daß die Punkte/Strecken/Polygone nicht trivial auf die OSM-Gegenstücke übertragbar sind. Es gibt beispielsweise straßentechnisch nicht das Kreuz A2/A1, sondern ein ganzes Bündel an Ab- und Auffahrten. Um dann das Stück Strecke zwischen (beispielsweise) diesem Kreuz und einer Abfahrt davor (wo möglicherweise der Stau beginnt) herauszufinden, ist in den guten OSM-Daten eben etwas mehr Aufwand nötig, weil u.a. die Fahrtrichtung berücksichtigt werden muß. So wie ich das Verstanden hab sind die TMC-Objekte in Abschnitte unterteilt. Auf diesen Abschnitten befinden sich (mehrere) OSM-Ways. Dann ist doch kein Problem, an allen OSM-Objekten eine TMC-ID zu taggen, je nach Zugehörigkeit und in einer seperaten Datenbank dann eine Zuordnung zwischen den ganzen TMC-Eigenschaften und dieser ID zu hinterlegen. Will man nun die Daten auswerten, findet man in den OSM-Daten die ID und sucht sich die passenden TMC-Eigenschaften aus der Datenbank heraus. Für Straßen kann man grob sagen, daß es deren Enden meistens mit Kreuzungen oder Ab-/Auffahrten übereinstimmen. Bei Regionen ist das nicht mehr ganz so einfach. Es fällt mir ehrlich gesagt recht schwer, umgangssprachlich zu beschreiben, wie die TMC-Daten funktionieren; mit Stift und Papier ist das gut zu veranschaulichen. Das Hauptproblem ist, daß die TMC'schen Wegpunkte gerichtet sind und eine hierarchische Struktur haben. Das ist ersteinmal sehr anschaulich, aber der Detaillierungsgrad der OSM-Daten ist häufig höher, als das TMC-Raster. Besonders auffällig ist das bei Autobahn-Ab- und -Auffahrten. TMC gibt der Ab-/Auffahrt (bzw. dem ganzen Kreuz) nur einen Punkt, während wir mit den ganzen Zubringer-Wegen etc. da schnell viele dutzend Nodes haben. Und je nach Richtung (wenn man von TMC-Daten auf einen OSM-Straßenabschnitt, der gerade gesperrt ist, kommen möchte) gibt es dann also nicht die eine TMC-Position, sondern man muß auf Basis der Positiv-/Negativ-Richtung zwischen den (beispielsweise) beiden Autobahn-Fahrbahnen unterscheiden können. Eine TMC-Meldung könnte sein: (1234) ist in Positiv-Richtung bis (3212) gesperrt. Nun muß man von (1234) ausgehend die doppelt verkettete Liste solange in Positiv-Richtung weitergehen, bis man bei (3212) angekommen ist. Wird die Autobahn da z.B. kurzzeitig zur Landstraße mit nur einer Fahrbahn, haben wir in den OSM-Daten da viele lustige ein- und zweispurige (Richtige Spur wählen!) Wege... Bei Ampel-Nodes ist obiges auch ohne Probleme möglich. Ampeln (also _reine_ Ampeln) sind allerdings keine TMC-Punkte. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: 17:45 @Eimann Hrm, das E90 hat keinen Lebenszeit Call-Time Counter mehr the second : 17:46 @jbglaw Eimann: Wofür braucht man das? 17:46 @jbglaw Eimann: Für mich ist an 'nem Handy wichtig, daß ich mein Gegeüber hören kann. Und daß mein Gegenüber mich versteht... 17:47 @KrisK jbglaw: was du meinst ist wodka. 17:47 @KrisK jbglaw: es klingelt und man hört stimmen signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
Hallo Klaus, Dinge mappen, die sich irgendwie vor Ort nachvollziehen lassen. Nach dieser Regel wären gemappte Langlaufloipen wieder zu löschen, wenn Das wäre aber schade für die Loipenkarte: http://osm.virtuelle-loipe.de/loipemap/?zoom=12lat=51.75284lon=10.52781layers=BTTF ;-) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
NopMap ekkeh...@gmx.de writes: Hallo Nop! Ich bin dagegen - die Loipen sollen auf jeden Fall bleiben! Nach dieser Regel wären gemappte Langlaufloipen wieder zu löschen, wenn sie aufgrund von Tauwetter spurlos verschwunden sind. Ab diesem Zeitpunkt stellt der Eintrag nur noch eine Falschinformation dar. Darüber hinaus sind diese toten Ways beim mappen echter Wege und Straßen sehr irritierend, wenn sie mit Wegen verwechselt oder versehentlich angeklickt oder verknüpft werden. Filter im Editor sind nur die halbe Miete, da sie auch alle echten Wege, die zusätzlich ein Loipentag tragen, verschwinden lassen. Nun, dann könnte ich ja auch auf die Idee kommen, Fährverbindungen abends zu löschen und morgens wieder einzupflegen ;-) Spaß beiseite, Ich nutze (und würde Loipenkarten gerne mehr nutzen, wenn den mehr Lopien eingetragen wären). Also um zu sehen, wo ich denn Loipen und den Einstieg dazu finde. Dann brauche ich die Karte in der Regel nicht mehr, es sei denn ich gerate an eine schlecht ausgeschilderte Abzweigung. Da hilft mir die Loipenkarte mehr als ein Minibild in einem Loipenführer. Und ich mache auf diesem Weg Werbung für OSM! Bei Langläufern die OSM noch nicht kennen und Lust haben, eine neue Loipe auszuprobieren. Was meinst du, was die für Augen machen wenn sie davon hören! Außerdem: warum sollte es OSM anders als Ersteller von Topografischen Karten machen? Dort sind die Loipen auch manchmal drin. Es gab mal eine Diskussion, man sollte diese Loipen beibehalten, da sie ja im nächsten Jahr wieder genauso angelegt würden. Ich hab das diesen Winter mal in meiner Gegend beobachtet und festgestellt, daß das nicht der Fall ist. Eine Abfahrtspiste ist durch Baumschneisen und Lifte festgelegt, aber die Langlaufloipen werden nach Lust und Laune bei jedem Spuren neu verlegt. Nun, die Pisten sind halt auch breiter! Ich konnte beobachten, daß sich der Verlauf teilweise innerhalb einer Woche zweimal verändert hat. Mal folgen sie einem Weg, mal führen sie an der gleichen Stelle 50m versetzt über eine Wiese. Sie sind noch deutlich kurzlebiger als ich erwartet hätte. Von einer Kontinuität sogar über Jahre hinweg kann nicht die Rede sein. Das ist aber nicht immer so. Die Loipen die ich kenne werden hier in der Gegend seit langem immer wieder gleich angelegt. Und falls jemand auf der Karte den Einstieg zur Loipe findet ist auch eine veraltet Wegführung besser als gar keine. Und wenn sich das verbreitert, so darf ja jeder schnell den Weg korrigieren. Solche Falschinformationen empfinde ich als ziemlich störend - schließlich versuchen wir ein möglichst korrektes Bild der Realität herzustellen. Dann hilft nur Richtigstellen! Aber doch nicht löschen! Von daher würde ich anregen, Langlaufloipen, die abgetaut sind bzw. allgemein formuliert die vor Ort absolut nicht mehr nachvollziehbar sind, konsequenterweise auch aus dem Datenbestand zu löschen. Wie gesagt, ich bin dagegen! Tschuess, Frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
NopMap wrote: Ab diesem Zeitpunkt stellt der Eintrag nur noch eine Falschinformation dar. Dann löschen wir auch im Sommer kleine Bäche? Ist ja kein Wasser drin? Hier sind zur Zeit ein paar Treppen wegen Eisglätte unpassierbar. Auch gleich löschen? Kaputte Ampel? Sessellifte die im Sommer außer Betrieb sind? Biergarten / Ausflugsgaststätten die nur im Sommer geöffnet sind? Darüber hinaus sind diese toten Ways beim mappen echter Wege und Straßen sehr irritierend, wenn sie mit Wegen verwechselt oder versehentlich angeklickt oder verknüpft werden. Prinzipiell ACK, aber mit der Begründung kannst Du o.g. Dinge auch gleich in Frage stellen. Dann müssen die, die editieren, eben besser aufpassen... im nächsten Jahr wieder genauso angelegt würden. Ich hab das diesen Winter mal in meiner Gegend beobachtet und festgestellt, daß das nicht der Fall ist. Ich beobachte hier das Gegenteil. Es sind immer die gleichen Leute die rum rutschen und die benutzen immer die gleichen Wege. Viele Loipen, insbesondere in Wintersportgebieten, sind sogar ausgeschildert. Ok, die Loipe geht mal 5m neben der Straße und mal 20m, und in Ausnahmejahren auch mal auf der anderen Straßenseite, aber sie ist weitgehend eine Konstante. Für Leute die eine Skitour an Hand der Karte zusammenstellen planbar. daher würde ich anregen, Langlaufloipen, die abgetaut sind bzw. allgemein formuliert die vor Ort absolut nicht mehr nachvollziehbar sind, konsequenterweise auch aus dem Datenbestand zu löschen. Dagegen. Jörg -- There are only 10 types of people in the world: Those who understand binary, and those who don't... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kraftwerks-Karte (war: Open Windrad Map)
Am 02.02.2011 18:41, schrieb Stephan Wolff: Am 02.02.2011 14:43, schrieb Claudius: Am 02.02.2011 11:28, Stephan Wolff: Ich arbeite an einer Karte zu Kraftwerken und Stromnetzen. Wäre toll, wenn du dabei auch das erweiterte Schema http://wiki.openstreetmap.org/wiki/Key:generator:source für Quelle und Art der Stromerzeugung unterstützen könntest. generator:source und generator:output:electricity werden ausgewertet. Was vermisst du? Gruß, Stephan HI ! für welchen Bereich wertest Du aus ? auch Spanien ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
Am 02.02.2011 19:25, schrieb M∡rtin Koppenhoefer: Am 2. Februar 2011 19:11 schrieb malenkio...@malenki.ch: NopMap schrieb: Von daher würde ich anregen, Langlaufloipen, die abgetaut sind bzw. allgemein formuliert die vor Ort absolut nicht mehr nachvollziehbar sind, konsequenterweise auch aus dem Datenbestand zu löschen. Konsequent aus deiner Sicht wäre sicher, die erst gar nicht zu erfassen, oder? Wenn die wirklich nur so kurzfristig sind, wie Nop schreibt, bin ich auch dagegen, sie zu erfassen. Das ist nicht relevant, löschen, und im übrigen brauchen wir Relevanzkriterien für Langlaufloipen. Bei verschneiten (Fahr-)Wegen die surface=xy löschen, weil das ja aktuell auch nicht stimmt. Die meisten Grenzen sind vor Ort nicht nachvollziehbar (vom gelegentlichen Grenzstein mal abgesehen), bitte auch gleich löschen. ... und wo hören wir dann mit dem löschen auf? Wenn solche Daten beim Editieren stören, sollte man sich Gedanken machen wie man sowas besser hinbekommt - war hier ja schon mehrfach Thema. Wenn Loipen mal um 50m versetzt werden, na und? Der Loipengeher wird (so denn Schnee da ist) die dann immer noch finden. Sorry, da macht ihr euch die Sache zu leicht. Das mit dem Löschen macht mehr Ärger als das es hilft ... 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?
Am 02.02.2011 11:10, schrieb Frederik Ramm: Hallo, ich aegere mich ziemlich ueber die TMC-Daten in der OSM-Datenbank. Ich habe nicht die Uebersicht, wer da alles dran arbeitet und dran gearbeitet hat, also es besteht die Gefahr, dass ich jetzt einigen ehrbaren Mappern auf die Fuesse trete, aber wenn's nach mir geht, muss das Zeug raus. Da fühle ich mich doch sehr angesprochen. Ich hab auch die restliche Diskussion in diesem Thread überflogen und viel gutes dazu gelesen. Mein Eindruck ist: Marcus hat sich sehr viel Mühe gemacht ein funktionierendes TMC Schema zu entwerfen. Leider gab es sehr wenig Kommentare dazu. Alle die ich gerne dazu um eine Meinung gefragt hätte, haben immer nur abgewunken, und gesagt, mit TMC beschäftige ich mich nicht, da habe ich keine Zeit zu etc.. Ich meine mich zu erinnern, das ich auch dich gefragt hatte. Bei TMC ist halt das Problem: Eine Anwendung macht erst Sinn, wenn man die Daten hat, die Daten kann man erst Sinnvoll in ein Schema pressen, wenn man weiß was die Anwendung können soll. Deshalb habe ich den (bestimmt ausbaufähigen) TMC Validator geschrieben, der dazu geführt hat, das diese Daten importiert werden/wurden. Also haben wir erstmal Daten eingegeben. Jetzt, nachdem das Konzept von vielen Freiwilligen unterstützt wirst, kommst du Provokant ;-) daher und sagst, ich möchte alles rauswerfen. Die Botschaft, die bei einem neuen Mapper da ankommt, ist doch: Oh, ein kryptisch getaggtes Objekt. Das fass ich mal lieber nicht an. Ja genau so wie z.B. Grenzen (an denen irgendwelche Relationen hängen die ja so kompliziert sind ...) Mir erschliesst sich der Nutzen dieser Tags nicht - kann mir jemand mal eine praktische Anwendung zeigen, die diese Tags benutzt? Mir sieht das nach einem grossangelegten Designfehler aus. Da haette man von vornherein ein OSM-externes Mapping TMC-OSM bauen muessen, statt praktisch die ganze TMC-Datenbank auf OSM aufzupropfen. Danke, das du das erst jetzt sagst. Es wäre ja praktischer erst über ein Schema zu diskutieren und dann Daten zu importieren. Aber damals hast du Dich nicht beteiligt. Ich will jetzt nicht die Revolution anzetteln und morgen alle TMC-Daten loeschen (und ich aergere mich, dass ich der Geschichte nicht viel frueher widersprochen habe). Warum schreibst du das dann ein paar Absätze höher genau so. Egal, ich bin dir dankbar, das du das Thema auf die Tagesordnung gebracht hast. Denn ich denke am TMC Konzept gibt es durchaus noch Verbesserungsbedarf. (Wie bei der Linienbündel-Diskussion, den ÖPNV Relationen, ...) Viele der Punkte die du ansprischt, wie z.B. wenig sprechende Namen und das Einfügen von optionalen Daten via Bot sind vermutlich besser lösbar, aber ich hab mir das Konzept von Marcus angesehn und fand es nach durchsicht der TMC Daten-Struktur verständlich. Aber wenn es nicht irgendwelche ueberwaeltigenden Gruende dafuer gibt, warum diese Daten in OSM bleiben muessen, dann bin ich sehr dafuer, dass diejenigen, die diese Daten verwenden, sich da irgendwie etwas basteln, was weniger invasiv ist. Wenn jetzt an einem Objekt z.B. nur eine TMC-ID dranstehen wuerde und alles weitere - was fuer eine Klasse, was ist die naechste ID, die vorherige ID, wassweissich - waere extern, koennte man damit ja schon leben. Lass uns den Vortrag von Pascal abwarten. Oder mach einen besseren Vorschlag. Aber der Vorschlag einfach alles wieder raus-Löschen zählt IMHO nicht, das würden auch viele Mapper nicht verstehen, die diese Daten eingegeben haben, und das gerne auf Ihrem Navi benutzen können wollen. Ich denke allerdings das die Pflicht für einen Vorschlag nicht unbedingt bei diejenigen, die diese Daten verwenden liegt, sondern bei Dir, denn Dich stört ja die jetzige Form. Die Form wie die Daten eingegeben werden, kann dazu benutzt werden um TMC Meldungen in OSM zu visualisieren. Natürlich gebe es Verbesserungspotentzial, aber das gab es ja beim (alten) ÖPNV Schema auch, da trifft man sich und baut etwas um etc. Aber man löscht nicht einfach alles (schon eine Mail mit diesem Subjekt finde ich sehr provokativ). Ich vermute auch das die Verbesserungen eher dazu führen werden, das mehr Objekte mit TMC Daten getaggt werden würden. (Statt einen Punkt evtl. ganze Streckenabschnitte?) Ich suche also sozusagen eine Exit-Strategie. Ich will herausfinden, was und wem diese Daten nutzen, und dann ein Konzept machen, wie wir die Daten aus OSM entfernen koennen, ohne diesen Nutzen zu ruinieren. Ausser natuerlich, alle ausser mir finden diese TMC-Daten ganz knorke und haetten lieber noch viel mehr Tags der Art BPF:grq_23:tiwwhs_2:MegaCode = 281763. Damit eröffnest du aber ganz klar eine Relevanz-Diskussion. Ich will nur eine Datenbank für alle Geo-Informationen. Die soll OpenStreetMap heißen. Und da dürfen auch kryptische Tags rein, die ich nicht verstehe, solange sie sich nicht mit meinen beißen. Wenn z.B. der Xyz Verlag OSM Karten verwenden möchte und dafür einen Tag
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
Löschen klingt gut... und wenn wir gerade dabei sind die abgetauten Loipen zu löschen, können wir gleichzeitig auch die Berg-Wanderwege löschen, welche noch verschneit und nicht begehbar sind. Wenn jemand diese dann im Sommer wieder will, kann er sie ja wieder einzeichnen... Aber bitte nicht vergessen, diese nächsten Winter wieder zu löschen! Es darf ja nicht so sein, dass solche Wege im Winter auf der Map ersichtlich sind, obwohl diese nicht begehbar sind ;-) Am 02.02.2011 18:56, schrieb NopMap: Hi! Allgemein gilt ja bei OSM das Prinzip, Dinge zu mappen, die sich irgendwie vor Ort nachvollziehen lassen. Dinge die nicht mehr existieren, werden normalerweise entfernt, z.B. wenn eine Straße umgebaut oder ein Weg verlegt wurde. Es ist auch nicht erwünscht, flüchtige Informationen wie eine regenbedingte Wasserpfütze oder den Landeanflug eines Flugzeugs als way mit einzutragen. Nach dieser Regel wären gemappte Langlaufloipen wieder zu löschen, wenn sie aufgrund von Tauwetter spurlos verschwunden sind. Ab diesem Zeitpunkt stellt der Eintrag nur noch eine Falschinformation dar. Darüber hinaus sind diese toten Ways beim mappen echter Wege und Straßen sehr irritierend, wenn sie mit Wegen verwechselt oder versehentlich angeklickt oder verknüpft werden. Filter im Editor sind nur die halbe Miete, da sie auch alle echten Wege, die zusätzlich ein Loipentag tragen, verschwinden lassen. Es gab mal eine Diskussion, man sollte diese Loipen beibehalten, da sie ja im nächsten Jahr wieder genauso angelegt würden. Ich hab das diesen Winter mal in meiner Gegend beobachtet und festgestellt, daß das nicht der Fall ist. Eine Abfahrtspiste ist durch Baumschneisen und Lifte festgelegt, aber die Langlaufloipen werden nach Lust und Laune bei jedem Spuren neu verlegt. Ich konnte beobachten, daß sich der Verlauf teilweise innerhalb einer Woche zweimal verändert hat. Mal folgen sie einem Weg, mal führen sie an der gleichen Stelle 50m versetzt über eine Wiese. Sie sind noch deutlich kurzlebiger als ich erwartet hätte. Von einer Kontinuität sogar über Jahre hinweg kann nicht die Rede sein. Solche Falschinformationen empfinde ich als ziemlich störend - schließlich versuchen wir ein möglichst korrektes Bild der Realität herzustellen. Von daher würde ich anregen, Langlaufloipen, die abgetaut sind bzw. allgemein formuliert die vor Ort absolut nicht mehr nachvollziehbar sind, konsequenterweise auch aus dem Datenbestand zu löschen. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
Am 2. Februar 2011 21:07 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Am 02.02.2011 19:25, schrieb M∡rtin Koppenhoefer: Das ist nicht relevant, löschen, und im übrigen brauchen wir Relevanzkriterien für Langlaufloipen. In der Post des OP war von Langlaufloipen, die schon nach Wochen nicht mehr da sind, die Rede. Die Loipen, die Bestand haben (also z.B. jeden Winter bzw. wenn es Schnee gibt) weitgehend an derselben Stelle verlaufen, sollte man natürlich nicht löschen. 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 2. Februar 2011 14:07 schrieb Frederik Ramm frede...@remote.org: Natuerlich kann man das Problem umgehen, indem man aus OSM heraus auf die externe Datenbank linkt - aber das skaliert nicht, oder im Volksmund: Wenn das jeder machen wuerde ;) Komischerweise hast Du bei Photos eine andere Meinung. TMC ist halt m.E. nicht irgendeine externe Datenbank, sondern eine für das Routing und die Navigation extrem relevante Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
Am 02.02.2011 21:51, schrieb M∡rtin Koppenhoefer: Am 2. Februar 2011 21:07 schrieb Ulf Lampingulf.lamp...@googlemail.com: Am 02.02.2011 19:25, schrieb M∡rtin Koppenhoefer: Das ist nicht relevant, löschen, und im übrigen brauchen wir Relevanzkriterien für Langlaufloipen. In der Post des OP war von Langlaufloipen, die schon nach Wochen nicht mehr da sind, die Rede. Die Loipen, die Bestand haben (also z.B. jeden Winter bzw. wenn es Schnee gibt) weitgehend an derselben Stelle verlaufen, sollte man natürlich nicht löschen. Zitat NopMap: Nach dieser Regel wären gemappte Langlaufloipen wieder zu löschen, wenn sie aufgrund von Tauwetter spurlos verschwunden sind. Ab diesem Zeitpunkt stellt der Eintrag nur noch eine Falschinformation dar. Sowas mag ich nicht sonderlich ;-) Nun bin ich kein Skifahrer, hab aber durchaus schon häufiger auf Waldparkplätzen mitten im Sommer einen Loipenplan für Langläufer gesehen. Da gibt es jetzt bestimmt (jemand wissender möge mich korrigieren) eine ziemliche Bandbreite zwischen ist auf Schildern und einschlägigen Büchern eingetragen und im Winter immer gespurt, über in der Hochsaison gespurt bis zu hat man einmal ausprobiert und dann nie wieder. Das Problem der Datenaktualität würde ich dabei aber gerne den Langlaufgehern und nicht dem Tauwetter überlassen ... 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 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] cycleway=track vs. cycleway=opposite_track
Am 02.02.2011 22:32, schrieb Pascal Neis: Folgendes Problem: Darf ein Way der als cycleway=track und auch als Einbahnstraße getaggt ist in verkehrter Richtung mit dem Fahrrad befahren werden ? nein, nur bei cycleway=opposite / opposite_lane /opposite_track. Chris ___ 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] cycleway=track vs. cycleway=opposite_track
Am 02.02.2011 22:32, schrieb Pascal Neis: Hi, bin vor ein paar Tagen auf ein Fahrrad-Routing-Problem mit Ways die ein cycleway=track-Tag besitzen aufmerksam gemacht worden. (danke Sven :) ) Folgendes Problem: Darf ein Way der als cycleway=track und auch als Einbahnstraße getaggt ist in verkehrter Richtung mit dem Fahrrad befahren werden ? Laut der Tag-Beschreibung im Wiki[1] eher nein! Ansonsten müsste er als cycleway=opposite_track gemappt sein. Laut Tagwatch gibt es um einige mehr cycleway=track als cycleway=opposite_track vgl.[2]. Sollte aber dennoch ein Way mit cycleway=track mit dem Fahrrad in falscher Richtung befahrbar sein ? In Heidelberg machen das alle Radfahrer so ... :) Kommt drauf an, ob du ein legales Routing anbieten möchtest oder nicht. ;) Das musst du mit deinem Gewissen etc. ausmachen. Meiner Meinung nach sollte ein Routing nur auf legalen Wegen zu routen. 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.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 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?
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?
On 02.02.2011 16:35, Jan-Benedict Glaw wrote: On Wed, 2011-02-02 16:19:59 +0100, Bernd Wurstbe...@bwurst.org 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] Kraftwerks-Karte (war: Open Windrad Map)
Am 02.02.2011 20:57, schrieb Jan Tappenbeck: für welchen Bereich wertest Du aus ? Planet Erde. auch Spanien ? Ich glaube auch Spanien gehört dazu. Teste doch mal http://toolserver.org/~osm/styles/?zoom=11lat=40.50466lon=-3.57915layers=B000F0FFF0FFFF Die Karte hat leider ein massives Performanceproblem und ich weiß nicht, wie ich es lösen kann. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exzessive Einzelrequests an die API
Hallo, On 01/12/11 01:31, Frederik Ramm wrote: irgendein - pardon - Idiot sendet seit Tagen taeglich ueber 100.000 einzelne /api/0.6/node/123-Requests an die OSM-API. Die Person kommt aus Deutschland, aus dem Arcor/Vodafone-DSL-Dialin-Netz. Die IPs werden immer gesperrt, das haelt dann, bis sie sich das naechste Mal einwaehlt. Das Problem haelt an. Vielleicht ist es doch kein Idiot, sondern nur jemand, der irgendein Programm versehentlich unsachgemaess bedient. Naehere Untersuchungen ergeben, dass die Abfragen mit Perl (LWP) gemacht werden, und zwar scheint es, als ob systematisch alle Nodes eines bestimmten Changesets abgefragt werden. Kennt jemand irgendein Perl-Tool, das sowas macht? Man gibt eine Changeset-ID an und dann laedt es irgendwie was runter? Normalerweise hat man die Nodes ja alle schon, wenn man das Changeset heruntergeladen hat, aber dann macht das Skript wohl fuer jeden Node nochmal extra einen GET-Request - eventuell, um die letzte Version festzustellen? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track vs. cycleway=opposite_track
Im Prinzip nein. Allerdings ist es nicht korrekt durchdacht. Besser cycleway=track (gleich in die Richtungen gebaut und befahrbar wie die Straße), left (auf linker Seite), right, both und dazu bicycle:oneway=no bzw bicycle:oneway=yes um vom oneway=yes // oneway=no abweichende Regelungen der Befahrbarkeit darzustellen. Evtl könnte ja sogar der Fall sein, dass Fahrräder auf der falschen Seite (bezogen auf rechts- oder linksverkehr) mit der Einbahn fahren dürfen. cycleway=opposite ist nur halb zu Ende gedacht - es deckt einfach keine ungewöhnlichen Situationen ab. On 02.02.2011 22:32, Pascal Neis wrote: Hi, bin vor ein paar Tagen auf ein Fahrrad-Routing-Problem mit Ways die ein cycleway=track-Tag besitzen aufmerksam gemacht worden. (danke Sven :) ) Folgendes Problem: Darf ein Way der als cycleway=track und auch als Einbahnstraße getaggt ist in verkehrter Richtung mit dem Fahrrad befahren werden ? Laut der Tag-Beschreibung im Wiki[1] eher nein! Ansonsten müsste er als cycleway=opposite_track gemappt sein. Laut Tagwatch gibt es um einige mehr cycleway=track als cycleway=opposite_track vgl.[2]. Sollte aber dennoch ein Way mit cycleway=track mit dem Fahrrad in falscher Richtung befahrbar sein ? In Heidelberg machen das alle Radfahrer so ... :) dankeviele gruesse pascal [1] http://wiki.openstreetmap.org/wiki/DE:Key:cycleway?uselang=de [2] http://tagwatch.stoecker.eu/Germany/De/keystats_cycleway.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Performanceprobleme bei Mapnik/SQL
Am 02.02.2011 00:01, schrieb Kolossos: Vielleicht wäre es ja eine Idee erstmal einen temporären View auf power=* innerhalb der BBOX zu kreieren und dann darauf in den folgenden 20 Abfragen auf diesen stark reduzierten Datensatz zuzugreifen. Dafür müsste man vermutlich die Syntax des mapnik-styles um einen Parameter erweitern. Leider verstehe ich nicht, wie aus den x,y,z-Koordinaten und der SELECT-Anweisung in der xml-Datei eine SQL-Abfrage mit geografischem Filter entsteht. Erstaunlicherweise werden manche Tiles nicht gerendert, obwohl sie keine oder sehr wenige Elemente mit power=* beinhalten (z.B /tiles/powermap/10/536/328.png), während andere Tiles mit viel mehr Objekten berechnet werden (z.B. /tiles/powermap/10/537/327.png). Scheinbar werden viel größere Bereiche als ein Tile geografisch selektiert. 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 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] Löschen von falschen und abgetauten Loipen
Hi! Joerg Fischer-2 wrote: Dann löschen wir auch im Sommer kleine Bäche? Ist ja kein Wasser drin? Hier sind zur Zeit ein paar Treppen wegen Eisglätte unpassierbar. Auch gleich löschen? Kaputte Ampel? Sessellifte die im Sommer außer Betrieb sind? Biergarten / Ausflugsgaststätten die nur im Sommer geöffnet sind? Alles was Du aufgezählt hast, ist nach wie vor sichtbar, vor Ort nachvollziehbar und wird seine Position auch nicht verändern. Daher ein völlig anderes Thema. Joerg Fischer-2 wrote: Ich beobachte hier das Gegenteil. Es sind immer die gleichen Leute die rum rutschen und die benutzen immer die gleichen Wege. Viele Loipen, insbesondere in Wintersportgebieten, sind sogar ausgeschildert. Dann trifft es nach Deiner Ortskenntnis auf Deine Gegend nicht zu. Ich rede ausschließlich von leicht flüchtigen Einrichtungen, nicht ausgeschildert, nicht markiert, keine Tafeln und restlos verschwunden. Sowas gehört meiner Ansicht nach nicht in einen Datenbestand, nur auf der Basis daß es vielleicht mal wieder so ähnlich ungefährt in der Nähe angelegt werden könnte. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Loschen-von-falschen-und-abgetauten-Loipen-tp5985807p5987751.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] Performanceprobleme bei Mapnik/SQL
On 03.02.2011 01:45, Stephan Wolff wrote: Objekten berechnet werden (z.B. /tiles/powermap/10/537/327.png). Scheinbar werden viel größere Bereiche als ein Tile geografisch selektiert. Der Server rechnet Metatiles. Das sind in der Regel 64 einzelne Tiles die am Stück gerechnet und gespeichert werden. Dazu kommt noch ein wenig Überlappung an den Rändern damit die Schnittgrenzen zusammenpassen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
Am 02.02.11 21:51, schrieb M∡rtin Koppenhoefer: In der Post des OP war von Langlaufloipen, die schon nach Wochen nicht mehr da sind, die Rede. Die Loipen, die Bestand haben (also z.B. jeden Winter bzw. wenn es Schnee gibt) weitgehend an derselben Stelle verlaufen, sollte man natürlich nicht löschen. Das aktuelle Problem ist wohl eher, ob die Loipen im Jahr 2 nach Bing noch mit den bisher in OSM erfassten Geodaten zusammenpassen. Derzeit werden ja massiv Knoten nach Luftbildern geschubst. Da passt eine nach schlechten GPS-Daten gezeichnete Spur irgendwann nicht mehr. Hochgeladene GPX-Tracks helfen da wenig, weil man ja nicht weiß, ob derhjenige auf Ski oder Sohle unterwegs war. Noch was anderes, neulich gesehen: Offizielle Langlaufloipen sind per Schilder für Fußgänger und Hunde verboten. Auch wenn mir diese Strecken nicht unbedingt gespurt vorkamen. Solche Loipen zu mappen macht mMn Sinn. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
