Momentan tragen wir vorübergehende Streckensperrungen wegen Baustellen ja noch als access=no o.ä. ein (wenn die Maßnahme nicht ganz kurz ist). Angesichts der Tatsache, dass viele Navi-Apps heute aber auch schon HD-Traffic nutzen (Magic Earth sogar kostenlos), frage ich mich, ob das noch zeitgemäß ist. In den HD-Traffic-Daten sind ja diese Sperrungen auch enthalten – und das aktueller als OSM es je leisten könnte.
Was spricht dafür, access-Tagging temporärer Sperrungen zu unterlassen und nur auf HD-Traffic zu setzen?
Die Information kommt beim Navi fast in Echtzeit an. Keine wochenlangen Verschiebungen (sowohl Einrichtung als auch Aufhebung der Maßnahme) durch den Update-Zyklus, keine unnötigen Umwege.
Kein Abwägen mehr, ob die Maßnahme überhaupt „lang genug“ dauert, um in OSM erfasst zu werden.
Folge davon: auch kurze Maßnahmen (1-2 Wochen) werden beim Routing berücksichtigt.
Kein vergessenes Rücktaggen mehr, weil kein Mapper den Abschluss der Maßnahme zeitnah mitbekommen hat.
Was spricht dafür, access-Tagging beizubehalten?
HD-Traffic erfasst nur Autostraßen – Radfahrer, Reiter und Fußgänger profitieren davon nur eingeschränkt.
HD-Traffic ist in den meisten Apps eine Bezahloption, die nicht jeder aktiviert hat; access=* gibt’s gratis.
access-Daten sind rein offline – HD-Traffic ist unterwegs auf mobile Netzverbindung angewiesen.
Die kombinierte Nutzung von access=* und HD-Traffic sorgt zumindest dafür, das neu eingerichtete Sperrungen sofort im Routing berücksichtigt werden. Aufgehobene sind dafür allerdings so lange wirksam, bis sie auch aus dem Offline-Kartenmaterial verschwunden sind.
Es gibt immer noch Leute (wie mich) die keine Flatrate haben , und HD-Traffic nicht nutzen können. Aber auch für die Routenplanung am PC halte ich die Beibehaltung des access-Tagging für sinnvoll.
Frage zum access-Tagging: Wie wird die Dauer der voraussichtlichen Sperrung korrekt eingetragen ?
access:conditional=no @ 2018-01-01-2018-07-31 ?
In beiden Fällen gibt es keine Probleme wenn vergessen wird die Beschränkung wieder aufzuheben, da der Zeitrahmen ja bereits angegeben ist.
Solche Informationen komplett auf einen kommerziellen, externen Dienstleister auszulagern widerspricht dem Ansatz von OSM ziemlich - warum machen wir das nicht auch mit allen anderen Daten?
HD sagte mir in diesem Zusammenhang jetzt nichts (habs mir nun natürlich ansatzweise angelesen). Verwendet das auch die TMC-Tags? Werden selbige überhaupt noch gepflegt?
Ja. Aber woher kommt diese Information? Ich denke, das ist das Problem.
Ich kenne diese 6-Monate-Regel, aber die gilt bei der Verwendung von :conditional m. E. nicht, wenn man es richtig macht.
Mit :conditional auch so machbar.
Dito.
Hier sprichst du es schon an: was sind das für Daten? Woher kommen sie, für wen sind sie, wer darf und kann sie wie nutzen?
Also ich denke, für unseren Teil sollte man die Anwesenheit des HD-Krams da weitestgehend ignorieren. Was ein Routerhersteller macht, der OSM- und andere Daten zusammen auswertet, ist ihm selbst überlassen.
Ich grübel gerade. Bist Du Dir da sicher? Ich dachte immer, HD-Traffic ist ein reiner Verkehrslage-Dienst, sprich Staus inkl. Sperrungen wegen Bergungsarbeiten nach Unfall, aber keine Sperrungen wegen Bauarbeiten. Vielleicht irre ich mich auch oder es hat sich da was geändert.
Ein offener Live-Traffic / temporary events / messaging service für kurzfristige Daten zusätzlich zu OSM wäre wohl die beste Lösung (OpenEventsMap?). Wenn alle OSM-basierten Navis so eine OpenEventsMapeinbinden würden, wäre zwar die Datenmenge für Live-Traffic wohl noch ziemlich dünn, aber für Sperrungen wäre es ideal. Dann gäbe es jeden Monat frische OSM Karten und z.B. vor jeder Fahrt wird die OpenEventsMap nach Sperrungen befragt. Die Daten kämen dann von uns.
Für Mittel- und Langstreckennavigation nutze ich deswegen Waze, da es eben so eine reichhaltige Verkehrskommunikation (Unfall, Stau, Sperrungen(!), Blitzer, …) bietet.
Es ging in keiner Weise darum, HD-Traffic mit OSM-Daten zu beliefern oder für irgendwen zu taggen, sondern darum, temporäre Sperrungen in naher Zukunft gar nicht mehr in OSM einzutragen, sondern es diesem Dienst zu überlassen, die fragliche Information zum Anwender zu transportieren.
Wenn wir sagen, dass eine Sperrung von zwei Wochen der Lokalzeitung zu entnehmen und nicht in OSM einzutragen ist, dann nennst du das ja auch nicht „Taggen für die Lokalzeitung“, oder?
Noch mal zur Klarstellung, bevor die Diskussion sonstwohin abdriftet:
HD-Traffic ist ein kommerzieller aktueller Verkehrslagedienst unter Federführung von Tom-Tom, der aus anonymisierten Bewegungsdaten von Mobiltelefonen gewonnen wird und bislang sehr gute zeitnahe Werte liefert. Außer den Echtzeitdaten zum Verkehrsfluss werden dort auch gemeldete Sperrungen etcetera mitgeliefert. Sorry, ich dachte, das wäre bekannt, wenn sogar ich es weiß (ich bekomme technische Neuerungen selten als erster mit). Gibt es seit elf Jahren. Mehr dazu bei Wikipedia: https://de.wikipedia.org/wiki/Verkehrslagedienst
Es ging mir um die Frage, ob solche Dienste (die auch gern communitybasiert sein und Waze heißen können, das kannte ich bis jetzt noch gar nicht, danke für den Tipp) die Funktion der Information über vorübergehende Sperrungen beliebiger Dauer nicht deutlich besser und anwenderfreundlicher übertragen als ein statischer Eintrag in OSM (auch wenn ich eine Baustelle conditional mappe, kann sie drei Monate länger dauern, ohne dass jemand das Tagging anpasst) und wir diese Information daher in naher Zukunft gar nicht mehr statisch in die Karte einpflegen, sondern sie solchen Diensten überlassen sollten (vielleicht entfernt vergleichbar mit Spritpreisen, die sich ja auch viel zu kurzfristig ändern, um in OSM sinnvoll erfasst werden zu können).
Es geht mir nicht um eine Verquickung von OSM mit kommerziellen Anbietern und auch nicht darum, kommerzielle Dienste aus der OSM-Community mit Daten zu versorgen, sondern um eine sinnvolle Aufteilung von Informationsflüssen. Wer noch auf der Palme sitzt, bitte wieder runterkommen.
Es ging mir darum, darüber nachzudenken, ob es nicht sinnvoll wäre, statische Geoinformation (die OSM konkurrenzlos gut kann) und dynamische Nutzbarkeit (für die OSM-Navi-Apps mit ihren meist wochenlangen Aktualisierungszyklen zu langsam sind) voneinander zu entkoppeln.
Nein, ich bekomme dafür kein Geld von Tom-Tom. Ich merke nur, seit ich Magic Earth nutze, wie gut und zuverlässig die HD-Infos sind.
Dann ist es eine Frage der Aktualisierung der Daten. Mapfactor macht es glaube ich monatlich. Und graphopper sogar täglich.
Eine Baustelle die längere Zeit zur “Vollsperrung” führt sollte m.E. schon in die Daten.
Über das wie wäre es eben schön, wenn auch Mapnik das berücksichtigt. aber dort fehlt es ja ebenfalls. Oder wer kennt eine Baustelle, die taggenau in Mapnik geändert/angezeigt wird?
Einen eigenen Live-Traffic-Dienst hochzuziehen, halte ich aber für nicht machbar. Wie Du schon geschrieben hast, braucht’s eine ordentliche Datenmenge, damit was ordentliches rauskommt. Aber man muß auch bedenken, daß man aus den einzelnen Bewegungsprofilen das korrekte Verkehrsmittel erraten muß. Selbst Google hat sehr lange dafür gebraucht, um das hinzubekommen.
Von Waze bin ich gerade weg, weil Waze halt nur Daten von Wazern zur Verfügung hat - und davon gibt es hier in S-H viel zu wenige. Waze hat sich auf meiner Pendelstrecke immer häufer Mist zurechtgeroutet. Aber wir haben hier sehr engagierte Mapper und einen Bundeslandmanager, der wirklich alles, was der Landesbetrieb Straßenbau an Baustellen raushaut, sofort einpflegt.
In Kaltenkirchen gibt’s eine baustellenbedingte Straßensperrung, um die TomTom herumroutet, Magic Earth aber nicht. Spontaner Erklärungsansatz wäre, daß Magic- Earth nur ein Subset der HD-Infos bekommt (vielleicht runter bis Kreisstraße) und deshalb auch kostenlos angeboten werden kann. Zu dem Thema werde ich mal beim Support anklopfen.
Sehe ich ganz genauso. Die Stauinfos sind sehr präzise, auch in ländlichen Gegenden. ETA bei ME weicht selbst bei Routen von 100km oder mehr selten um mehr als 3-4 Minuten ab.
was mich etwas stört, ist der Tunnelblick auf DE. OSM ist ein weltweites Projekt, und nun für einen - winzigen - Teil der Erde alles auf den Kopf zu stellen, halte ich nicht gerade für sinnvoll.
Wer hat denn einen Tunnelblick auf DE? HD-Traffic gibt’s derzeit in 43 Ländern. Und wer hat vor, „alles auf den Kopf zu stellen“? Und davon abgesehen gibt es schon eine Menge nationaler Besonderheiten in OSM. Z.B. was hw=trunk in GB und in DE bedeutet. Dann kann man auch sagen, in Europa werden vorübergehende Sperrungen nicht getaggt, weil der Anwender diese Information über Dienst xy viel besser bekommt als über OSM-Offlinekarten.
Ich habe das nicht gefordert. Ich habe nur gefragt. Offenbar wird aber weniger als nichts davon gehalten.
Also beenden wir das hier lieber und umfahren weiterhin Baustellen, die es schon seit drei Wochen nicht mehr gibt. Tut mir leid, die Frage überhaupt gestellt zu haben
HD-Traffic ist nicht offen, halte ich nicht für eine gute Wahl.
Aber Grundsätzlich fehlt so was schon der Ansatz von Waze gefällt mir ganz gut. Aber das gehört nicht direkt in die OSM-Daten also Kartendaten sondern da muss eine App bzw. Navigerät diese Routing/Verkehrsdaten-Daten nachladen und zu aktualisieren können.
also z.B. OSMand müsste dann sowas können… und erheben können… bzw. den Nutzern Staus, Baustellen, Sperrungen melden lassen… selbst gewisse Dinge erkennen können usw.
Vielleicht kann man sich auch mit Waze oder anderen zusammentun, weil hier spielen auch die großen Player wie Apple, Google mit. Die durch Android und iPhone maßen an Daten schon haben… Hier kann man schon vorhersagen machen… z.B. wie am Montag um 7:00 der Verkehr sein wird…
Natürlich nicht. Da ist es jetzt aber noch drin, in Form eines access=* oder access:conditional=*. Genau das war doch meine Überlegung: die aktuellen Verkehrslagedaten von den Kartendaten zu trennen.
Und ob der Dienst jetzt HD-Traffic oder Waze oder Wrdlbrmpft heißt, ist mir auch wurscht
Baustellen die vergessen wurden hatte ich auch schon … aber dann kann man mal eine Node in die OSM-Karte setzten… wenn es bei mir im Umkreis ist mach ich das bzw. schreib was dazu…
Es wurden auch schon mal automatisch Nodes platziert… bei so was… wenn Baustellen schon zu alt waren… Manches übersieht man auch… z.B. Baustellen von Häusern oder so…
Wi fest ist das?
Das mit den Jahreszahlen findet man nämlich nicht im Wiki, da das rein auf wiederkehrende Restriktionen ausgelegt ist, wöchentliche (Öffnungs-)Zeiten am besten, bis hin maximal zu “Jedes Jahr April bis Oktober” o.ä. Einmalige Ereignisse kommen im Weiki zu access:cond. nicht vor …
Hatte mal genau wegen einer Baustelle nach sowas gesucht im Wiki …
, und HD-Traffic nicht nutzen können. Aber auch für die Routenplanung am PC halte ich die Beibehaltung des access-Tagging für sinnvoll.
