Verkehrszeichen als eigenständiger Node?

Ich frage mich generell welche Information man daraus ableiten können soll. Solange keine Richtung angegeben ist, kann sowieso niemand auswerten, für welchen Teil der Straße das eingetragene Verkehrszeichen gilt.

Ist doch schnuppe. Verkehrszeichen werden von keiner Anwendung ausgewertet, sondern sind bestenfalls Dekoration. Soll sie doch jeder dahin malen, wo er will - auf die Straße oder daneben.

Möchte man die Verkehrsschilder benutzen, muss ein use case vorliegen.
Generell sind sie natürlich dann hilfreich, wenn sie konsequent angewendet werden.
Dazu bräucht man eine Tabelle in der die Behandlung einzelner Schildarten und derer Anbringung in der OSM untersucht wird.
Für eine der wichtigsten Funktionen - Geschwindigkeitsbegrenzung - taggen wir den Maxspeed, diese Schilder brauchen wir also nicht.
In der Tabelle:
Schild | Nutzung im Verkehr | Verwendung in OSM stünde also
Geschwindigkeitsbegrenzung | ... pla pla pla.. | Tag maxspeed=<value>

Abbiegeverbote stünden als Relation an dem Node

Warnschilder müßten an den Vektor damit die Navigation sie verwenden kann, wobei die Richtung angegeben werden müßte (wie?). Bei einer Einbahnstraße ist es hingegen unkompliziert: Zusätzlicher Punkt an die Highway + antsprechend Tagging.

Dass niemand im vollen Umfang die Verkehrszeichen verwendet, liegt ja eben an fehlender Kodifizierung nach der Du fragst.

Wenn Du eine Wiki Seite dafür anlegen könntest, würde ich mich gern an dieser Arbeit beteiligen. Eigentlich habe ich das für das "Navigationsmeeting" in Garching vorgesehen 😉

marek kleciak wrote:

...Zusätzlicher Punkt an die Highway + antsprechend Tagging...

Ich dachte hierfür gibt es am way oneway=yes - also wozu einen eigenen Punkt 8ist glaub ich ein schlecht gewähltes Beispiel 😉 )? Und dass es kein oneyway ohne entsprechendem Schild gibt ist - denke ich - klar; anders sieht es bei "Stop" oder "Vorrang geben" aus...

Hi Tunnelbauer,
vielleicht habe ich´s unklar formuliert: Wo oneway=yes steht, haben wir eine Einbahnstraße, dadurch ist ja klar, worum es bei dem Verkehrsschild geht. Man braucht jedoch Richtungsangaben falls ein Verkehrsschild nur eine Fahrtrichtung betrifft und die andere nicht UND die Straße die zwei Richtungen hat mit EINEM Vektor gezeichnet ist.

Wahrscheinlich muß man es mit einer Relation versehen, die die Richtung anzeigt.

marek kleciak wrote:

Hi Tunnelbauer,
vielleicht habe ich´s unklar formuliert: Wo oneway=yes steht, haben wir eine Einbahnstraße, dadurch ist ja klar, worum es bei dem Verkehrsschild geht. Man braucht jedoch Richtungsangaben falls ein Verkehrsschild nur eine Fahrtrichtung betrifft und die andere nicht UND die Straße die zwei Richtungen hat mit EINEM Vektor gezeichnet ist.

Wahrscheinlich muß man es mit einer Relation versehen, die die Richtung anzeigt.

dafür gibt es lange etablierte Verfahren: oneway=yes oder oneway=1 für Einbahnstrassen in der "Erfassungs-Richtung" und in der anderen Erfassungs-Richtung oneway=-1
andere tags erfolgen mit xxx:forward und xxx:backward.
Alles Werte RELATIV zur OSM-Richtung. Werden sogar von Josm angepasst, wenn jemand die Straße "dreht".

Gruss
walter

würde gerne mal wissen, wie ein maxspeed=* als Node bei einer Kreuzung "richtig" erfasst werden soll. Ohne Relationen geht es wohl nicht. Dann lass ich es lieber gleich.

wambacher wrote:

dafür gibt es lange etablierte Verfahren: oneway=yes oder oneway=1 für Einbahnstrassen in der "Erfassungs-Richtung" und in der anderen Erfassungs-Richtung oneway=-1
andere tags erfolgen mit xxx:forward und xxx:backward.
Alles Werte RELATIV zur OSM-Richtung. Werden sogar von Josm angepasst, wenn jemand die Straße "dreht".

