Re: [Talk-de] Einbahnstraße die von Fußgängern/Radfahrern/Motorradfahrern passierbar ist.
Hallo Manuel, das ganze sieht mit nach einem Fall von "tagging for the renderer/router" aus Am Mittwoch, 14. Oktober 2015 16:27 schrieb Manuel Reimer [mailto:manuel.s...@nurfuerspam.de]: >Hallo, > >über WhoDidIt bin ich auf einen Changeset in meiner Region aufmerksam geworden >bei dem auf diesen Weg einige Access-Tags hinzugefügt wurden: > >http://www.openstreetmap.org/way/38109871 > >Die vielen Access-Tags fand ich unschön und habe mir deshalb dort ein "fixme" >drangesetzt. >Gestern bin ich nun einmal an dieser Stelle vorbeigelaufen. Ich habe vor Ort >*keinerlei* Einschränkungen bezüglich der erlaubten Verkehrsmittel gefunden. Wenn da wirklich nichts ist, können die Beschränkungen, insbesondere das "access=no" eigentlich(*) weg, da im Moment fälschlicherweise z.B. Kutschen nicht erlaubt sind. >Das einzige, das da ist, ist ein "Sackgasse-Schild" rechts von diesem Punkt: > >http://www.openstreetmap.org/node/308773513 > >Komischerweise fehlt dort sogar ein Hinweis, dass Fußgänger und Radfahrer >passieren können (zumal der Kaibachweg in einem gemeinsamen Rad-/Fußweg endet). Da musst du mal bei deiner Stadt/ deinem Kreis vorsprechen und die darum bitten, dass Schild auszutauschen. >Das Sackgasse-Schild bezieht sich auf diesen Poller: > >http://www.openstreetmap.org/node/687493064 > >Autos kommen da nicht vorbei. Mit einem Motorrad müsste man gut vorbeikommen >und die Beschilderung würde das auch nicht verbieten. > >Den weiter südlich auf der anderen Seite liegenden Poller habe ich vor Ort >nicht gesehen. Ich laufe da demnächst aber nochmal vorbei bevor ich den >rauswerfe. Löblich. >Worum es mir eigentlich geht: Wie muss das Tagging aussehen? Wie verhindere >ich, dass ein Router über den Poller hinwegroutet? > >Die ganzen Access-Tags auf dem Weg würde ich auf jedem Fall rausnehmen wollen, >da es eben keinerlei Verbote gibt. Man darf mit jedem Fahrzeug bis zum Poller >vorfahren und bei Bedarf auch rechts in den Kaibachweg einbiegen (maximal bis >zum Fußweg). Sehe ich nach deiner Beschreibung genauso. Bitte beachte, dass (*) "*=yes" von manchen für "Geprüft" verwendetet wird. >Jemand hat bereits ein Access-Tag auf die Brücke gesetzt: >http://www.openstreetmap.org/way/76037293 >Aber auch das ist eigentlich falsch. "motor_vehicle" schließt Mopeds und >Motorräder ein. Mit denen müsste man den Poller aber locker passieren können >und die Beschilderung verbietet das auch nicht. Vermutlich ging es den >Verkehrsplanern bevorzugt um Autos. Im Prinzip verhindert der Poller aber das >Befahren mit jeglichem mehrspurigen Fahrzeug. Normalerweise sollte Router auf Wegen gesetzte "barrier=pollard" auch ohne Zusätzliche tags am way auswerten. Ein Motorradrouter kann sich dann eben entscheiden die Barriere zu ignorieren. Ich hoffe das Hilft ersteinmal. Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Radfahren zwar erlaubt aber nicht wirklich gut gesucht
Hallo Bernhard, konkret: mit keinem. Allerding gibt noch class:bicycle [1], dass wird aber glaube ich von keinem Router ausgewertet. Das größere Problem ist jedoch, dass es auch Radfahrer gibt, die auf (der Fahrbahn) einer Bundesstraße fahren, wenn es keinen Radweg gibt (da die dann meisten auch benutzungpflichtig sind) und keinen großen Umweg in anspruch nehmen wollen. Falls dir die Routinvorschläge nicht zusagen, bleibt dir noch die Option den Router nach eigenen Präferenzen selbst zu optimieren. Das geht z.b. mit Brouter oder auch mit OSMAND. Ich helfe auch gerne. Gruß Hubert [1]: http://wiki.openstreetmap.org/wiki/Class:bicycle -Original Message- From: Bernhard Kuisle [mailto:bernhard.kui...@web.de] Sent: Sonntag, 24. Mai 2015 18:44 To: talk-de@openstreetmap.org Subject: [Talk-de] Tag für Radfahren zwar erlaubt aber nicht wirklich gut gesucht Hallo, ich habe folgendes Problem: Bei uns in der Nähe befindet sich eine vielbefahrene Kreisstraße (gerader Verlauf, schnelle PKW und auch viele Laster) auf der natürlich Radfahren erlaubt ist, aber auf der kein Einheimischer (auch kein Rennradler) mit dem Fahrrad fährt, da auf beiden Seiten mehr oder weniger parallel kleine Straßen (auch asphatiert) verlaufen. Alle mir bekannten Fahrradrouter benutzen die Kreisstraße, da sie natürlich etwas kürzer ist. Mit welchen tags könnte ich die Router dazu bringen, eine der beiden Alternativen zu wählen? Gruß Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Radfahren zwar erlaubt aber nicht wirklich gut gesucht
Nochmal einen weiteren konfigurierbaren Router hinterher: https://routino.arch.tu-dresden.de/routino/router.html ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fußgänger-Diskriminierung?
Hallo, ich kürze den Text mal etwas und hoffe das man noch folgen kann. Am 23. April 2015 um 15:12 schrieb fly lowfligh...@googlemail.com Das war missverstandlich und bitte nicht als tagging-Vorschlag interpretieren. Meinte ich kenne keinen separat eingetragenen Fahrradweg entlang der Straße, der nicht auch gemischt oder separiert für Füßgänger*innen erlaubt ist. Zum Glück ist die Starßenverkehrsbehörde bei mir sehr kreativ. Daher kommen vermutlich auch all meine seltsamen Fragen und Vorstellungen. Bild 1 [1] zeigt einmal ein straßenbegleitender Radweg, welcher später durch einen Grünstreifen von der Fahrbahn getrennt wird. Auf Grund der Breite sollen dort keine Fußgänger laufen. Diese müssen den Geh und Radweg, (nur Gegenrichtung) auf der linke Straßenseite benutzen. Es gibt das Schild aber auch in freier Wildbahn, wie auf Bild 2 [2] zu sehen. Hier gehe ich aber davon aus, dass das so nicht beabsichtigt ist, jedoch steht auf der anderen Seite des Weges das gleiche Schild. Vielleicht auch highway=sideway. Dann werfe ich noch highway=sidetrack bzw. cycleway=sidetrack in den Ring. Verstehe nicht, warum wir zwischen nur Bordstein und zB nur Grünfläche unterscheiden müssen. Das kann doch alles separat eingetragen werden, aber wenn Du jetzt noch einen Zusatztag brauchst, dann erfinde doch etwas. Das hat zum einen mit einem Fußgänger Routing Project von Maxbe [3] zu tun, zum anderen mit der ungeklärten Frage, ob an nun Bordsteinwege als seperaten Weg einzeichen soll oder nur als tag an der Straße. Bei weiter abgesetzen Wege, wie z.B. bei Grünstreifen, usw., ist es ja weitestgehen akzeptiert, dass diese extra gemappt werden. Gruß Hubert [1] Bild 1 : https://www.mapillary.com/map/im/15YpUDzLrrj6Oha9nSRyuw [2] Bild 2 : http://imgur.com/QEvITqP [3] https://wiki.openstreetmap.org/wiki/User:Maxbe/B%C3%BCrgersteigrouting ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fußgänger-Diskriminierung?
Am 21. April 2015 um 15:19 schrieb fly lowfligh...@googlemail.com Am 21.04.2015 um 12:08 schrieb Martin Koppenhoefer: Am 21. April 2015 um 11:14 schrieb Roland Olbricht olbri...@mentzdv.de: Kurze Nachfrage. In wie fern hängen footway/path=sidewalk und sidewalk=detached zusammen, bzw unterschieden die sich? Weil die Frage auf kam: Ich verwende path=sidewalk, da ich mich an kein explizit gemappten highway=cycleway;cycleway=track errinnern kann. Aber was spricht gegen cycleway=sidewalk ? Irgentwo habe ich mal gelesen, dass highway=cycleway;cycleway=track sinnfrei wäre, da highway=cycleway sowieso cycleway=track impliziere. Außerdem wird cycleway=track schon an der Straße (highway=track) verwendet, und könnte daher zu Problemen mit Renderern führen, die man vermeiden kann. Gegen cycleway=sidewalk sprich meiner Meinung nach nicht viel, außer einem komischen Gefühl durch das walk im sidewalk. Danke für den Hinweis. Das ist (für Fußwege) ziemlich genau das, was ich gesucht habe und zu Jochens Vorschlag passt. Dass es zusätzlich sidwalk=detached gibt, liegt vermutlich daran, dass der russische Nutzer ebenfalls das Tag footway=sidewalk nicht gefunden hat. sidewalk=detached ist doch eher sowas wie footway=track, d.h. ein von der Straße unabhängiger bzw. baulich getrennter Fußweg in Nähe der Straße, im Gegensatz zu einem klar zur Straße gehörenden, nur durch einen Bordstein abgetrennten Gehweg. Ich hätte es jetzt an den Straße (highway=*) analog zu sidewalk=both/left/right/no verwendet. Aah. Das macht tatsächlich am meinsten Sinn. Danke. Es sollte mit in die Wiki-Dokumentation zu highway=footway aufgenommen werden: http://wiki.osm.org/wiki/DE:Tag:highway%3Dfootway In diesem Fall reicht es sogar, das nur in der deutschen Version nachzuziehen. m.E. wäre es von vornherein sinnvoll gewesen, Gehwege mit einem anderen tag als völlig unabhängige, eigenständige Fußwege zu taggen, und vielleicht ginge das auch jetzt noch einzuführen. +1 highway=sidepath oder sideway=footway/path/cycleway highway=sidepath finde ich recht nett. Da könnte man dann die gleichen tagging Regeln anwenden, wie bei highway=path. Außerdem verlinken dann sowohl cycleway/sidewalk=sidepath und bicycle/foot=use_sidepath auf eben diesen Weg. Allerdings müsste man auch hier irgentwie zwischen Wegen unterscheiden, welche nur durch einen Bordstein bzw. mittels Grünstreifen, Graben, Gitter, (Parkbuchten) von der Fahrbahn getrennt sind. Gruß Hubert. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fußgänger-Diskriminierung?
Kurze Nachfrage. In wie fern hängen footway/path=sidewalk und sidewalk=detached zusammen, bzw unterschieden die sich? Gruß Hubert Am 20. April 2015 16:59:32 MESZ, schrieb Roland Olbricht olbri...@mentzdv.de: Hallo zusammen, erst einmal danke für die umfangreiche Rückmeldung und auch einige weitere erhellende Beispiele. Ich würde gerne an Jochens Analyse und Vorschlag anknüpfen wollen. Aber wir haben halt nunmal sehr viel Renderer (bzw. Kartenstile), die damit nicht umgehen könnten. Und ich sehe auch nicht, wie man das mit vertretbarem Aufwand in die Software einbauen kann. Wir würden damit also bestehende Anwendungen vor ein Problem stellen. Diese Information ist ganz wichtig. Offenbar haben Renderer mehr Fallstricke als ich erwartet hätte. Ich nehme an, es geht nicht so sehr um die zusätzlichen Labels, wenn Platz ist: https://www.openstreetmap.org/#map=19/48.13872/11.61015 sondern um die in die Straße ragenden Labels, wenn eigentlich kein Platz ist https://www.openstreetmap.org/#map=17/48.13872/11.61015 Das scheint allgemein ein schwieriges Problem zu sein, weil ein paar Meter weiter https://www.openstreetmap.org/#map=17/48.13711/11.61489 es für die Secondary-Straße in Nord-Süd-Richtung so aussieht, als wenn sie Richard-Strauß-Tunnel heißen würde - sie heißt Leuchtenbergring, wie der Trunk, der südlich anschließt. Umgekehrt scheint es wohl keinen anderen Anwendungsfall außer Rendering zu geben, in denen die zusätzlichen Informationen ein Problem bedeuten würden. Dies ist ein Nebenweg der mehr oder weniger parallel zu einem Hauptweg lang geht. Dieses Tag könnte beim Rendering bzw. bei der Suche herangezogen werden, um den Straßennamen zu unterdrücken. Der Name kann dann auf die Nebenwege drauf, der Router kann ihn wie von Roland gewünscht nutzen. Danke für den Vorschlag. Von Marc Gemis kam der Hinweis, dass dafür sidewalk=detached in Gebrauch ist. Fürs Routing würde sich der Ansatz auf jeden Fall eignen. Ich nehme an, dass Renderer das Rendern des Namens unterdrücken können, wenn ein spezielles zusätzliches Tag auftritt? Alternativ könnte man natürlich auch einen neuen name-Tag einführen: Name des parallel führenden Hauptweges. Damit muss man beim Rendering nichts ändern. Mit diesem Ansatz könnte ich auch gut für den Router arbeiten. Einziger Nachteil wäre, dass andere Routing-Engines das nicht automatisch übernehmen, im Gegensatz zum name-Tag. Für die Renderer wäre das vermutlich die arbeitssparendere Lösung. Wenn sich kein großer Protest erhebt, würde ich also dann an osm-talk herantreten mit kurzer Zusammenfassung des Problems und der Einschätzung aus talk-de, dass a) name-Tag plus ein Zusatztag (z.B. sidewalk=detached oder parallel_to_road=yes, sollen die britischen Muttersprachler entscheiden) b) parallel_road:name = Name (oder andere Keys, nach Votum der Muttersprachler) pragmatische Lösungen wären und dem Ziel, das im Wiki als geeignete Vorgehensweise zu dokumentieren und für neue Edits zu verwenden. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fußgänger-Diskriminierung?
Hallo, bisher tagge ich den Namen einer Straße nicht auf den Gehweg/Radweg, wenn dieser straßenbegleitend ist. Allerdings kann ich mich der Argumentation von Roland nicht verwehren. Als Lösung könnte der tag footway=sidewalk o.ä. dienen. Ein Renderer könnte dann so programmiert werden, dass der name=*-tag halt nicht angezeigt wird. Eine Vererbung des Namens aus einer street-Relation ist natürlich auch denkbar, aber vermutlich schwerer umzusetzten, da mit mehr Aufwand verbunden. Sowohl beim Taggen als auch beim Auswerten. Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] F: Kreuzungsfreiheit bei trunk
Ist zwar nicht so mein Gebiet, aber als Kartenleser würde ich dort ein Trunk erwarten (Oldenburger Straße). Bei der Duckwitz Straße und Friesland Straße weiß ich das nicht so genau. Da würde ich es davon abhängigmachen, ob die als Auffahrt zum Trunk zählen, oder als eigene Straßen, welche nur kurz über eine gemeinsame Brücke gehen. Allerdings gefällt mir die die getrennt gemappten Spuren der nördlichen Brückeabschnittes nicht.Eine bauliche Trennung ist dort nach Sat Bild nämlich nicht zu erkennen. Gruß Hubert87 -Original Message- From: 715371 [mailto:osmu715...@gmx.de] Sent: Sonntag, 18. Januar 2015 18:05 To: Openstreetmap allgemeines in Deutsch Subject: Re: [Talk-de] F: Kreuzungsfreiheit bei trunk Hi, dieser trunk hat einen Bürgersteig und Radweg: https://www.openstreetmap.org/way/124713629 Wo würdet ihr die Grenze ziehen - würdet hier jemand das als highway=primary taggen? LG Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 23. Dezember 2014 02:24 schrieb 715371 osmu715...@gmx.de: Für einen Renderer kann es zu Beispiel auch interressant sein, wenn er denn benutzungspflichtige und nicht benutzungspflichtige Radwege unterscheiden möchte. Aber einen eigenen Tag dafür kenne ich auch nicht, nur die Versuche indierekt über bicycle=use_sidepath oder durch die Unterscheidung von bicycle=official/designated und bicycle=yes. Ein eigener Wert (z.B. bicycle=mandatory/obligatorry o.ä.) schein wohl überfällig, aber das ist ein anderes Thema. +1 Die Info ruft dann zwar nicht mehr Fehler hervor, wenn sie fehlt, aber ist natürlich immer noch interessant. bicycle=mandatory/obligatorry wäre in dem Kontext zumindest ein Tagging über das ich noch nicht nachgedacht habe. Problem ist vielleicht, dass es alleine am Radweg keine access- Bedeutung hat/haben könnte. Stimmt. Ich habe da die Vorstellung das mandatory (official) designated und yes implizieren würde Das hängt davon ab, was man als Problem identifiziert. Für mich ist es das beide Modelle (an die Straße taggen, eigener Weg) sinnvoll sind. Daher wird wohl schon deit 2011 () darüber gestritten ws denn nun besser ist. Ende offen wie man sieht. Und dazwischen sind auch alle Meinungen möglich. Wie so oft. *zwinker* Hast du die Hauptprobleme, die seitdem diskutiert wurden irgendwo dokumentiert? Oder weißt du, ob es so etwas gibt? Wenn sich diese Diskussion immer wieder wiederholt, ist das auch nicht sehr produktiv. Eure/Unsere Meinungen und Vorschläge würde ich sonst gerne einmal zusammenfassen. Ich hab noch eine Email mit zwei Links hinterhergeschickt, die ist wohl irgentwo falsch abgebogen. Eine direkte Zusammenfassung habe ich noch nicht, aber ersteinmal die beiden Links: wiki.osm.org/wiki/DE_talk:Bicycle/Radverkehrsanlagen_kartieren - Behauptungen, die diese Seite aufstellt -Punkt 4 http://wiki.openstreetmap.org/wiki/Talk:Sidewalks - Separated from the road by some form of barrier? Falls ich noch mehr finde lasse ich sie Dir zukommen. Hast du da mal ein Beispiel, wie das gehen soll, mit OsmAnd, Maperitive und Tilemill sehe ich da keine Chance das hinzubekommen. Und das Problem des separaten/doppelten mappens entsteht bei Radwegen ja maximl bei cycleway=track/opposite_track. =lane wird ja unbestritten (glaub ich) an die Straße gemappt. Ich musste jetzt auch lange nachdenken, was ich damit sagen wollte, entschuldige! Ich habe in diesem Zusammenhang beim Rendern irgendein weiteres Problem vermutet. Passiert mir auch oft, oder ich vertue mich mit den Absätzen und Frage und Antworte auf passen nicht mehr zusammen. Weil es dabei auch noch auf die Seite ankommen könnte, wäre vielleicht ein ganz anderer Tag als bisher vorgeschlagen besser. Z.B. separate_cycletrack=left/right/both und analog das für footway separate_sidewalk=left/right/both Das ist zwar auch möglich, allerdings sehe ich da das Problem, dass man sich wieder zwischen Straße und Gehweg entscheiden muss. Ich werde es aber trotzdem mal mit zu den Variationen aufnehmen. Stimmt. Wenn es zusammen an einem Weg erfasst ist, wären die Tags nicht mehr so schön. Man müsste dann beides taggen. Da findet sich hoffentlich ein vernünfiter Kompromiss. Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
des separaten/doppelten mappens entsteht bei Radwegen ja maximl bei cycleway=track/opposite_track. =lane wird ja unbestritten (glaub ich) an die Straße gemappt. Weil es dabei auch noch auf die Seite ankommen könnte, wäre vielleicht ein ganz anderer Tag als bisher vorgeschlagen besser. Z.B. separate_cycletrack=left/right/both und analog das für footway separate_sidewalk=left/right/both Das ist zwar auch möglich, allerdings sehe ich da das Problem, dass man sich wieder zwischen Straße und Gehweg entscheiden muss. Ich werde es aber trotzdem mal mit zu den Variationen aufnehmen. Beste Grüße Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hab doch glatt die Links vergessen, die ich noch einfügen wollte: Seit 2011: wiki.osm.org/wiki/DE_talk:Bicycle/Radverkehrsanlagen_kartieren - Behauptungen, die diese Seite aufstellt -Punkt 4 http://wiki.openstreetmap.org/wiki/Talk:Sidewalks - Separated from the road by some form of barrier? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo. Das ist etwas, dass ich eigentlich als zweitrangig erachtet. Beides hat Vor und Nachteile. Separates Erfassen hat den Vorteil, das man auf hohen Zoomstufen (z.b. Zoom 18+) eine genaueren Verlauf darstellen kann, der ein genaueres Routing möglich ist (z.b. komplizierte Kreuzungen) Das taggen an die Straße hat die Vorteile, das das erzeugt Kartenbild übersichtlicher erscheint und es macht das Routing einfacher. Darum geht es mir aber nicht. Ich habe für mich festgestellt, dass beide Versionen getagged werden und möchte eine Möglichkeit ausloten, welche die dadurch entstehenden Konflikte minimiert. Gruß Hubert Am 20. Dezember 2014 03:03:28 MEZ, schrieb 715371 osmu715...@gmx.de: Am 09.12.2014 um 13:17 schrieb Hubert: Ich kenne ein paar (eche/reine) Radwege, welche mit highway=cycleway getaggt sind. Allerdings habe ich Bauchschmerzen, enge Bordsteinradwege mit highway=cycleway + cycleway=sidewalk/crossing zu taggen. Das sieht dann doch sehr seltsam aus, auch wenn es unter einem systematischen Gesichtspunkt logisch wäre. Mir fehlt hier noch die Diskussion weshalb man nun etwas separat erfassen sollte bzw. nicht. Ein Bordstein ist zwar eine bauliche Trennung, aber man kann sie erwarten und stellt für Radfahrer kein Hindernis dar, wenn an den zu erwartenden Stellen (z.B. Mündungen von anderen Straßen) die Bordsteine abgesenkt sind. Oder das zumindest so vorkommt, so dass man die straßenbegleitenden Wege ohne Komplikationen befahren kann. Bei Rollstuhlfahrern mag das anders aussehen. Ich finde aber, dass man (in D-Land) eher als default annehmen sollte, dass alles Rollstuhlfahrergerecht ist und Rollstuhlfahrer an z.B. einer Kreuzung oder Einmündung alles machen können. Wenn das nicht der Fall sein sollte, sollte man sich nach einem Tagging umschauen oder ggf. eine Relation einführen, die der restriction-Relation ähnelt. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, ich habe einmal auf meiner Wiki Seite (https://wiki.openstreetmap.org/wiki/User:Hubert87/DoubleRepresentation) ein paar mögliche Kombinationen niedergeschrieben. Ich bitte um viel Feedback auf der entsprechenden Diskussionsseite. Außerdem: Am Donnerstag, 18. Dezember 2014 02:27 schrieb osmu715...@gmx.de: Was dann aber noch fies bleibt, sind solche Wege die erst straßenbegleitend sind und dann nicht mehr (weil deutlich zu weit weg). https://www.openstreetmap.org/way/202894636 Ja, solche Dinge sind wirklich schwierig zu entscheiden. Das muss der Mapper Vor Ort entscheiden. Mir hilft immer die Frage, ob es von der Rennleitung Ärger geben würde, wenn man dort auf der Straße fährt/geht, Benutzungspflicht vorrausgesetzt. Daher ist es aus meiner Sicht schwer die beiden Modelle miteinander zu vereinen, auch wenn ich gerade das an Huberts Ansatz gut finde. Ich finde genau in solchen Fällen hätte das doppelte Erfassen seine Stärke. Im Moment sieht es ja (auf der Hauptkarte) so aus, als würde auch der Gehweg dort aufhören und an der Straße ist ein sidewalk=* auch noch nicht gemappt. Am Donnerstag, 18. Dezember 2014 18:42 schrieb fly lowfligh...@googlemail.com: da finde ich cycleway/sidewalk=separate_way oder ähnliches besser. Ich glaube, so arbeitet das Lübecker Schema bei seperat gemappten Radwegen. Dort wird aus dem cycleway=track dann ein cycleway=sidepath. Das ist zwar ein gangbarer Weg, hat für mich aber dann einen Nachgeschmack, wenn das gemacht wird, um das Einzeichnen von doppelten Linien (auf opencyclemap.org) zu verhindern. Wenn es allerding gemacht wird, da es sich aus einem höherem Schema so ergibt, dann ist es (auf einmal) Ok. Am Donnerstag, 18. Dezember 2014 18:52 schrieb Martin Koppenhoefer dieterdre...@gmail.com: da finde ich cycleway/sidewalk=separate_way oder ähnliches besser. jein, ich wäre eher für eine Relation, dann ist die Zusammengehörigkeit eindeutig. separate_way hat das Problem, dass man erstens auch nicht genau weiss, welcher way, und zweitens bezieht man sich mit einem tag auf einen anderen way, den es zu einem späteren Zeitpunkt vielleicht schon gar nicht mehr gibt. Zwar könnte man fordern, wer den Gehweg verändert muss halt auch noch die Straße anschauen (und auch wenn das im Prinzip schon genau das Problem ist, so kann man es für Straßen vielleicht noch tolerieren), aber wenn man sowas erstmal eingeführt hat (tags die sich auf andere in der Nähe liegende, nicht genau spezifizierte/verlinkte Objekte beziehen), dann verbreitet sich das Prinzip vermutlich noch weiter auf andere Arten von Objekten. Das ist ein bisschen so ähnlich wie forward-Angaben auf einem Node. Ein Problem mit Relationen sehe ich auch darin, das Straßen mit z.B sidewalk=* und Zugehörigkeit zu einer (street-)Realtion nicht unbedingt auch einen seperat eingezeichneten Gehweg haben müssen. D.h. ein Datenauswerter müsste erst nachsehen ob die (street-)Relation zu der die Straße gehört und dann ob in der Relation auch noch ein Mitglied ist, welches ein Gehweg ist. Das klingt für mich kompliziert bis unmöglich. Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] cycleway=track bei Bordstein Trennung
Hallo, Am Mittwoch, 17. Dezember 2014 15:06 schrieb Martin Koppenhoefer dieterdre...@gmail.com: ach so, ich hatte den Thread bisher so gelesen, dass eine Bordsteintrennung schon als getrennt interpretiert wird, und mich dann auf Stellen bezogen, wo der Bordstein verschwindet bzw. bündig ist mit Straße und Gehweg. Das kommt gelegentlich mal vor, ist aber nicht besonders üblich (normalerweise reduziert sich nur die Bordsteinhöhe, Stichwort abgesenkt). Auch wenn ich das genau so sehe, muss ich fairer Weise sagen, dass darüber überhaupt keine Einigung herrscht. Falls das von mir so rübergekommen ist, tut mir die das leid. Ich würde, wenn Fußwege als highway=footway + footway=sidewalk eingetragen werden, die aber auch dann so eintragen, wenn der Bordstein abgesenkt, also eben mit der Straße ist. Allerding ist das zugegebener Maßen im gegensatz zu einem Hochbord, deutlich schwieriger als bauliche Trennung zu verteidigen. Wenn es ums Flächenmappen (von Wegen/Straßen) geht, dann würde ich auf jeden Fall Gehweg und Straße getrennt erfassen. Interressanter Punkt, falls du dich dabei auf das area:highway=* beziehen solltest, meine ich mich zu erinnern, dass dort durch die Mitte des Weges immer auch ein highway=* gehen soll/muss. Oder irre ich mich da gerade? Am Mittwoch, 17. Dezember 2014 15:12 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 17. Dezember 2014 um 02:24 schrieb 715371 osmu715...@gmx.de: Das Problem mit der Zuordnung der Fußwege zur Straße, bzw. umgekehrt empfinde ich als nicht so extrem. Über sidewalk=right/left/both bekommt man das schon hin. Das kam von mir, und nich von Tobias. (nur falls/damit nicht der Falsche am Pranger landet) Nur weil die in der Nähe liegende Straße einen Fußweg auf der Seite hat, wo auch ein Fußweg separat gezeichnet ist, bekommt man noch keine eindeutige Zuordnung in allen Fällen Eine direkt Zuordnung ist m.M. nach auch garnicht nötig, damit zumindest Renderer und Router das vernünftig hinbekommen. Bei echten eigenständigen Wegen würde ja das footway=sidewalk am Gehweg fehlen und an der Straße auch kein sidewalk=* gemappt werden. Am Mittwoch, 17. Dezember 2014 22:27 schrieb 715371 osmu715...@gmx.de: Ich hatte das bisher immer so gelöst, dass dann wirklich ein Weg zur Straße führt. Allerdings bei Radwegen und nur dort, wo es einen Unterschied gemacht hatte. Allgemein bei abgesenktem Bordstein, würde ich das dann auch so machen. Ich wüsste nicht was dagegen spricht. +1. Ich denke hier z.B. an T-Kreuzungen, wo ich das so machen. Bei absenkten Bordsteinen hat man in den meisten Fällen ja eine Ausfahrt, die man mappen könnte, oder es ist tatsächlich ein Überqeurungs an genau der Stelle vorgesehen. Ich wünsche noch eine Gute Nacht. Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, danke für die Beiträge. Ich habe am Anfang auch die street-relationen entsprechend der Empfehlungen des Lübecker Schemas eingetragen. Allerdings habe ich das als seeehr müsilig empfunden. Man muss für jede Straße eine eigene Relation anlege, die Straße kennzeichnen, die Nebenwege kannzeichnen, usw. Ich habe dafür viel Zeit gebraucht und nach knapp 5 Straßenzügen aufgegeben. Das Problem mit der Zuordnung der Fußwege zur Straße, bzw. umgekehrt empfinde ich als nicht so extrem. Über sidewalk=right/left/both bekommt man das schon hin. Allerdings hat man spätestens dann doppelte (eigntlich dann vierfache) Arbeit, wenn man aus Rücksicht auf den Datenauswerter andere Tags verwenden möchte. (z.B. statt sidewalk=* footway:*=sidewalk, wo ich mir dabei noch nicht sicher bin.) Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, bitte entschuldigt die verzögerte Antwort Am Donnerstag, 11. Dezember 2014 03:24 schrieb 715371 osmu715...@gmx.de: ... Es bleibt irgendwie schwer zu vergleichen. Ja, und wie war das noch gleich: Traue nie einer Statistik die du nicht selber gefälscht hast. ;) ... Eine Doppelrepräsentation würde das Problem mit dem Rendern lösen, das ich für wichtig halte. So richtig elegant finde ich das nicht. Und es gibt auch einige Mapper, die das komplett ablehnen. Zumindest habe ich das in den Diskussionen zu den Proposals von damals gelesen. Ich bin mir auch noch nicht wirklich sicher, dass die Vorteile überwiegen. Allerdings ist es im Moment die einziege Möglichkeit, die Ich sehe, beide Darstellungen zu haben. ... Wobei dann auch solche Dinge wie barrier=retaining_wall/fence etc berücksichtigt werden müssten. Wenn jemand z.B. keine turn-restriction gemappt hat, weil er es ja separat eingezeichnet hat und es deshalb nicht geht, würde das sonst zu Fehlern führen - so würde ich mir das ad-hoc vorstellen. Tut mir leid, aber da kann ich dir gerade nicht folgen. highway=footway + footway=sidewalk wird/soll ja nur gemappt werden, wenn ein Wechsel auf die Straße jeder Zeit möglich ist. Ansonsten wird doch nur highway=footway gemappt, oder? OK. Es kommt definitiv auf die Situation an. Wenn eine Straße nur einen Bürgersteig hat, dann genügt sidewalk=*. Wenn der Fußweg von der übrigen Anlage getrennt ist, kann es sich hingegen lohnen, die Wege separat einzuzeichnen. Deshalb wäre es wohl auch nicht im Sinne der OSM separates erfassen generell zu verbieten, sondern nur in bestimmten Situationen. Ich weis nicht so recht. :/ . Ich bin eher dafür, das auf irgend eine Art und Wiese einheitlich zu haben. Dass mit dem dubiosen approved bei sidewalk=* ist mir auch aufgefallen. Allerdings wäre eine Abstimmung inzwischen irgendwie sinnlos. Bei footway=sidewalk halte ich die für wesentlich wichtiger. Durch den Gebrauch ist das Tagging allerdings auch ziemlich fix. Wenn man sich das Proposal zu footway=sidewalk durchliest, könnte man bei der Abstimmung schon genau die Kritik/Befürchtung, die ich hier auch übe, vermuten. Sehe ich auch so. Vieleicht kann die Doppelrepresentation als Komptomiss dazu dienen, ohne selber alt zu fiel Ärger zu verursachen. Ich werde mal im Laufe der nächsten Woche ein paar Gedanken dazu formulieren. Mal sehen was mir dabei noch alles einfällt. Deine Anwendung ist die erste bei der ich bemerke, dass sie diese Daten benutzt. Und dann auch noch nicht einmal nur die - es sind noch mehr Tags nötig. Ob das Proposal damals mit doppeltagging eine Mehrheit bekommen hätte? Na ja... Wenn man das nur mit Gehwegen machen würde, bräuchte es nicht soviele tags. Viele der Tags sind einfach der sehr unübersichtlichen Lage (Rechtlich, OSM Tagging) beim Thema Fahrrad/Radwege geschuldet. Und dann wird man beim Routen mit simplen Algorithmen nicht mehr weit kommen. Man _muss_ sehr komplexe Algorithmen benutzen. U. a. weil Mapper Wege auch nicht mehr mit der Fahrbahn verbinden werden (weil sie es nicht wissen oder vergessen). Schon möglich, aber das gibt es bei Routern auch jetzt schon. Ich setzt dann den Start/Endepunkt nicht auf ein Gebäude, sonder einfach auf die Straße davor. Mit Maus ist das kein großes Problem, aber unterwegs für den Router macht es das nur komplizierter und die Bedienung umständlicher. Es wäre halt schön zu wissen, dass das was da so viele machen auch funktioniert. Guter Einwand. Allerdings haben viele Fußgänger und Radfahrer Router (immer noch) große Probleme vernünftige Ergebnisse zu liefern. Beste Grüße Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, Am Freitag, 12. Dezember 2014 21:18 schrieb chris66 chris66...@gmx.de: Am 11.12.2014 03:24, schrieb 715371: Eine Doppelrepräsentation würde das Problem mit dem Rendern lösen, das ich für wichtig halte. Verstehe ich nicht. Ein Renderer der beides auswertet malt dann 2 Linien neben der Straße, das soll schön aussehen? Prizipiel hast Du erstmal Recht. Es verlangt von einem Renderer, der das Vernünftig darstellen will, eine etwas kompliziertere Abfrage. Das Tagging müsste außerdem gut durchdacht werden. Als einfaches Beispiel (bitte nicht daran verbeißen) sei aber mal folgendes Situation gegeben: Eine Wohnstraße mit Borstein-Gehwegen auf beiden Seiten. highway=residential + footway:both=sidewalk highway=footway + footway=sidewalk Der Renderer, welcher den Bürgersteig an der Straße darstellen möchte, unterdrückt halt alle highway=footway + footway=sidewalk und stellt die highway=residential + footway:both=sidewalk entsprechend dar. Z.B. als roten Rand. Derjenige, der den Bürgersteig als eigenen Weg darstellen will, malt die highway=residential + footway:both=sidewalk als normale Straßen, ohne roten Rand, und stellt darfür die highway=footway + footway=sidewalk dar. So oder so ähnlich. Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Straße dargestellt. Im Monet unterschiede ich nicht benutzungspflichtig (hellblau), benutzungspflichtig (dunkelblau), Radweg/Radfahrstreifen (durchgezogene Linie), Schutzstreifen (dashed line), freigegebener Gehweg (dotted line), auf Hauptverkehrsstraßen Max 50km/h (organge), max 30 km/h (grün), Radverkehr verboten (Rot). Achso, Grundlage meines Tagging sind Infos des Lübecker Schemas, also vorhandenes tagging. Sowie einen (selbst eingeführtes, temporäres, undokumentiertes) Key is_sidepath, der mir die Information darüber liefert, ob ein Weg straßenbegleitend ist oder nicht. Was halt von den Mappern nicht erreicht wurde ist aus meiner Sicht, dass es zuverlässig ist. Wenn ich mir die OSM-Daten dazu in Rostock anschaue, sehe ich da direkt das Problem, dass eben nicht klar ist, ob ein Gehweg nun durch Bordstein oder tatsächlich von der Straße getrennt ist. Das kann man auch nicht durch irgendwelches Rendering wegbekommen. Da fehlen dann Tags - owbwohl es schon so viele sind - und Wege. Naja, wenn man davon ausgeht, dass ein Bodstein eine Trennung ist, dann stimmt das schon. Wie gesagt würde, ich mich nicht dagegen sperren, sondern es versuchen in eine Bahn zu lenken, die allgemein akzeptabel ist. footway=sidewalk ist ja schließlich ein akzeptierter (?,approved) Key, der dafür schon 2011 eingeführt wurde. Bei sidewalk=* bin ich gerade verwirrt, auf der Wiki Seite (http://wiki.openstreetmap.org/wiki/Key:sidewalk) steht als Status approved steht, bei den Proposals (http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk) ist aber bisher nicht darüber abgestimmt worden und ein Anderes habe ich nicht gefunden. Davon abgesehen ist es jedoch unbestreitbar in use. Und dann wird man beim Routen mit simplen Algorithmen nicht mehr weit kommen. Man _muss_ sehr komplexe Algorithmen benutzen. U. a. weil Mapper Wege auch nicht mehr mit der Fahrbahn verbinden werden (weil sie es nicht wissen oder vergessen). Schon möglich, aber das gibt es bei Routern auch jetzt schon. Ich setzt dann den Start/Endepunkt nicht auf ein Gebäude, sonder einfach auf die Straße davor. Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, danke für die Antworten. Am Montag, 8. Dezember 2014 19:34 schrieb fly lowfligh...@googlemail.com: Ich habe zumindest path=sidewalk/crossing schon öfter verwendet. Reinen cycleways begegne ich äußerst selten. cu fly Ich kenne ein paar (eche/reine) Radwege, welche mit highway=cycleway getaggt sind. Allerdings habe ich Bauchschmerzen, enge Bordsteinradwege mit highway=cycleway + cycleway=sidewalk/crossing zu taggen. Das sieht dann doch sehr seltsam aus, auch wenn es unter einem systematischen Gesichtspunkt logisch wäre. Ich habe meine Meinung zum Erfassen von Gehwegen nocht nicht zementiert, aber ich tendiere eher in Richtung seperatem erfassen. Am Dienstag, 9. Dezember 2014 01:55 schrieb 715371 osmu715...@gmx.de: Moin, Am 08.12.2014 um 16:50 schrieb Hubert: Hat dort jemand eine Idee. In der genannten Diskussion lief es darauf hinnaus, dass 3 Typen von Gehwegen unterschieden werden müssen. Eigenständige Gehwege, straßenbegleitende Gehwege mit abgesetzter Führung (Grünstreifen, Zaum, o.ä.) und straßenbegleitende Gehwege mit enger Führung, aka Bürgersteige (nur durch Bordstein getrennt, wechseln auf die Fahrbahn jederzeit möglich). Bei Radwegen sehe ich die Problemtik ähnlich gelagert. Meinungen? Gedanken? Danke Hubert, den Thread kannte ich noch nicht. Deine Analyse würde ich im groben auch teilen. Danke und *Puh* ;D Ich habe den Thread grob durchgelesen, aber auch vorher schon eine ziemlich statische Meinung gehabt - an der hat sich eigentlich nichts geändert. Eigenständige Gehwege - eigener Weg Straßenbegleitende Gehwege mit abgesetzter Führung - (*) Straßenbegleitende Wege mit enger Führung - sidewalk=* (*) Entscheidend ist: Was ist die Trennung? Bordstein - sidewalk=* Parkstreifen - sidewalk=* Grasstreifen mit Bäumen - sidewalk=* Grasstreifen mit mehr 5m Abstand von Fahrbahn - eigener Weg Grünstreifen aus Sträuchern - eigener Weg Zaun - eigener Weg Und was eine Hand voll Bordstein-Bürgersteigmappern schon selber erkannt hat: Es geht nicht ohne foot=use_sidepath. Da ich einen Bordstein als bauliche Trennung anerkenne, denke ich es ist OK diese auch seperat einzutragen. Und ja, foot=use_sidepath wäre dann erforderlich. Soweit ich das Konzept für Gehwege an die Straße Taggen überblicke, wäre es doch auch dort denkbar auf einzelne Personengruppen eingehen zu können. Ansonsten habe ich den Eindruck, dass die Mehrheit gegen das separate Erfassen ist, wenn es nur eine Bordsteintrennung gibt. Könnte man das nicht entsprechend deprecaten? Die Einschätzung würde ich noch teilen. Allerdings kann sich das noch änderen, oder es ändert sich gerade. Ich sehe sehr viele Gegenden, wo es kein sidewalk=* an der Straße gibt, aber der Bürgersteig schon als highway=footway eingetragen ist, allerdings ohne footway=sidewalk In D ist es halt so, dass man als Fußgänger am Straßenrand (außerorts dann auch nur auf einem bestimmten), auf dem Bürgersteig oder auf einem straßenbegleitenden Gehweg gehen muss (bis auf Ausnahmen wie für die Mitführung von Sperrgut etc). Zum anderen müssen Kinder bis 8 Jahre auf dem Gehweg Radfahren. Rollstuhlfahrer haben nur mit Bordsteinkanten ein Problem und von Blinden scheint weder bekannt zu sein wie sie sich fortbewegen, noch was beim Routing wichtig für sie ist. Rollstuhlfahrer: Sollten kein Problem mit sidewalk=* haben, weil bei solch einem Tagging zu erwarten ist, dass man bei Kreuzungen, Hauseinfahrten etc einen entsprechend abgesenkten Bordstein vorfindet. Ansonsten wäre ein Beispiel schön. Blinde: Werden schon irgendwie den Bürgersteig finden, schließlich gibt es da ja auch noch andere Probleme wie Passanten, Pfeiler für Verkehrsschilder, Fahrradwege. Soweit ich das mal gehört habe, sind für Blinde POIs wie Parkbänke wichtig. Normale Fußgänger: Sind die Mehrheit und können mit entsprechendem Abstand zur Ampel nahezu überall Straßen überqueren. Soweit teile ich die Einschätzung. Allerdings ist mir das etwas zu sehr Renderer/Router orientiert. Klar, das sind die beiden wichtigsten Nutzer der Daten, aber die Erfassung sollte dann doch auf höheren Grundlagen stattfinden. Fahrradfahrer: Wenn man das weiter Spinnt, kommt man bei Radfahrern zu dem Problem, dass sie überwiegend auf beiden Seiten Einbahnstraßen vorfinden und beim Routing dann große Umwege genommen werden, bis man an eine Kreuzung zum Wenden kommt. Das hängt ganz vom Router ab. Oder vom Radfahren. Bei einem Borstein kann Ich zwar vom Radweg auf die Straße wechseln, nicht aber von der Straße auf den Radweg Wenn da jetzt wer etwas implementiert, dass eine Pseudo-Verbindung zwischen Rad-/Gehweg und Straße interpoliert, würde ich gerne genauer wissen wie Fehleranfällig das ist. Mich auch. Außerdem dürfen Radfahrer in D per default auf der Straße fahren. Ja. IMHO ist es in Städten mit engen Straßen absurd Bürgersteige saparat zu
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Hallo, Am 8. Dezember 2014 12:05 schrieb 715371 osmu715...@gmx.de: BTW: Wie würdet ihr den Radweg am Gehweg erfassen? Eigener Weg oder cycleway=track? Wobei letzteres nicht geht, weil ja schon cycleway=lane. Ich würde dort den Radweg seperat mit highway=cycleway/path + ... eintragen und den Radfahrsteifen als cycleway=lane. (Alternative kann ich mir auch cycleway:right=lane;track vorstellen, wobei ich bezweifel, dass das Richtig interpretiert wird. Oder auch cycleway:lanes=...|...|lane|... und cycleway:right=track) Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] cycleway=track bei Bordstein Trennung
Hallo, Am 8. Dezember 2014 12:05 schrieb 715371 osmu715...@gmx.de: Was, wenn der cycleway=track nur durch Bordstein von der Fahrbahn getrennt wäre? Zum Thema Bordstein-Trennung gab es Ende Oktober eine kleine Diskussuion hinsichtlich des Eintragens von Bürgersteigen (http://forum.openstreetmap.org/viewtopic.php?id=27488. Es ging darum ob und wann ja wie Bürgersteige und Überwege eingetragen werden sollen. Zusammengefasst (Ich hoffe ich erinnere mich richtig): Keine Einigung, entweder als sidewalk=right/left/both oder als highway=footway dann aber mit footway=sidewalk. Das wird bei einem Bordsteinradweg allerdings etwas schwieriger, da es (noch) keinen äquivalenten tag zu footway=sidewalk für Radwege gibt. Hat dort jemand eine Idee. In der genannten Diskussion lief es darauf hinnaus, dass 3 Typen von Gehwegen unterschieden werden müssen. Eigenständige Gehwege, straßenbegleitende Gehwege mit abgesetzter Führung (Grünstreifen, Zaum, o.ä.) und straßenbegleitende Gehwege mit enger Führung, aka Bürgersteige (nur durch Bordstein getrennt, wechseln auf die Fahrbahn jederzeit möglich). Bei Radwegen sehe ich die Problemtik ähnlich gelagert. Meinungen? Gedanken? Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Am Di 04.11.2014 13:32 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Richtungsangaben auf nodes, die sich auf die Richtung des ways beziehen (und nicht z.B. auf Himmelsrichtungen) sind broken, nicht nur, weil nodes keine Richtung haben, sondern z.B. auch, weil es ways mit verschiedenen Richtungen geben kann, die durch denselben node laufen. Hallo, zumindest zumindest die Begründung weil nodes keine Richtung haben ist nachvollziehbar. Im Anderen Falle kann man ja die Ampel auf die Haltelinie setzten. Dann hat man keine sich kreuzende Nodes. Man müsste sich einmal mal überlegen, ob man einen Datenauswerter dabei unterstüzen kann, zu erkennen, wieviele Ampeln zusammengehören. Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Hey, On Di 04.11.2014 16:42 Florian Lohoff f...@zz.de wrote: Ich hatte mal überlegt ob man das durch eine relation lösen könnte. D.h. alle Signale die zu einer Kreuzung und einer Steuerung unterliegen zu einer Relation zusammenfassen. Damit wäre die zuordnung zu einer Kreuzung gegeben. Dann gäbe es auch die möglichkeit noch: - Ampelphasen (Wegen der statistischen 1/2 Ampelphase Wartezeit) - Laufzeiten z.b. 8-16:00 etc zu Dokumentieren. Nur so mal ins unreine gesprochen Das halte ich für einen gangbaren Weg. Meine Ideen dazu: Wenn dann die Relationen so eingesetzt werden, dass man zu einer Ampel kommt, alle anderen Ampeln der gleichen Relation auf dem Weg über die Kreuzung nicht mehr gezählt werden. Eine ähnliche Relation könnte man dann auch für Fußgänger/Radfahrer übergänge nutzen. (zweimal hintereinander highway=traffic_signals + crossing=signals oder highway=crossing + crossing=signals) Im Zweifelsfall hat man dann aber mehrere Relationen pro Kreuzung. Außerdem könnte man so auch eine Grüne Welle darstellen/simulieren. Weiß jemand ob die Ideen mit dem Junction-Proposal im Widerspruch stehen? http://wiki.openstreetmap.org/wiki/Proposed_features/Junction Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Hallo, ich habe vor einer Weile den kompletten ÖPNV (Bus) in Rostock umgestellt, da er für eine lange Zeit nicht nicht aktuallisiert wurde und sehr fragmentiert war. Dabei habe ich das OXOMOA Schema verwendet. Ich halte die Verwendung von pt=stop_position und pt=platform sehr sinnvoll. Beispiel 1: Bei uns gibt es z.B. einige Haltestellen bei denen Straßenbahnen und Busse gleichzeitig halten. Entweder neben einander mit der Platform in der Mitte, oder Hintereinander, wobei in der Regel die Straßenbahnen vorne steht. In diesen Fällen hat man zwei pt=stop_position an einer pt=platform. Beispiel 2: Je nach Abstraktionsgrad kann eine pt=platfrom als Node, Way oder Area dargestellt werden (wobei Area Interressant fürs Rendering ist) und pt=stop_position z.B. für des Line Diagramm (http://overpass-api.de/api/sketch-line?network=VVWref=23operator=RSAG) interressant ist. Natürlich ließe sich das beim Line Diagramm auch irgentwie durch eine Relation mit den pt=platform darstellen. Aber mit pt=stop_position erschein mir das sinnvoller. Nur mal eine weitere Meinung Gruß Hubert -Original Message- From: Henning Kleen [mailto:henning.kl...@informatik.uni-oldenburg.de] Sent: Sonntag, 19. Oktober 2014 12:12 To: winfi...@gmail.com; Openstreetmap allgemeines in Deutsch Subject: Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion Ich stimme Tirkon vollkommen zu, halte die Aufteilung in stop_postition und platform auch für redundant. Dem Proposal nach sind allerdings sowohl stop_position also auch platform in allen relevanten Relationen nur recomended und nicht mandatory, so dass ein Public_transport konformes Mapping auch gegeben wäre, wenn eines der beiden Elemente fehlt (Sinnvollerweise die stop_position). Es scheint nur einen gewissen Konsens zu geben, sowohl stop_position, als auch platform zu erfassen (Ich selbst habe das in Oldenburg auch so gemacht). Wenn ich darüber nachdenke widerspricht das Mappen der stop_position auch der Regel nur physisch vorhandene Merkmale zu erfassen. Im Gegensatz zu einem Haltestellenschild oder einem Bahnsteig ist die genaue Halteposition nicht an ein physisches Merkmal geknüpft. Einzig bei Bahnhöfen könnte ich mir vorstellen, dass es sinnvoll sein könnte, die Halteposition zusätzlich zu erfassen, da Züge unterschiedlicher Länge durchaus unterschiedliche Haltepositionen auf ein und dem selben Gleis haben können (kenntlich gemacht durch Haltetafeln http://www.tf- ausbildung.de/SignalbuchOnline/ne5.htm). Ob es erforderlich ist, das in der Genauigkeit in OSM zu erfassen lasse ich mal dahingestellt. Eine andere Frage wäre ob es derzeit irgendwelche Dienste etc. gibt, die sowohl platform als auch stop_position auswerten und diese Unterscheidung auch benötigen. Falls das nicht der Fall ist, so könnte man ja mal versuchen einen Konsens erreichen, die stop_position zukünftig nicht mehr zu erfassen (und als deprecated zu markieren). Ich wäre auf jeden Fall dafür. Henning Am 19.10.2014 um 11:05 schrieb Jo: Ich meine das ist historisch so entstanden. Für Zuge auf Schienen war es angeblich 'logischer' um das als Node auf dem Weg zu machen. Damals gab es auch nur ein Way für alle Schienen. Für Autobuse war es für mich jedenfalls immer logischer um 2 Nodes neben den Weg zu haben. Deswegen sind die stop_positions für mich weniger wichtig und habe ich neben die 5 Haltestellen in Belgien nicht für jede die stop_position hinzugefügt. Wo ich die aber wohl hinzugefügt habe, ist das meistens nicht auf die Position wo die Lotlinie auf dem Weg fällt. Man könnte die wohl so determinieren wenn man die unbedingt braucht, und wenn die nicht in OSM anwesend sind. Jedenfalls würde ich die nicht wegstimmen. Wenn ich Haltestellen find die auf dem Weg mappiert sind, konvertiere ich das zu stop_position + bus/tram=yes und setze die HS neben den Weg So sind allen froh. Jo 2014-10-19 5:33 GMT+02:00 Tirkon tirko...@yahoo.de: Das OXOMOA Schema und seine Abarten werden nur von einer kleinen Minderheit von Mappern verstanden. Dabei ist insbesondere die Aufteilung einer Haltestelle in platform und stop_position dem intuitiven Veständnis abträglich und zudem unnötig. Denn aus der platform kann die stop_position durch Fällen des Lots auf die Straße ermittelt werden. Wenn eine Bushaltestelle vorübergehend verlegt wird, dann wird in der Realität das Bushaltestellenschild (platform / bus_stop) durch ein Kreuz ungültig gemacht und ein provisorisches an der Ersatzhaltestelle aufgestellt. Die stop_position ergibt sich auch hier in der Realität durch das Fällen des Lotes auf die Straße. Der Mapper vor Ort kann also intuitiv das Haltestellenschild mappen und fertig. Es würde dann zur Konstruktion einer funktionierenden ÖPNV Relation ausreichen. Daher: Kann mir irgendjemand erklären, warum es bei OSM diese Zweiteilung geben muss und man nicht mit der Angabe der platform
Re: [Talk-de] Mapper aufgepasst: Sonnenexplosion kann GPS stören
OT: Zwischen Sonnenexplosion und Sonnenerruption besteht schon ein Unterschied. Im erstem Falle ist es so ziemlich egal, wo auf der Erde man sich befindet. Es seiden ich habe hier irgentwo ein Ironie Schild übersehen. Hubert -Original Message- From: Elstermann, Mike [mailto:mike.elsterm...@itc-halle.de] Sent: Donnerstag, 11. September 2014 15:22 To: 'talk-de@openstreetmap.org' Subject: [Talk-de] Mapper aufgepasst: Sonnenexplosion kann GPS stören http://geoobserver.wordpress.com/2014/09/11/sonnenexplosion-kann-gps- storen/ mikeE., der geoObserver ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderweg splittet sich in zwei Alternativen
Hallo, Ich würde das dann ähnlich von Public Transport Relationen machen. D.h. entweder die alternativen Wegabschnitte mit der role=alternative eintragen (alte Variante) oder eine Relation vom type=route_master anlegen mit den beiden alternativen Routen als Child-Relation vom type=route. Gruß Hubert -Original Message- From: hike39 [mailto:ho...@hike.de] Sent: Donnerstag, 21. August 2014 19:00 To: talk-de@openstreetmap.org Subject: [Talk-de] Wanderweg splittet sich in zwei Alternativen Hallo Gemeinde, ich habe da einmal eine Frage: Ich erfasse hier in meiner Umgebung Wanderwege, die ausgeschildert und dabei mit Routennummern versehen sind. Das Erfassen über Relationen ist für mich kein Problem. Nur splitten sich manche in Alternativrouten auf. Und da weiß ich nicht, wie ich die vernünftigerweise erfassen soll. Ich könnte natürlich den gemeinsamen Teil als eine Relation und die Zweige als eigenständige erfassen. Aber das finde ich suboptimal. Zwei unabhängige Wanderrouten, die den größten Teil auf den gleichen Wegen geführt werden, ist auch blöd. Hat jemand von Euch einen Vorschlag? Gruß hike39 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderweg splittet sich in zwei Alternativen
Die beiden Wege kommen jeweils einzelnd in eine Relation vom type=route jeweils von Start bis Ziel. Die beiden route-Relationen kommen dann als Child in die Relation vom type=route_master. Info zu route_master unter: http://wiki.openstreetmap.org/wiki/Relation:route_master bzw http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route . Oder noch mal Nachfragen Gruß Hubert -Original Message- From: hike39 [mailto:ho...@hike.de] Sent: Donnerstag, 21. August 2014 19:33 To: talk-de@openstreetmap.org Subject: Re: [Talk-de] Wanderweg splittet sich in zwei Alternativen Am 21.08.2014 um 19:10 schrieb Hubert: Hallo, Ich würde das dann ähnlich von Public Transport Relationen machen. D.h. entweder die alternativen Wegabschnitte mit der role=alternative eintragen (alte Variante) oder eine Relation vom type=route_master anlegen mit den beiden alternativen Routen als Child-Relation vom type=route. Da würde ich die zweite Variante vorziehen. Aber wie sind die Teile dann verknüpft? type=route_master Gemeinsamer Weg type=route Zweig A type=route Zweig B ? Gruß hike39 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie exakt Landnutzungsflächen eintragen?
Hey, auch wenn ich relativ neu dabei bin, möchte ich mich hierzu mal äußern. Ich habe mir zum Einarbeiten in OSM auch schon verschiedene Wiki und Foren Artikel durchgelesen. So wie ich die überwiegende Äußerungen der Teilnehmer lese, geht die Meinung dahin, das Landuse-Flächen an den Straßenflächengrenzen (und nicht den Way selbst) enden sollten (mapping what's on the ground). Ob man nun jedes Grundstück als einzelnes Landuse eintragen muss ist fraglich. Wer spaß daran hat, bitte schön, kann man machen. Meine Erfahrung mit JOSM zumindest ist, dass man eine Warnung immer dann bekommt, wenn zwei identische Landuses aneinander liegen. Daher kann es passieren, dass mit der Zeit diese nach und nach verschwinden. Vieleicht bräuchte man soetwas wie boundary type=property oder ähnlich. In barrier=fence tut's näturlich auch, solange er auch wirklich da ist. Was m. M. nach auf keinen Fall geht, ist ungefragt nicht falsche Eintragungen anderer Mapper zu löschen, weil es einem perönlich nicht geflällt. Desweiteren wird im Forum schon darüber diskutiert, ob man nicht langsam anfängt und die verschiedenen Flächen (Fahrbahnfläche/ Gehwegfläche/ Verkehrinseln usw.) zusätzlich zu den Ways zu mappen. Spätestens dann ist es hilfreich wenn die Landuses schon am Straßenrand aufhören und man dort einfach ansetzen kann. Link: http://forum.openstreetmap.org/viewtopic.php?id=19795 Gruß Hubert. -Original Message- From: Sascha Pomplun [mailto:fo...@saschapomplun.de] Sent: Freitag, 4. Juli 2014 21:03 To: talk-de@openstreetmap.org Subject: [Talk-de] Wie exakt Landnutzungsflächen eintragen? Juten Tach! Ich würde gerne klären wieviel Genauigkeit in OSM erwünscht ist, denn meine Arbeiten werden regelmäßig zerstört, so das mir langsam die Lust vergeht, überhaupt noch groß Zeit in diesem Projekt zu versenken. Was ich sehr schade finden würde, denn ich arbeite seit 2007 mit und habe hier sehr viel Zeit investiert. Aber wenn ein Großteil wieder gelöscht wird, macht das weder Sinn noch Spaß. Ich beschäftige mich in den letzten Jahren hauptsächlich mit Micro- Mapping. Dafür trage ich viele Details ein, die weniger für Autofahrer interessant sind. Denen dürfte es kaum interessieren, wo z.B. auf dem Hinterhof ein Zaun verläuft, oder ein Mülleimer steht. In diesem Zuge werden also sehr viele Details von mir eingetragen. Dazu gehört natürlich auch eine optimal eingezeichnete Landnutzungsflächen. Das heißt also wenn ich z.B. eine Schule einzeichne, endet die Fläche der Schule auch exakt an der Grundstücksgrenze. Nicht in der Mitte einer Straße oder sogar über mehrere Straßen (öffentliches Straßenland) hinweg, weil sich die Flächennutzung außer eines neuen Trägers nicht ändert. Alles was sich dahinter befindet, hat entweder eine andere Flächennutzung, oder ist öffentliches Straßenland. Genau so verfahre ich mit Krankenhäusern, Wäldern, Parks, Kindergärten, Wohngebiete und was es sonst noch alles gibt. Und genau da fängt mein Problem an. Es gibt immer wieder Mapper die diese Flächennutzungsdetails löschen und z.B. Industrie-, oder Wohngebiete einzeichnen, die über etliche Straßen - teilweise über mehrere Stadtteile hinweg, verlaufen. Einigen kann man sich mit den Mappern nie, da jeder seine Sicht der Dinge als absolut ansieht und im Wiki nichts genaueres steht. Dadurch gibt es sehr oft übereinanderliegende Flächennutzungen, oder diese riesen Flächen werden in eine große Relation gepackt. Manche schneiden dafür auch alle einzelnen Linien auf, damit die Ränder der Flächen sich nicht doppeln. Was wirklich sehr viel Spaß macht zu bearbeiten, gerade für Neueinsteiger. Das bekomme ich immer wieder auf Veranstaltungen mit, bei denen Interessierte sagen, sie lassen lieber die Finger davon und beschränken sich eher auf POIs. Es macht mir aber auch selber keinen Spaß eine Straße bearbeiten zu müssen, die noch in irgendwelchen Flächennutzunsrelation befindet. Deswegen will ich hier nachfragen, wieviel Genauigkeit in OSM überhaupt erwünscht ist bezüglich Flächennutzung. Wo soll eine eingezeichnete Fläche optimalerweise(!) enden? Dort wo auch das Grundstück endet wenn möglich, oder so das es gerade irgendwie passt, damit es auch auf der Karte schön aussieht und wirklich alles lückenlos ausgemalt ist? Durch kleinere Landnutzungsflächen ist das ganze Kartenmaterial auch wesentlich leichter zu warten und wenn mal ein Fehler passieren sollte betrifft es kein Gebiet, das man schon auf z12 erkennt. Man sieht unter anderem auch wunderbar wo z.B. ein Unternehmen endet und ein anderes anfängt, dazu reichen Zäune alleine nicht aus. Man kann damit auch sehr genau die m² gewisser Landnutzungen berechnen lassen und und und. Wer seine Karte trotzdem Lückelos ausgemalt haben will, kann die Daten immernoch entsprechend vorverarbeiten und rendern. Das ist andersrum nicht möglich ist. Mir ist klar, das es (noch?) nicht möglich ist das flächendeckend optimal zu erfassen, aber wenn die
Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Hey, das wird schwierig. Besonders in Hinblick auf backward-capability. Wenn ich das Richtig verstehe versuchst Du so etwas ananlog zu highway=footway + footway=sidewalk/crossing. Von der Key:bicycle-Seite steht zu der Werten nur: For values see access=*. (Wäre übrigens ein Grund bicycle=use_sidepath nicht zu erlauben) Gruß Hubert Am 10. Mai 2014 13:51 schrieb Falk Zscheile falk.zsche...@gmail.com: Am 9. Mai 2014 19:08 schrieb Hubert sg.fo...@gmx.de: die Grüne Box hab ich nicht gesehen. Müsste aufjedenfall mal überarbeitet werden. Ob vorgesehe, gewidmet oder ausgeschildert eingesetzt werden soll, hängt davon ab, was man unter designated versteht. Ich verstehe darunter alle ausgeschilderten Wege (Blaue VZ 237,240,241 oder eventuell sogar Radroutenschilder) aber auch rechte nichtbenutzungpflichtige Radwege (ohne jegliche Beschilderung). Daher empfinde ich verpflichtend auf den Fall als Falsch und ausgeschildert dementsprechend auch nicht passend. designated=value ist, wenn ich das richtig sehe nichts anderes und allgemein gebräuchliche Kurzform von access=designated, designated=value. Wir verwenden aber immer nur bicycle=designated und foot=designated Wie so oft bei OSM passt key=designated natürlich nicht bruchfrei zu access=value, wie es sonst verwendet wird. Sind auch Fälle denkbar wie: access=all, designated=[bestimmtes Fahrzeug]? bicycle=designated und foot=designated wird insbesondere im Zusammenhang mit traffic_sign=DE:240 bzw. DE:241 verwendet. Dann heißt es aber eigentlich access=designated, designated=bicycle, designated=foot, womit alle anderen Verkehrsteilnehmer ausgeschlossen sind. Alles höchst unbefriedigend, höchst unbefriedigend ... Oder gelingt es jemandem von euch designated und access in ein logisches und für OSM konsistentes Schema zu bringen? Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Am 10. Mai 2014 15:42 schrieb falk.zsche...@gmail.com: Am 10. Mai 2014 14:23 schrieb Hubert sg.fo...@gmx.de: das wird schwierig. Besonders in Hinblick auf backward-capability. Wenn ich das Richtig verstehe versuchst Du so etwas ananlog zu highway=footway + footway=sidewalk/crossing. Von der Key:bicycle-Seite steht zu der Werten nur: For values see access=*. Naja, so lange für backward die gleichen access-Bedingungen gelten wie für forward ist es kein Problem, sonst schon ... Ich glaub, da hast du mich missverstanden, oder ich dich gerade. Mit backward-capability meinte ich nicht in Bezug auf die Fahrtrichtung der Straße sondern in Hinblick auf schon in den Daten vorhandene Tags. (Wäre übrigens ein Grund bicycle=use_sidepath nicht zu erlauben) Da bin ich mir nicht sicher. Ohne das Proposal vollständig verstanden zu haben, wäre die Information von bicycle=use_sidepath doch (aus dem Blickwinkel von access) etwa: für die Straße an der das Tag hängt: access:bicycle=no und bicycle=use_sidepath die Zusatzinformation, dass es einen parallel verlaufenden Weg gibt, den der Fahrradfahrer benutzen kann/soll/darf, oder? Gruß Falk Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsches Wiki, access=designated kurzdefinition
Hallo Martin, von wann ist deine Definition? Es kann Zufalls sein, aber ich habe heute erst die allgemeine Definition von Dieser Schlüssel gibt an, dass ein Weg oder eine Straße für eine bestimmte Verkehrsart vorgeschrieben ist. in Dieser Schlüssel gibt an, dass ein Weg oder eine Straße für eine bestimmte Verkehrsart vorgesehen ist. in Anlehnung an die englische Definition und der Definition in der Tabelle auf der Access-Seite http://wiki.openstreetmap.org/wiki/DE:Key:access#Werte. Beste Grüße Hubert -Original Message- From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Sent: Freitag, 9. Mai 2014 18:18 To: Openstreetmap allgemeines in Deutsch Subject: [Talk-de] deutsches Wiki, access=designated kurzdefinition Die Kurzdefinition im deutschen Wiki für designated ist: Gibt die verpflichtende Nutzung eines Weges für eine bestimmte Verkehrsart an. Das trifft es m.E. nicht, es handelt sich m.E. nur um einen offiziell beschilderten Weg, ob der nun verpflichtend ist hängt von einer ganzen Reihe anderer Umstände ab. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsches Wiki, access=designated kurzdefinition
Hey, die Grüne Box hab ich nicht gesehen. Müsste aufjedenfall mal überarbeitet werden. Ob vorgesehe, gewidmet oder ausgeschildert eingesetzt werden soll, hängt davon ab, was man unter designated versteht. Ich verstehe darunter alle ausgeschilderten Wege (Blaue VZ 237,240,241 oder eventuell sogar Radroutenschilder) aber auch rechte nichtbenutzungpflichtige Radwege (ohne jegliche Beschilderung). Daher empfinde ich verpflichtend auf den Fall als Falsch und ausgeschildert dementsprechend auch nicht passend. Mit gewidmet könnte ich leben, allerdings gibt es auch Widmungen die nur auf dem Papier (Amtblatt, etc.) stehen und nicht durch Schilder, bauliche Gegebenheiten oder Markierungen offensichtlich sind. Man kann auch eine Kombination nehmen, im Extremfall einfach alles was es an Übersetzungen halt so gibt Kleine Scherz. Gruß Hubert -Original Message- From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Sent: Freitag, 9. Mai 2014 18:47 To: Openstreetmap allgemeines in Deutsch Subject: Re: [Talk-de] deutsches Wiki, access=designated kurzdefinition Am 9. Mai 2014 18:35 schrieb Hubert sg.fo...@gmx.de: Es kann Zufalls sein, aber ich habe heute erst die allgemeine Definition von Dieser Schlüssel gibt an, dass ein Weg oder eine Straße für eine bestimmte Verkehrsart vorgeschrieben ist. in Dieser Schlüssel gibt an, dass ein Weg oder eine Straße für eine bestimmte Verkehrsart vorgesehen ist. auf deutsch würde ich evtl. gewidmet schreiben, bzw. ausgeschildert. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsches Wiki, access=designated kurzdefinition
Hey, §2 Absatz 4 STVO: Mit Fahrrädern muss einzeln hintereinander gefahren werden; nebeneinander darf nur gefahren werden, wenn dadurch der Verkehr nicht behindert wird. Eine Pflicht, Radwege in der jeweiligen Fahrtrichtung zu benutzen, besteht nur, wenn dies durch Zeichen 237, 240 oder 241 angeordnet ist. Rechte Radwege ohne die Zeichen 237, 240 oder 241 dürfen benutzt werden. Linke Radwege ohne die Zeichen 237, 240 oder 241 dürfen nur benutzt werden, wenn dies durch das allein stehende Zusatzzeichen Radverkehr frei angezeigt ist. Wer mit dem Rad fährt, darf ferner rechte Seitenstreifen benutzen, wenn keine Radwege vorhanden sind und zu Fuß Gehende nicht behindert werden. Außerhalb geschlossener Ortschaften darf man mit Mofas Radwege benutzen. VwW-Stvo Zu Absatz 4 Satz 3 und Satz 4: I. Radwege ohne Benutzungspflicht. Radwege ohne Benutzungspflicht sind für den Radverkehr vorgesehene Verkehrsflächen ohne Zeichen 237, 240 oder 241. Dabei ist zu beachten, dass 1. der Radverkehr insbesondere an Kreuzungen, Einmündungen und verkehrsreichen Grundstückszufahrten durch Markierungen sicher geführt wird und 2. ausreichend Vorsorge getroffen ist, dass der Radweg nicht durch den ruhenden Verkehr genutzt wird. Im Grunde sind also alle für den Radverkehr vorgesehene Verkehrsflächen Radwege ohne Benutzungspflicht. Des weiteren kennt die WvW-STVO im Zusammenhang mit benutzungpflichtigen Radwegen noch den Begriff baulich angelegt. Früher waren das einfach alle rot gepflasteren Flächen rechts neben einer Straße. Dann haben einige Komunen angefangen auch Gehwege rot zu pflastern, so dass dieses Erkennungsmerkmal nicht mehr sicher ist. Im Grunde muss man neben dem Radweg noch einen Gehweg erkennen können. Dies kann durch Farbkontrast geschehen (Bordstein|Rot|Grau , B|Schwarz|Grau, B |Grau|Schwarz, B|Rot|Schwarz, B|Schwarz|Rot, oder bei breiten Wegen auch Grau|Rot|Grau, Grau|Schwarz|Grau oder aber auch Rot|Schwarz|Rot, Schwarz|Rot|Schwarz, wobei dann sinnvollerweise die Fläche in der Mitte der Radweg ist, da zwei Radwege ja sinnlos sind). Ein anderer Radweg kann aber auch durch Kantsteine zwischen zwei gleichen Flächen erkennbar sein (grau|grau), durch die Richtung der Pflasterung (längs|quer) oder einfach durch eine weiße Liene die einen Weg in zwei Häflten teielt. In den letzteren Fällen ist die Fläche die der Fahrbahn an Dichtesten ist meistens auch der Radweg. Erkennen kann man das dann auch an Einmündungen/ an den Furten. Der Radweg ist der Teil zwischen den dickeren Markierungen, der Gehweg der Teil zwischen der dicken Markierung (Mittig) und der dünneren Markierung. In den Fällen wo nur ein Weg /eine Furt über eine Einmündung führt ist in den meisten Fällen auch kein Radweg vorhaben. Wenn die Komune nett ist, dann pinseln die dir noch ein Sinnbild Radfahren auf die Richtige Fläche, aber das ist ja nicht in deiner Frage enthalten. Du sieht man kann einen Radweg an vielem Erkennen. Wichtig ist aber, dass immer auch ein GEHWEG vorhanden ist. Nur weil etwas nach Radweg aussieht, muss es noch lange keiner sein. Als Beispiel sein mal dieser Weg gegeben (Bing: 54,103137 12,153549) Der getrennte Geh und Radweg kommt vom Süden und Spaltet sich dann auf. Die Rote Fläche geht zur Straße. Ob sie dort auch noch als Radweg gilt ist Fraglich, da der Gehweg neben der Straße fehlt. Gruß Hubert P.S.: Bei mir in der Gegend gab es mal einen benutzungspflichtigen getrennten Rad- und Gehweg der durchgängig geteert war (Geh und Radweg) und die (bauliche) Trennung durch Bäume realisiert wurde die alle 15 angepflantz sind. Mittlerweile wurde er zu einem gemeinsamen Geh und Radweg umgewidmet/umgeschildert. -Original Message- From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Sent: Freitag, 9. Mai 2014 19:18 To: Openstreetmap allgemeines in Deutsch Subject: Re: [Talk-de] deutsches Wiki, access=designated kurzdefinition Am 9. Mai 2014 19:08 schrieb Hubert sg.fo...@gmx.de: Ich verstehe darunter alle ausgeschilderten Wege (Blaue VZ 237,240,241 oder eventuell sogar Radroutenschilder) aber auch rechte nichtbenutzungpflichtige Radwege (ohne jegliche Beschilderung). wie erkennt man eigentlich einen nichtbeschilderten Radweg? An der roten Farbe? Steht das so irgendwo in der StVO / StVG etc? Gruß Martin PS: Fahrbahnmalereien zähle ich auch zur Beschilderung (zugegebenermaßen sprachlich nicht ganz richtig). ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
