Verkehrszeichen als eigenständiger Node?

Lübeck · 2012-08-28 18:25:34

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

marek kleciak · 2012-08-28 20:04:01

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.

Fabi2 · 2012-08-28 20:26:57

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

Last edited by Fabi2 (2012-08-28 20:31:36)

marek kleciak · 2012-08-28 20:37:06

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

Wolfgang B · 2012-08-28 20:44:42

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.

RvdtG · 2012-08-28 20:56:32

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

Fabi2 · 2012-08-28 21:16:27

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.

marek kleciak · 2012-08-28 21:21:01

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

Tordanik · 2012-08-28 21:36:09

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.

Fabi2 · 2012-08-28 22:27:38

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

Last edited by Fabi2 (2012-08-28 22:30:01)

seawolff · 2012-08-28 23:05:45

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

MotorKUH · 2012-08-29 07:16:43

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.

Last edited by MotorKUH (2012-08-29 07:24:05)

marek kleciak · 2012-08-29 07:30:28

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

brogo · 2012-08-29 07:45:51

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

marek kleciak · 2012-08-29 08:18:10

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

Jimmy_K · 2012-08-29 09:03:26

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.

marek kleciak · 2012-08-29 11:58:27

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.

Wolfgang B · 2012-08-29 12:15:34

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.

marek kleciak · 2012-08-29 12:28:50

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.

tunnelbauer · 2012-08-29 12:40:29

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.

marek kleciak · 2012-08-29 12:48:09

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.

Fabi2 · 2012-08-29 13:50:52

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.

Fabi2 · 2012-08-29 14:02:38

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.

Fabi2 · 2012-08-29 15:04:49

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.

Last edited by Fabi2 (2012-08-29 15:16:30)

marek kleciak · 2012-08-29 15:13:35

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

Announcement

#26 2012-08-28 18:25:34

Re: Verkehrszeichen als eigenständiger Node?

#27 2012-08-28 20:04:01

Re: Verkehrszeichen als eigenständiger Node?

#28 2012-08-28 20:26:57

Re: Verkehrszeichen als eigenständiger Node?

#29 2012-08-28 20:37:06

Re: Verkehrszeichen als eigenständiger Node?

#30 2012-08-28 20:44:42

Re: Verkehrszeichen als eigenständiger Node?

#31 2012-08-28 20:56:32

Re: Verkehrszeichen als eigenständiger Node?

#32 2012-08-28 21:16:27

Re: Verkehrszeichen als eigenständiger Node?

#33 2012-08-28 21:21:01

Re: Verkehrszeichen als eigenständiger Node?

#34 2012-08-28 21:36:09

Re: Verkehrszeichen als eigenständiger Node?

#35 2012-08-28 22:27:38

Re: Verkehrszeichen als eigenständiger Node?

#36 2012-08-28 23:05:45

Re: Verkehrszeichen als eigenständiger Node?

#37 2012-08-29 07:16:43

Re: Verkehrszeichen als eigenständiger Node?

#38 2012-08-29 07:30:28

Re: Verkehrszeichen als eigenständiger Node?

#39 2012-08-29 07:45:51

Re: Verkehrszeichen als eigenständiger Node?

#40 2012-08-29 08:18:10

Re: Verkehrszeichen als eigenständiger Node?

#41 2012-08-29 09:03:26

Re: Verkehrszeichen als eigenständiger Node?

#42 2012-08-29 11:58:27

Re: Verkehrszeichen als eigenständiger Node?

#43 2012-08-29 12:15:34

Re: Verkehrszeichen als eigenständiger Node?

#44 2012-08-29 12:28:50

Re: Verkehrszeichen als eigenständiger Node?

#45 2012-08-29 12:40:29

Re: Verkehrszeichen als eigenständiger Node?

#46 2012-08-29 12:48:09

Re: Verkehrszeichen als eigenständiger Node?

#47 2012-08-29 13:50:52

Re: Verkehrszeichen als eigenständiger Node?

#48 2012-08-29 14:02:38

Re: Verkehrszeichen als eigenständiger Node?

#49 2012-08-29 15:04:49

Re: Verkehrszeichen als eigenständiger Node?

#50 2012-08-29 15:13:35

Re: Verkehrszeichen als eigenständiger Node?

Board footer