Dann müßte man diese Informationen an einer Stelle in Wiki zusammenfassen.

wambacher wrote:

würde gerne mal wissen, wie ein maxspeed=* als Node bei einer Kreuzung "richtig" erfasst werden soll

Das geht nicht. Maxspeed ist ein Attributt der Strecke, also brauchen wir keine Schilder taggen dafür. Man attributtiert den Straßenabschnitt wie gewohnt. Der Schild kann in einem System wenn gewünscht dort generiert werden, wo sich Maxspeed ändert.

Oneway ist ja erfasst.

Aber wie gesagt: Ich denke "Routing"relevante Schilder sind eher "Stop" und "Vorrang geben" - und ich habe auch schon Stop-Schilder - wie Jan schreibt - als Punkt neben der Straße getagged, da es so im Wiki steht - nur was macht der Router daraus oder was kann er daraus machen, wenn da so ein Schild ohne jeglichen Bezug steht?

Der Router kann damit nichts anfangen 🙁
Er müßte eine sehr teure Suche nach den Punkten in der Nachbarschaft der berechneten Route starten. Das würde unnötig Ressourcen fressen, daher macht es auch niemand auf diese Art.
"Billige" Lösung malt alles was sie sieht, dann ist aber die Generierung einer akustischen bzw. optischer Warnung nicht möglich.

tunnelbauer wrote:

Oneway ist ja erfasst.

Aber wie gesagt: Ich denke "Routing"relevante Schilder sind eher "Stop" und "Vorrang geben" - und ich habe auch schon Stop-Schilder - wie Jan schreibt - als Punkt neben der Straße getagged, da es so im Wiki steht - nur was macht der Router daraus oder was kann er daraus machen, wenn da so ein Schild ohne jeglichen Bezug steht?

Wo soll das denn im Wiki stehen? Stoppschilder gehören natürlich auf die Straße.
Der Router erkennt die Zugehörigkeit dann durch die kürzeste Entfernung zur nächsten Kreuzung.
Neben der Straße kann der Router allerhöchstens über Relationen etwas damit anfangen.

Dazu möchte ich folgendes bemerken:

Für meine in Entwicklung befindliche Motorrad-Tourenkarte wäre es nicht dumm, wenn man Verkehrszeichen für kurvige Strecken auswerten könnte, sprich so wie z.b. motorroad=yes, oneway=yes usw. gäbe es noch ein curvy=yes.
Mittels so eines Kennzeichens könnten für den Motorradfahrer kurvigen Strecken Vorrang bei der Routenwahl gegeben werden.
Ob es sich um einen kurzen oder langen Abschnitt, eine mehr oder weniger kurvige Straße oder eine gefährliche Kurve handelt, sollte hier keine Rolle spielen. Einzig und allein die Tatsache, das vom Straßenverkehrsamt dort ein Schild vor Kurven warnt, ist für einen Motorradfahrer gleichzeitig Indikator für Kurvenspaß.

Beachtet dazu auch meine Frage hier im Forum bei Garmin.

Hallo Scotti,
selbstverständlich ja! Genauso wie maxspeed=<value> als eigenschaft einer Strecke dazu verwendet wird um für eine damit getaggte Strecke die Anzeige in der Ecke einer Navigation einschaltet die zeigt, wie schnell man fahren darf, sollte man auch Tagging für:
- gefährliche Kurven
- andere gefähliche Abschnitte der Strecke haben

Also ich möchte nochmal anregen, dass man eine solche Wiki Siete baut in der man alle diese Informationen an einer Stelle zusammenträgt.
Scotti, könntest Du damit anfangen? Einfach eine Tabelle bauen ähnlich der http://wiki.openstreetmap.org/wiki/Map_Features und diese als Platzhalter mit allen Verkehrsschilder füllen.

Um genauer zu sein, die Seite:http://wiki.openstreetmap.org/wiki/DE:Proposed_features/Traffic_sign schreibt:
" Anwendbar auf Knotenpunkte, Wege oder Flächen ".
Ich denke man sollte es genauer beschreiben: Es gibt Punktwarnungen und Eigenschaften der Strecken ( wie z.B. "kurvig"..)

@MotorKUH
Für kurvenreiche Strecken gibt es hazard=curve (allerdings erst 12 mal).

