Ich würde eher 70-80% sagen. Speziell im Kreuzungsbereich (Überland) ist oft Anfang und Ende massiv versetzt. Teilweise ist die Beschränkung auch nur in eine Richtung, da man beim Abbiegen nur die eine Fahrspur queren kann.
Wenn die Node des Schildes im Weg liegt, könnte man genauso forward, … angeben.
Ich bin ein Befürworter des Wegweisermappings. Bei ungünstiger Empfangssituation (Wetter, Bäume, Häuser, etc.) helfen einem, um die richtige Straße zu finden, die Wegweiser sehr gut weiter (vorausgestzt das Navi wertet sie aus). Es gibt auch schwierige Situationen auf Autobahnen, z.B.: zwei dicht gefolgte Abfahrten, wobei die zweite zweispurig ist und sich kurz nachher teilt. Da wird es mit Ansagen ähnlich “nächste Abfahrt” “rechts halten” etc. sehr knapp. Aber die Auswertung der Destination (“in 200 Meter Abfahrt Richtung Hinterholz nehmen”) macht es deutlich einfacher.
Einen Algorithmus, was auf dem Wegweiser steht, kann man nicht entwickeln, da es selbst Einheimischen manchmal nicht möglich ist, zu eruieren, warum genau die Stadt auf dem Schild steht.
Klar kann man die Wegweiser mappen und klar sind sie hilfreich, jedoch nicht zwingend. Was die zwei dicht gefolgte Abfahrten angeht, haben die “Profis” eine extra Meldung die auf einem “extra” Tag für solche Situation basiert.
Nochmals: Wegweiser zu mappen ist flüssiger als Wasser. Maxspeed oder access lassen sich mehr oder weniger am highway unterbringen. Und bei den anderen 95 % der Wegweiser soll man vor Ort schauen, was sie bedeuten. Ein Navi soll einen bei der Zielfindung unterstützen. Was habe ich als Fahrer davon, wenn mir das Kastl alle 20 Sekunden ein Verkehrszeichen ansagt? Spätestens nach dem dritten 70er-Taferl in einer Minute schmeiße ich es entnervt aus dem Fenster. Wenn jemand unbedingt die Verkehrszeichen mappen will, so soll er es als eigenständigen Punkt mappen und nur ja in keine Relation einbinden. Damit vergrault man nicht nur Neueinsteiger, sondern auch den einen oder anderen Altmapper.
Wenn man eine vernunftige Navi baut dann blinke ein Verkehrszeichen nicht immer dort, wo ein neuer Straßenabschnitt mit der gleichen Maxspeed kommt, sonder man hat in einer Ecke eine anzeige die die maximale zulässige Geschwindigkeit anzeigt.
Für alle Kritiker: In zukunft werden alle Autos die sog. ADAShttp://de.wikipedia.org/wiki/Advanced_Driver_Assistance_Systems haben.
Eines der wichtigsten Elemente ist die Maxspeed. Ein Auto fährt, wenn man diese Option verwendet, nach Navi Anweisung nur die maximal zulässige Geschwidigkeit auf einer Strecke.
Niemand außer OSM kann zeitnah solche Änderungen liefern.
Ein KO Kriterium für Google beispielsweise. Falls die OSM Community mitmacht.
Also ich glaube, dass bei dieser Diskussion zwei Dinge vermischt werden:
Zum einen der Umstand, dass osm eine Geodatenbank ist, welche die exakte Lage von Objekten in der Natur festhält und zum anderen widerum, dass die osm-Geodatenbank eine vortreffliche Grundlage für routingfähiges Kartenmaterial darstellt.
Bei maxspeed kann man zB das Verkehrszeichen neben der Straße mappen - das Feature (die Eigenschaft maxspeed) kann als Attribut dem way angehängt werden - hat aber nix mit der Position des Taferls selbst zu tun. Und genau so müsst die Herangehensweise für “Stop” oder “Vorrang geben” sein. Das eine ist eine Eigenschaft am Weg und das andere ist die Position des Taferls (welches die Eigenschaft des Weges begründet).
Hier einen Konsens zu finden ist die Kunst.
@Wolfgang B:
Wer nicht will, der muss nicht. Es gibt viele die mappen Straßen oder Bäume aber keine Häuser - soll jeder handhaben wie er will. Der Rest (ob Stop ausgewertet und angezeigt wird) obliegt der Navi-Software oder den Einstellungen derselben - hat aber eigentlich nichts mit osm zu tun.
Mein Navi/Auto kann mich auch ab zB 130km/h akkustisch warnen - wir sprechen hier aber von können - nicht müssen.
Hallo Thomas,
richtig! Das eine ist die Abbildung der physikalischen Realität, das andere sind die Routingeigenschaften.
Natürlich kann man beides machen. Eigentlich ist es ein goldener Weg: Die Routingsoftware benutzt nicht für die Auswertung die Verkehrsschilder (Maxspeed) sondern nimmt dafür die Attributte der Straße. 3d Modelling im Detail nimmt die Schilder als Punkte neben der Straße und malt sie in 3D da, wo sie tatsächlich physikalisch stehen.
Es gibt ja nicht ohne guten Grund die Empfehlung: “Ein Objekt in der Realität, ein Objekt in OSM” (https://wiki.openstreetmap.org/wiki/DE:Good_practice), denn das sichtet die Erweiterbarkeit und abbildung der Wirklichkeit, soweit es das Modell der OSM_datenobjekte zuläßt.
Wenn ich mit einem realitätsnahen Modell den Standort des Schildes/Ampel gemappt habe, kann ich die Daten immer in eine spezialisierte ungenauere Darstellung (maxspeed=* auf dem Weg in einer fiktiv aus den daten erstellten OpenCarMap) für den entsprechenden Anwendungsfall überführen. Andersherum ist es aber nicht möglich, aus maxspeed=* am Weg, den genauen Stand- oder Anbringungsort des Schildes zu rekonstruieren, so das man mit dem vermeitlich einfacherem Modell, unötig, potenziell in anderen Anwendungsfällen nutzbare Daten, wegwirft. Außerdem hat man durch solche beschränkten Spezialtags immer Probleme mit späteren Ergänzungen, die das Objekt genauer beschreiben, welches sie respräsentieren sollen.
Natürlich gehört zur realitätsnahen Erfassung eines Schildes/Ampel auch die maschinenlesbare Angabe auf welche Spur bzw. welchen Wegabschnitt es sich auswirkt (Relation), denn man will ja möglichst gut die Realität erfassen. Außerdem kann ich ein einfaches Schildmodell als Knoten neben der Straße, später zu einer vertikalen Darstellung eines ca. 8 cm Kreises mit linienformiger einseitig befestigter Platte erweitern, wenn ich das Schild irgendwann mal besser repräsentieren muß.
Ich hoffe auch, das da gute Tools entstehen werden, die das ganze vereinfachen, ohne das sie den Erfahrenen benutzern die Möglichkeit nehmen, sich aus den OSM-Primitiven, ihr Wunschobjekt zusammenzubauen. Die Zukunft könnte dann vielleicht so ausehen, das man eine Option “Verkehrszeichen erstellen” hat, und der Wizard dann den Schildstandort, sowie den Beginn udn das Endes des Wirkungsbereiches erfragt und die Relation automatisch erstellt.
Leider ist es aber so, das die vergleichweise guten Modelle wie z.B. das Oxomoa-Schema (das hat zwar auch noch keleine Fehler wie die fehlnede “Bahnsteigrelation”) bisher eher nicht durch entsprechende Tools hut unterstützt wurden, mit dem Ergebnis, das der ÖPNV von weniger Leuten erfaßt wird, als notig. Da OSM ein Crowdsourcing Projekt ist, sollte möglichst alles idiotensicher sein, aber ohne das es fortgeschrittene Mapper nervt, wie das üblicherweise oft z.B. bei bevorzugt Windowssoftware der Fall ist, wo der Wizard keine Hilfe sondern eine “10x weiter-klicken”-Belätigung ist und man es ohne viel schneller hinbekommt.
Die Ansätze stehen sich, wie ich oben versucht habe aufzuzeigen, nicht im Weg. Für das Routing wird man die Daten eh immer passend aufbereiten müssen, da kann man sowas wie das übertragen der Eigensschaften auf die wege gleich mit machen, was aber im Einzelfall eh vom verwendetem Navi abhängt. Denkbar wäre auch der Ansatz, das sich die Autorouting-Community aus der allgemeinen realitätsnahen Geodatenbank ein gemeinsames Zwischenformat “OpenCarMap” erstellt, wo die grundsätzlichen Sachen, wie das Umrechnen der Schilder auf Wegattribute, etc. schon gemacht wurde, so daß die Weiternutzer den Rechenaufwand dafür einsparen.
Lieber noch 100 weitere “wartungsfreundliche” Tags für jedes Verkehrszeichen, als das man mal ein vernüftiges richtungsgebundenes Vehkehrsbeeinflussungsobjekt-Modell dafür zusammen bastelt, oder was?
Die realen Schilder kann man wenn sie gleich sind, bei der Konvertierung der Daten in das Format des Routers ja zusammenfassen und z.B. nur Hinweise bei sich ändernder Geschwindigkeit ausgeben, was sowieso Aufgabe der Navi-Software ist.
Da muß es dann endlich vernüftige Softwareunterstützung dafür geben.
Genau so ist es! OSM will ja grundsätzlich eine maschinenlesbare Respräsentation der Realität, in Form einer Geodatenbank, sein.
Das die Geodatenbank maschinenlesbar ist, können dann Rechner und deren Software so allerei Sachen mit den daten anstellen: Karten malen, Routen berechnen, 3D Landschaften erzeugen, etc. wobei für den entsprechenden Zweck die Daten aus der Datenbank immer passend aufbereitet werden müssen. Somit ist Routing nur eine Nutzung der Daten und sollte grundsätzlich mit den Daten in der Datenbank nichts zu tun haben.
Was passiert denn in der Realtät, was man in OSM erfassen müßte bei einem z.B. Ortsschild (was ja ein implizites maxspeed=* ist, dessen doppelte Erfassung nur zu Inkonsitenzen führt)?
Der Autofahrer fährt aus dem Ort heraus, sieht das Ortsschild und drückt freudig ab diesem Zeitpunkt das Gaspedal durch. Irgendwann unterwegs kommt, vielleicht nach ein paar Wegweisern zwischendurch, dann mal ein maxspeed=40 und der Fahrer bremst, weil das vorherige maxspeed=* durch das Ortsschild da zu Ende ist. Ist maxspeed=* deswegen eine Eigenschaft der Hauptstraße, die durch den Ort führt?
Der Konsens muß zwischen Benutzerfreundlichkeit der Erafssung und dem Ende der Datenkakophonie, die bisher immerhin noch halbwegs funktioniert hat, gefunden werden.
Routing hat mit den Daten nichts zu tun. Routing nutzt die Daten, die erfasst werden. Wir haben bereits viele Elemente des Routings in der OSM Datenbank vorhanden:
Es ist ja absolut kein Problem, das diese Merkmale der Realität auch erfaßt werden, aber was machen ich z.B. im Moment, wenn ich morgen von 'nem super DOP unbedingt den Gullideckel in der linken Spur der Straße vor meinem Haus mit man_made=man_hole erfassen will?
Da die Spur nicht mal 'ne Linie ist, die ich mit der gleichwertigen Fläche ersetzen könnte und anschließend dann dort den Gulli einzeichen könnte, muß ich zu aberwitzigen Konstruktionen aus Knoten, die dann mit neu zu schaffenden lane-Lage-Tags, virtuell auf die nicht sichtbar respräsentierte Spur abgebildet werden arbeiten. Schon gibt es zwei neue Tags lane:left:x=* und lane:left:y=* beim ersten Gulli geht es ja noch, danach wird es schwierig, ich kann nur hoffen das niemand den Weg teilt oder wenn er es tut, dann hoffentlich kein Neumapper ist, der vergißt, die Koordinaten meines Gullis Relativ auf der Linie zu updaten.
Was ich damit sagen will: Das momentane Erfassungsschema ist da zu beschränkt und auf lange Sicht nicht wirklich Zukunftskompatibel.
