Hallo, gibt es eine offiziele Möglichkeit Sackgassen zu mappen? Ich bin viel im Wald im unterwegs und logge da. Oft stößt man dann auf Waldschneisen die ein Ende haben. Damit andere User nicht auf die Idee kommen und denken “ah, es könnte weiter gehen, es ist nur noch nicht erfasst” suche ich eine Möglichkeit zu verdeutlichen das Wege Sackgassen sind. danke mfg barelli
Sackgassen kann man mit dem Tag noexit=yes kennzeichnen. in wie weit man das auch auf Waldschneisen übertragen kann, weiß ich allerdings nicht. Tipp: http://wiki.openstreetmap.org/index.php/DE:Map_Features Gruß Henrik
hi, schonmal danke für die antwort. weißt du denn ob sowas auch grafisch dargestellt wird? mfg barelli
Hallo barelli, schau dir die Features-Seite mal an. Die Symbole / Zeichen ganz rechts werden nach dem rendern in der Karte dargestellt. Georg
Die Frage kann man sicherlich nicht pauschal beantworten, denn ist gibt ja verschiedene grafische Anzeigemoeglichkeiten. Auf den Garminkarten von Computerteddy wird das Sackgassensymbol nicht angezeigt. Dein Problem kenne ich aus eigener Erfahrung, weiss aber nicht, ob es eine 100%-ige Loesung dafuer gibt. In “meinem” Wald ist es meist so, dass die Schneisen nicht ploetzlich aufhoeren, sondern der Wegzustand immer mehr nachlaesst, je weiter man sich vom Hauptweg entfernt. Wenn man das entsprechend einzeichnet, dann sehen anderen den Pfad halt eben auch langsam auslaufend, und ich hoffe, sie ziehen daraus die richtigen Schluesse. Umgekehrt, wenn ich nur eine Wegeinfahrt markiere, wo es eigentlich noch weiter gehen wuerde, dann spendiere ich da immer eine Note, dass der Weg noch weiter geht. Leider werden die Notes aber auch nirgendwo angezeigt, so dass das auch nicht unbedingt die goldene Loesung ist. Gruss Torsten
Ich setze dort, wo es noch weitergeht, einen eigenständigen Weg mit “highway=road” und “note=FIXME”. Beides wird in JOSM vom Validator angezeigt und außerdem ist das ganze noch in Mapnik und Osmarender gut sichtbar (auf den Garminmaps glaube ich leider nicht). Sowas produziere ich in meiner Gegend recht häufig, siehe hier: http://www.openstreetmap.org/?lat=48.5235&lon=8.93908&zoom=15&layers=B000FTF Das sieht zwar nicht doll aus, aber der Sinn ist ja, dass es korrigiert werden soll. Und so sieht man ganz schnell, dass es da noch was zu tun gibt und wo. Andersrum kann man sagen: Dort wo kein solcher Weg ist, ist auch keiner in Wirklichkeit. Das geht natürlich nur begrenzt, denn dafür muss ja alles auch so “markiert” sein.
Wenn ich mir jetzt vorstelle, dass alle irgendwo etwas eintragen, wo etwas fehlt oder ein Fehler bekannt ist, hätten wir in der Karte ein riesen großes Durcheinander. Es gilt generell, dass man nicht für den Renderer Daten erfasst oder anpasst. Bestimmt werden über kurz oder lang von den Renderer die Sackgassen mit einem entsprechenden Zeichen gekennzeichnet. Gruß Michael
Ich markiere alle nicht vollständigen Wege wie hier http://openstreetbugs.appspot.com/?lon=8.73619587689919&lat=48.85634888208328&zoom=16 in openstreetbus. Da man - O.K. ich spreche für mich also da ich - eher überschaubare Bereiche auf ein Mal bearbeite, mache ich mir von den betreffenden Bereichen (zumindest wenn sie größer sind) in altmodischer Weise einfach einen Ausdruck. Das funktioniert einwandfrei und “versaut” die Hauptkarte nicht. Grüßle, detlef
Naja, wir haben bei OSM letztendlich ein ziemliches Durcheinander, was ja aber durch die vielen Freiheitsgrade durchaus erwuenscht ist. Und das Tag highway=road ist immerhin ein “offizielles” Tag aus der Mapfeatures-Liste, dass extra dafuer vorgesehen ist, um temporaer unvollstaendige Daten zu kennzeichnen. Allerdings ist es eigentlich eher dafuer gedacht, wenn man die Klassifizierung einer Strasse nicht angeben kann. Deshalb habe ich es auch noch nicht fuer unvollstaendig erfasste Wege benutzt, ganz doof finde ich die Idee trotzdem nicht. Ich habe nur haeufiger den Fall, dass bis zum Ortsende eine residential Strasse geht, die danach als Feldweg weiter fuehrt. Wenn mein Ziel des Tages ist, den Ortsteil komplett abzufahren, dann ist die letzte Information, dass dort noch ein feldweg weitergeht. Wenn ich den nun als road eintragen wuerde, dann wuerde ein Teil der Informatiopn (Feldweg) verloren gehen.
Ich hoffe nicht. Es gibt bei OSM sinnvollere und wneiger sinnvolle Tags. Noexit zaehle ich eindeutig zu den letzteren: - Auf keiner Karte, keinem Stadtplan sind Sackgassen extra gekennzeichnet. Das sieht man naemlich eigentlich auch so. - Mit noexit wird ein kompletter Strassenabschnitt markiert. Wie wollte man das auf einer Karte darstellen? Die Strasse durch X-en aehnlich wie bei access=no? Die Position des Sackgassenschildes fuer ein Symbol nutzen geht nicht, weil der Renderer ja gar nicht wissen kann, wo er es hin malen sollte. Da muessten wir dann das Schild als node eintragen und nicht die Strasse als Sackgasse markieren. - Wie bei mehreren anderen tags gibt es bei noexit noch das Problem, dass dort nicht sauber fuer verschiedene Fahrzeuge aufgeschluesselt wird. Ist die Strasse fuer alle eine Sackgasse? Fuer KFZ? Fuer Fussgaenger? Vielleicht ist der Weg ueber OpenStreetBugs nicht falsch, wenn die Informationen staerker in die OSM Anzeigen eingebunden werden. Auf der anderen Seite kann man natuerlich auch fragen, warum man die Bug-Informationen nicht gleich in der OSM-Datenbank speichert. Z.B. ein tag “bug=hier stimmt was nicht”. Gruss Torsten
Das verstehe ich nicht. Wenn ich überall etwas eintrage, wo etwas fehlt, ist das doch eine ziemlich wertvolle Information. Ob es nun ein openstreetbug ist oder ein kurzes highway=road ist egal, auf jeden Fall sind auf den ersten Blick zwei Dinge klar: 1. hier ist noch was zu tun; 2. die karte ist hier nicht zuverlässig zu gebrauchen.
Deine Variante ist natürlich auch gut. Was mich persönlich aber stören würde, ist, dass ich jedes Mal den openstreetbug erst anschauen muss, bevor ich weiß, ob da noch ein Weg fehlt, oder etwas anderes falsch ist. So gesehen ist meine Variante (die ich so ähnlich glaube ich irgendwo in der Wiki aufgeschnappt habe) etwas einfacher zu handhaben. Ich muss dir Recht geben, dass das nicht unbedingt schön aussieht, was ich mache, aber wie heißt es doch so schön: “Wir mappen nicht für …” 
Außerdem ist OSM als Karte zum jetzigen Zeitpunkt, abgesehen von winzigen Gebieten, meiner Meinung nach völlig unbrauchbar (bei dieser Meinung lasse ich mich gern eines besseren belehren, aber wenn ich mir meine Gegend anschaue, komme ich zu diesem Schluss). Und da machen die paar “hässlichen” Wegstücke auch nichts mehr aus. Und wen diese “hässlichen” Wegstücke stören, der sei so frei und gehe in den Wald, oder wo auch immer der fehlende Weg ist, und ergänze OSM Meistens habe ich aber so ein Stück innerhalb eines Monats selber korrigiert, weil es in meiner Gegend praktisch keine Outdoor-Mapper gibt.
Diese Information fülle ich dann auf, wenn ich wieder in der Gegend bin und es mein Ziel ist die Feldwege zu mappen. So, ich hab meine Argumente dazu mal ausführlich dargestellt, weil es den meisten wohl nicht gefällt, wie ich das mache. Nun zu dem anderen Thema hier:
Deine Argumente leuchten ein, besonders das letzte lässt den Wert des noexit-Tags sinken. Wenn alles korrekt gemappt ist, also für alle Wege auch die dazugehörigen Berechtigungen für Fußgänger, Moped, PKW, LKW usw., dann sollte es doch ein Programm schaffen, selber herauszufinden, wo eine Sackgasse (für ein gegebenes Verkehrsmittel) ist oder nicht. Grüße Stammfunktion
Zum Thema Sackgasse meine ich das wir diese sehr wohl aufnehmen sollten. Denkt doch einmal an die Zukunft. Irgendwann wird die OSM-Karte (bzw. Datenbank) den Stand erreicht haben auch wirklich für die Navigation zu taugen und dann sind Informationen wie eine Sackgasse durchaus wichtig. Ich stelle mir gerade den Fahrer eines 20m Sattelzuges, schlimmer noch eines Gliederzug vor, der in dem Glauben eine durchgängig befahrbare Straße gewählt zu haben, plötzlich und unvermittelt vor einem 10m-PKW Wendehammer steht. Gerade in diesem Bereich besteht ein Riesendefizit bei den vorhandenen Navi-Karten und in den entsprechenden Foren treten viele seit langer Zeit dafür ein das endlich entsprechende Hinweise in die Systeme einfließen.
Da hast du sicher Recht aber das bedeutet ja nicht das OSM hier nicht besser als alle anderen ist (sein wird). Hier in der Umgebung sehe ich immer öfter unter dem Sackgassenschild den Zusatz -keine Wendemöglichkeit-. Ich denke das ist wichtig eben dafür das der o.g. trucker gar nicht erst da rein fährt.
Eventuell sollte man die Macher der Renderer bitten noexit auch als Node zuzulassen, damit wäre das Problem des Schildes und dessen Anzeige erledigt. Die Straße sollten wir IMHO trotzdem als noexit kennzeichnen, und eben die von Stammfunktion genannten Beschränkungen gerade hier strikt anwenden. Die Routingroutinen werden bestimmt nicht nach Schildern bzw. deren Nodes suchen. In der Kartenansicht jedoch ist dann wieder das Schild wichtiger. Gruß Georg
Das wird der Renderer Algorithmus aber auch alleine anhand der Daten erkennen, das muss man ihm dann nicht per extra Tag signalisieren, das macht die Sache nur noch schwieriger: - Er kann sich nicht darauf verlassen, dass das Tag immer gesetzt ist. Er muss bei jeder Strasse davon ausgehen, dass sie nicht zu seiner Loesung gehoert. - Sein Ziel kann genau im Bereich dieser Sackgasse liegen (z.B. in einer kleinen Stichstrasse, die von der bereist als Sackgasse markierten gesamten Strasse abgeht). - Das Tag kann irrtuemlich gesetzt den Routingalgorithmus ganz schoen verwirren. Viel Spass bei der Fehlersuche, wenn jemand ein Stueckchen Autobahn irrtuemlich als noexit markiert.
Bei dem Tag turning_circle=yes ist mir auch schon aufgefallen, dass das noch nicht so optimal ist. Heisst das nun, dass da ein PKW wenden kann? Oder ein LKW? Das muesste man wahrscheinlich auch mal in turning_circle=hgv oder so aufbohren.
Dir geht es hier anscheinend nicht um das Sackgassenschild, sondern um das Zusatzschild. Und genau das erfasst du ja mit dem noexit nicht. Damit sind wir wieder zurueck beim turning_circle.
Von mir aus spricht nichts gegen ein Proposal fuer ein Sackgassenschild. Denn im Gegensatz zur jetzigen Variante kann man das immerhin fuer die Kartenansicht nutzen. Wirklich brauchen tut man das aber nicht, denn wenn ich eine Strasse auf der Karte sehe, dann sehe ich auch, ob die auf der anderen Seite weiter geht oder nicht. Und, wie oben bereits geschrieben, fuer einen Routing-Algorithmus ist das egal, denn auch der merkt selber, ob er bei einer Strasse weiter kommt oder nicht. Gruss Torsten
Hallo Torsten, turning_circle ist denke ich nur für die kleinen Wendeplätze gedacht, die für PKW geeignet sind. Schließlich werden hiermit laut Doku auch schon “Verdickungen” in einem Straßenabschnitt gekennzeichnet. Die LKW-Wendekreise die ich bislang (bewußt) gesehen habe, hatten allesamt eine Insel in der Mitte, was sich durch eine einfache Straße ja wunderbar darstellen läßt. Außerdem ist hier auch für einen LKW-Fahrer abschätzbar, ob er da mit seinen Sattelzug rum kommt. Für den Fall das keine Insel in der Mitte vorhanden ist würde ich beim Wendekreis für die Straße area=yes setzen. Grüßle, detlef
Ich muss gestehen, dass ich nicht wirklich weiss, ab welcher Groesse ein LKW wieviel Platz zum Wenden braucht. Wenn der Wendekreis in der Mitte eine Insel hat, dann zeichne ich auch immer eine Strassen-Schlaufe. Ob man daraus aber viel ueber die Platzverhaeltnisse ablesen kann, wage ich aber mal zu bezweifeln. Denn bei solchen Kehren ist man ja im Bereich der GPS-Genauigkeit, so dass die letztendlich eigentlich nur symbolisch eingetragen sind.
Da hast du das naechste Tag getroffen, dass bei mir auf der schwarzen Liste steht. Ein OSM-Element wird normalerweise durch ein Haupt-Tag (z.B. highway=track) beschrieben. Dazu gibt es dann weitere Tags, die die Hauptinformation noch ergaenzen aber im Prinzip nicht aendern (z.B. tracktype=grade1, name=beispielweg). Das Einhalten dieses Schemas gerantiert, dass Auswerteprogramme (z.B. Renderer oder Routingprogramme) auch funktionieren, wenn sie einen Teil der Keys nicht kennen. Ihnen geht ein Teil der Information dann zwar halt verloren, aber die Teilmenge, die sie erkennen, ist immer noch richtig. Und nun kommt das Tag are=yes. Wenn man bisher ein highway=unclassiefied ueber die Punkte A, B, C, D hatte, dann bedeutete das, dass eine Strasse vom Punkt A nach B, vom Punkt B nach C und vom Punkt C nach D lief, wobei die Strassenmitte in etwa auf diesen Verbindunglinien liegt. Kommt jetzt aber das area=yes dazu, dann kann man die bisherige Annahme komplett vergessen, denn nun heisst das ploetzlich, dass zwischen den Punkten A, B, C und D eine Verkehrsflaeche liegt, die alle Punkte beliebig miteinander verbindet und bei der die angegebenen Punkte den Rand der Flaeche markieren. D.h. also, dass alles, was das area=yes Tag nicht erkennt, nicht nur ungenauere Ergebnisse liefert, sondern kompletten Muell. Fuer meinen Geschmack ist das ein Musterbeispiel, wie man eine Datenstruktur nich aufbauen sollte. Und um solchen Murks komplett zu machen, kann man bei Sackgassen noch die naechste allgemein akzeptierte Datenpanne mit einbauen, die genauso gegen dieses Erweiterungsschema verstoesst: die Inner-Outer-Relation. Man nimmt einfach eine Wendekehre mit Verkehrsinsel. Die aeussere Kannte markiert man mit highway=unclassiefied und area=yes. Den Rand der Insel traegt man dann als leisure=park ein, und dazu spendiert man dann noch eine entsprechende Inner-Outer-Relation. Schon hat man die Gegend “korrekt” erfasst, die Daten sind aber trotzdem reiner Muell, mit dem niemand was anfangen kann. Gruss Torsten
Eigentlich ist doch das genaue Gegenteil der Fall. Nehmen wir als Beispiel einen Marktplatz als highway=pedestrian + area=yes. Hätten wir so was wie area=pedestrian, dann würde Software, die area nicht kennt, * überhaupt nichts anzeigen * kein Routing zwischen den unverbundenen einmündenden Straßen durchführen Mit area=yes wird * immerhin der Rand des Marktplatzes mit passender Beschriftung angezeigt * problemlos zwischen den Seitenstraßen geroutet (halt auf dem Rand entlang, aber echtes Platzrouting ist eh noch mal aufwändiger) Ich finde Fall 2 erheblich brauchbarer und auch näher an der Intention …