Das Tag 'hazard' ist insgesamt leider nicht weit verbreitet.
http://wiki.openstreetmap.org/wiki/Prop … res/hazard

Hallo,

MotorKUH wrote:

Einzig und allein die Tatsache, das vom Straßenverkehrsamt dort ein Schild vor Kurven warnt, ist für einen Motorradfahrer gleichzeitig Indikator für Kurvenspaß.

Ich kann mir vorstellen, daß es kurvige Strecken gibt, die nicht mit dem entsprechenden Verkehrszeichen versehen sind. Wenn es um Kurvenspaß geht, hätte das Tag für die Straße eine ähnliche Bedeutung wie die Angabe eines landschaftlich schönen Straßenabschnittes. Das wäre meiner Ansicht nach unabhängig bzw. ergänzend zum entspechenden Verkehrszeichen und stellt eine Eigenschaft der Straße dar.

Sven

Hallo Sven, ebenfalls richtig! Falls niemand Was dagegen hat, werde ich mit dem tabelarischen Untarabschnitt auf der Wikiseite http://wiki.openstreetmap.org/wiki/DE:P … affic_sign anfangen.

Wow, diese Herangehensweise eröffnet ein breites Feld für Taggingideen.

Wie tagge ich einen Streckenabschnitt für den gilt:
0. eine Doppelkurve
1. Steigung
2. Gefälle
3. Unebene Fahrbahn
4. Schnee und Eisglätte
5. Steinschlag
6. Spliit Schotter
7. Seitenwindgefahr
8. Staugefahr

Nur um den Anfangf zu machen...

Für 1 und 2:

http://wiki.openstreetmap.org/wiki/DE:Key:incline

marek kleciak wrote:

Hallo Scotti,
selbstverständlich ja! Genauso wie maxspeed=<value> als eigenschaft einer Strecke dazu verwendet wird um für eine damit getaggte Strecke die Anzeige in der Ecke einer Navigation einschaltet die zeigt, wie schnell man fahren darf, sollte man auch Tagging für:
- gefährliche Kurven
- andere gefähliche Abschnitte der Strecke haben

Also ich möchte nochmal anregen, dass man eine solche Wiki Siete baut in der man alle diese Informationen an einer Stelle zusammenträgt.
Scotti, könntest Du damit anfangen? Einfach eine Tabelle bauen ähnlich der http://wiki.openstreetmap.org/wiki/Map_Features und diese als Platzhalter mit allen Verkehrsschilder füllen.

Da traust Du mir aber was zu!

Eine Übersicht der Verkehrszeichen gibt es hier:
http://de.wikipedia.org/wiki/Bildtafel_ … eutschland
http://de.wikipedia.org/wiki/Bildtafel_ … Frankreich
http://de.wikipedia.org/wiki/Bildtafel_ … er_Schweiz
http://de.wikipedia.org/wiki/Bildtafel_ … 6sterreich
http://de.wikipedia.org/wiki/Bildtafel_ … ederlanden

Einen Vergleich gibt es hier:
http://de.wikipedia.org/wiki/Vergleich_ … hrszeichen

chris66 wrote:

@MotorKUH
Für kurvenreiche Strecken gibt es hazard=curve (allerdings erst 12 mal).

Das Tag 'hazard' ist insgesamt leider nicht weit verbreitet.
http://wiki.openstreetmap.org/wiki/Prop … res/hazard

Dann bringt es mir noch lange nichts. Da müssen erst die Tagger ran und erfassen, was nur geht.

Hi Scotti,
jeder Motorradfahrer hat mal mit einem kleinen BMW angefangen 😉
Du hast mit Deiner Frag eine relevante Baustelle inspiriert.

Die Seite http://de.wikipedia.org/wiki/Vergleich_ … hrszeichen ist schon putzig.
Kannst Du vielleicht eine Liste als Text zusammenstellen, welche Verkehrszeichen die Eigenschaften einer Strecke beschreiben?
Wenn wir eine solche Liste haben, können wir über Tagging debattieren. Ich bin mir sicher, das eine oder Andere gibt es irgendwo bereits...

Für die punktuelle Beschreibung haben wir schon einen Vorschlag in der Wiki.

Maxspeed=* ist mesitens (mir fallen gerade keine Ausnahmen ein...) ein durch ein Vekehrzeichen verursachtes Attribut der Strecke. Also ist das eher eine Relation mit den Rollen "from", "to" und "sign" auf dem Vekehrsweg. Dabei ist "sign" nicht nur rund und mit rotem Rand, sondern es sind z.B. auch Orts- und Autobahnschilder.

Echte Eigenschaften des Weges sind z.B. surface=* oder smoothness=*.

Eine Seite für das Tagging der Verkehrszeichen gibt es schon:
http://wiki.openstreetmap.org/wiki/DE:R … in_Germany

Gruß
Masi

marek kleciak wrote:

Wow, diese Herangehensweise eröffnet ein breites Feld für Taggingideen.

Wie tagge ich einen Streckenabschnitt für den gilt:
0. eine Doppelkurve
1. Steigung
2. Gefälle
3. Unebene Fahrbahn
4. Schnee und Eisglätte
5. Steinschlag
6. Spliit Schotter
7. Seitenwindgefahr
8. Staugefahr

Nur um den Anfangf zu machen...

den würd ich "Highway to Hell" nennen 😉

hi !

bevor das Thema abdriftet - auch wenn einige sich dahinter "verstecken" weil es so im Wiki steht. Das muss ja nicht richtig sein!!!

Ich bin dafür wenn schon ein Teil der Schilder erfaßt wird, dann auch in den Way integrieren.

Im Raum Saarbrücken hatte ich selber schon Situationen bei denen ein Warnhinweis mehr als angebracht wäre.

Also wer ist so "muttig" und schreibt ins Wiki - Schilder gehören in den Way!

Gruß Jan :-)

Wambacher wrote:

den würd ich "Highway to Hell" nennen

Mein Lieber, Du hast meinen trockenen polnischen Humor richtig interprätiert.
Ich wollte dich auch dazu bringen, dass Du dafür einzeln Voschläge machst.

Highway=Highway to Hell kann in der Tat als Kombination gennanter Eigenschaften gelten, nur, wie tagge ich´s einzeln?

And Lübeck: Schilder gehören in den Way wenn sie DEn Weg beschreiben.

Lübeck wrote:

Ich bin dafür wenn schon ein Teil der Schilder erfaßt wird, dann auch in den Way integrieren.

http://en.wikipedia.org/wiki/File:Verke … berg_1.JPG

Und jetzt alle: "Schilder gehören in den Way!" 😉

...Ok, zumindest nicht nach den momentan bei OSM üblichen Taggingregeln...

Ausgerechnet diese Informationsschilder braucht man bei einem solchen Konzept nicht. Sie Informieren einen Fahrer OHNE Navigationssystem, wie er seinen Ziel erreicht. Eine Navi berechnet selbst die Zielkoordinaten. Daher sind in einer Geodatenbank solche Informationen überflüssig.
Filtert man diese Informationen weg, sieht das Bild schon anders aus 😉

Man braucht auch die anderen nicht!
Eine Geschwindigkeitsbeschränkung z. B. ist durch das maxspeed-Tag an der jeweiligen Straße in der Datenbank. Das reicht fürs Navi.

Seh ich ähnlich. Eine kurvenreiche Strecke erkennt man auf eine Karte besser daran, dass im Verlauf derselben Kurven vorkommen, als dass man stellenweise den offiziellen Warnhinweis darin abdruckt.

Ich wär übrigens eher für:
highway=road
destination=hell

marek kleciak wrote:

Ausgerechnet diese Informationsschilder braucht man bei einem solchen Konzept nicht. Sie Informieren einen Fahrer OHNE Navigationssystem, wie er seinen Ziel erreicht. Eine Navi berechnet selbst die Zielkoordinaten. Daher sind in einer Geodatenbank solche Informationen überflüssig.
Filtert man diese Informationen weg, sieht das Bild schon anders aus 😉

Ich hatte nur noch in Erinnerung, das hier neulich Leute genau diese Vorwegweiser fürs Spurmapping erfassen wollten. Das wäre nur eine Möglichkeit, das zu bewerkstelligen, ohne das OpenStreetMap (noch weiter) zu OpenCarMap mutiert.

Wolfgang B wrote:

Eine Geschwindigkeitsbeschränkung z. B. ist durch das maxspeed-Tag an der jeweiligen Straße in der Datenbank. Das reicht fürs Navi.

Sag ich doch für die Geschwindigkeitsbegrenzungsschilder die ganze Zeit!

Mit den anderen sollten wir´s einzeln unter die Lupe nehmen. So z. B. kann man algorithmisch eine Strecke untersuchen und automatisiert auswerten. Haben wir auch gemacht. Das Problem ist jedoch, dass "nur" die Straßengeometrie des Öfteren nicht ausreicht. Schlechte Straßenoberfläche, nicht ausreichende Neigung des Straßenquerschnittes und schon hat man ein Problem wenn man der algorithmischer Auswertung glaubt. Hier wäre ich strikt für die manuelle Erfassung so, wie die Behörden die Strecke gekennzeichnet haben.

Das ist jedoch eine der wenigen Ausnahmen wo ich denke dass die Erfassung wichtig wäre. Was den Rest angeht, müssen wir uns gemeinsam Gedanken machen...

marek kleciak wrote:

Ausgerechnet diese Informationsschilder braucht man bei einem solchen Konzept nicht. Sie Informieren einen Fahrer OHNE Navigationssystem, wie er seinen Ziel erreicht. Eine Navi berechnet selbst die Zielkoordinaten. Daher sind in einer Geodatenbank solche Informationen überflüssig.

Na ja, sie sind genauso überflüssig - oder auch nicht - wie der Baum neben der Straße und die Form der Fenster im Haus daneben. Oder?

Fabi2 wrote:

Ich hatte nur noch in Erinnerung, das hier neulich Leute genau diese Vorwegweiser fürs Spurmapping erfassen wollten. Das wäre nur eine Möglichkeit, das zu bewerkstelligen, ohne das OpenStreetMap (noch weiter) zu OpenCarMap mutiert.

Da ging es iirc aber darum, die Aussage des Schildes zu mappen, nicht das Schild an sich. Also eher so etwas wie

destination:lanes = Brno;Poysdorf|Brno;Poysdorf|Graz;Wien

am Way. Der Unterschied ist dabei ähnlich wie der zwischen einem Node mit traffic_sign=DE:250 (Schild seblst) und dem Way-Tag vehicle=no (Aussage des Schildes).

Zum ursprünglichen Thema: Beim Verkehrszeichen-Mapping als Nodes im Way ist ein ungelöstes Problem, wie die Richtung anzugegeben ist. Das ist trivial bei Einbahnstraßen, lösbar bei Nodes innerhalb eines Ways, aber nicht ohne Weiteres möglich bei Nodes an der Nahtstelle zweier Ways mit unterschiedlicher Richtung.

Ich finde es auch keineswegs eindeutig, dass Schilder eindeutig in den Way gehören. Das wäre dann naheliegend, wenn man will, dass ein Router sie berücksichtigt. Aber ist das Taggingschema "Schilder an Nodes" überhaupt dazu gedacht? Eigentlich dienen dazu doch die Tags an Ways.

Tordanik wrote:

Fabi2 wrote:

Ich hatte nur noch in Erinnerung, das hier neulich Leute genau diese Vorwegweiser fürs Spurmapping erfassen wollten. Das wäre nur eine Möglichkeit, das zu bewerkstelligen, ohne das OpenStreetMap (noch weiter) zu OpenCarMap mutiert.

Da ging es iirc aber darum, die Aussage des Schildes zu mappen, nicht das Schild an sich. Also eher so etwas wie

destination:lanes = Brno;Poysdorf|Brno;Poysdorf|Graz;Wien

am Way. Der Unterschied ist dabei ähnlich wie der zwischen einem Node mit traffic_sign=DE:250 (Schild seblst) und dem Way-Tag vehicle=no (Aussage des Schildes).

Das beschränkt aber die realen Erfassungsmöglichkeiten und widerspricht dem Konzept, das die in OSM die Realität erfaßt werden sollte. Ohne Neuerfassung kann ich dann nicht mehr angeben, ob zw. z.B. der Wegweiser zusätzlich noch eine variable Anzeige hat und ob er z.B. beleuchtet ist. Das meinte ich mit OpenStreetMap ist nicht OpenCarMap, bei der das ganze Erfassungsmodell speziell auf den Nutzungsfall Autorouting zuschneiden kann!

Tordanik wrote:

Zum ursprünglichen Thema: Beim Verkehrszeichen-Mapping als Nodes im Way ist ein ungelöstes Problem, wie die Richtung anzugegeben ist. Das ist trivial bei Einbahnstraßen, lösbar bei Nodes innerhalb eines Ways, aber nicht ohne Weiteres möglich bei Nodes an der Nahtstelle zweier Ways mit unterschiedlicher Richtung.

Deshalb, ja auch als extra Node. Bei solchen Bügelkonstruktionen, kann man den Mast auch über die Straße mappen und die Position des Schildes als Node, welchen man dann mit einer Relation mit der betreffenden Spur/Straße verbinden kann. Dieses Mapping entspricht dann wenigstens der Realität und ist auch für die Autorouter und z.B. Ampeln und Mautbrücken zu gebrauchen. Außerdem ist man nicht eingeschränkt, wenn man z.B. den Wegweiser noch mit irgendwelchen Zusatzinfos ergänzen will.

Tordanik wrote:

Ich finde es auch keineswegs eindeutig, dass Schilder eindeutig in den Way gehören. Das wäre dann naheliegend, wenn man will, dass ein Router sie berücksichtigt. Aber ist das Taggingschema "Schilder an Nodes" überhaupt dazu gedacht? Eigentlich dienen dazu doch die Tags an Ways.

Dann darf man den Weg x-mal splitten, muß die Tags jeweils übertragen, so daß die Stücken immer kürzer werden, um dann Routen, maxspeed=*, surface=*, overtaking=*, access=*, jedes verscheidene traffic_sign, usw. am Weg unterzubringen. Nicht zu vergessen den Aufwand, wenn dann eins der Schilder abgebaut oder umgefahren wurde...

Moin!

Lübeck wrote:

Ich bin dafür wenn schon ein Teil der Schilder erfaßt wird, dann auch in den Way integrieren.

Also wer ist so "muttig" und schreibt ins Wiki - Schilder gehören in den Way!

Ich erfasse nur Ortsschilder mit "traffic_sign=city_limit" als node auf dem way, alle anderen anderen Verkehrszeichen nur als Eigenschaft des Weges.

Ich würde den Wikitext eher formulieren als:
Schilder als node auf dem way sind selten sinnvoll.
Schilder als node neben dem way sind nie sinnvoll.

Viele Grüße
Stephan

wambacher wrote:

den würd ich "Highway to Hell" nennen 😉

[Scherzmodus=an]Zur Info:
Hell = Mein Arbeitsplatz
"Highway to Hell" = Bundesstraße B9
"Road to Hell" (Chris Rea) = Weitere Straße bis zum Parkplatz
Dafür muss aber nicht extra ein Tag erfunden werden. Mich würde dann eher interessieren, wo ich den "Stairway to Heaven" finde.[Scherzmodus=aus]

Update:
Guten Morgen zusammen,

bin zu grün hier, um eine Entscheidung zu treffen, ob OpenStreetMap auch OpenCarMap oder für mich OpenMotorcycleMap sein darf. Ob und wie das technisch gelöst werden kann, das müssen andere tun.

Aber bald ist Weihnachten und man darf sich etwas wünschen. Und ich wünsche mir eine Möglichkeit, kurvige Strecken im Routing zu bevorzugen. Muss ja nicht über Verkehrszeichen als Node gehen. Aber anhand erfasster Verkehrszeichen hätte man schon mal eine gute Grundlage.

Schönen Tag.

Fabi2 wrote:

Dann darf man den Weg x-mal splitten, muß die Tags jeweils übertragen, so daß die Stücken immer kürzer werden, um dann Routen, maxspeed=*, surface=*, overtaking=*, access=*, jedes verscheidene traffic_sign, usw. am Weg unterzubringen. Nicht zu vergessen den Aufwand, wenn dann eins der Schilder abgebaut oder umgefahren wurde...

Genau das ist der Grund, warum ich hier auch Bauchschmerzen habe. Auf der anderen Seite ist das ein Grund, warum sich OSM z.B. von Google absetzen kann.
Nehmen wir an, wir lassen diese lästigen, wie Du schreibst "OpenCarMap" Attribute und die Weiterentwicklung in diese Richtung. Wir hätten dann weiterhin eine nette kartografische Karte mit der man sogar irgendwie navigieren kann.

Ich habe hier keine gute Antwort was gemacht werden soll außer - laß uns mal versuchen. Es ist ja nicht meine Meinung gegen Deine. Die Community wird hier entscheiden.
Wahrscheinlich kann man Vieles mit entsprechenden Tools vereinfachen.

Tordanik wrote:

Ich finde es auch keineswegs eindeutig, dass Schilder eindeutig in den Way gehören. Das wäre dann naheliegend, wenn man will, dass ein Router sie berücksichtigt. Aber ist das Taggingschema "Schilder an Nodes" überhaupt dazu gedacht? Eigentlich dienen dazu doch die Tags an Ways.

Klar es ist ein Thema für den Router und dazu sind die Tags an den Ways ausreichend. Deswegen sind einige Schilder überflüssig. Andere hingegen nicht. Das wollen wir erst Mal untersuchen.

Natürlich gibt es hier zwei verschiedene Ansätze die sich erst Mal im Wege stehen: 3D Abbildung der Realität - da sollten die Schilder dort stehen, wo sie sind, zum Zweiten der Routing mit seiner Abstraktion. Eigentlich sollten in einer universellen Karte BEIDE Ansätze möglich sein. Ein schwieriges Thema...

Fabi2 wrote:

Maxspeed=* ist mesitens (mir fallen gerade keine Ausnahmen ein...) ein durch ein Vekehrzeichen verursachtes Attribut der Strecke. Also ist das eher eine Relation mit den Rollen "from", "to" und "sign" auf dem Vekehrsweg. Dabei ist "sign" nicht nur rund und mit rotem Rand, sondern es sind z.B. auch Orts- und Autobahnschilder.

Irgendwie habe ich da kein Smiley gesehen. Mit solcher Art zu taggen vergraulen wir dann fast alle Neueinsteiger.

Christian

In 95% der Fälle gilt die Geschwindigkeitsbegrenzung für ein Abschnitt in beide Richtungen. Dort ist maxspeed=<value> ausreichend.

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_D … ce_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.

marek kleciak wrote:

Fabi2 wrote:

Dann darf man den Weg x-mal splitten, muß die Tags jeweils übertragen, so daß die Stücken immer kürzer werden, um dann Routen, maxspeed=*, surface=*, overtaking=*, access=*, jedes verscheidene traffic_sign, usw. am Weg unterzubringen. Nicht zu vergessen den Aufwand, wenn dann eins der Schilder abgebaut oder umgefahren wurde...

Genau das ist der Grund, warum ich hier auch Bauchschmerzen habe. Auf der anderen Seite ist das ein Grund, warum sich OSM z.B. von Google absetzen kann.
Nehmen wir an, wir lassen diese lästigen, wie Du schreibst "OpenCarMap" Attribute und die Weiterentwicklung in diese Richtung. Wir hätten dann weiterhin eine nette kartografische Karte mit der man sogar irgendwie navigieren kann.

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ß.

marek kleciak wrote:

Ich habe hier keine gute Antwort was gemacht werden soll außer - laß uns mal versuchen. Es ist ja nicht meine Meinung gegen Deine. Die Community wird hier entscheiden.
Wahrscheinlich kann man Vieles mit entsprechenden Tools vereinfachen.

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.

marek kleciak wrote:

Natürlich gibt es hier zwei verschiedene Ansätze die sich erst Mal im Wege stehen: 3D Abbildung der Realität - da sollten die Schilder dort stehen, wo sie sind, zum Zweiten der Routing mit seiner Abstraktion. Eigentlich sollten in einer universellen Karte BEIDE Ansätze möglich sein. Ein schwieriges Thema...

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.

Wolfgang B wrote:

Nochmals: Wegweiser zu mappen ist flüssiger als Wasser.

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?

Wolfgang B wrote:

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.

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.

Wolfgang B wrote:

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.

Da muß es dann endlich vernüftige Softwareunterstützung dafür geben.

tunnelbauer wrote:

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.

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.

tunnelbauer wrote:

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).

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?

tunnelbauer wrote:

Hier einen Konsens zu finden ist die Kunst.

Der Konsens muß zwischen Benutzerfreundlichkeit der Erafssung und dem Ende der Datenkakophonie, die bisher immerhin noch halbwegs funktioniert hat, gefunden werden.

Fabi2 wrote:

Smit ist Routing nur eine Nutzung der Daten und sollte grundsätzlich mit den Daten in der Datenbank nichts zu tun haben.

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:

-Anzahl der Spuren
-Maxspeed
-Abbiegevorschriften

marek kleciak wrote:

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:

-Anzahl der Spuren
-Maxspeed
-Abbiegevorschriften

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.

Fabi2 wrote:

Das momentane Erfassungsschema ist da zu beschränkt.

Absolut richtig. Kannst Du zu dem Treffen nach Garching kommen?

Grüße,
Marek