Mapillary Beispiel 3 hat vorn eine durchgehend gepflasterte Fläche, aber dann ist ein Baum dazwischen.
“Y”-Lösung: von der highway centerline als eine Linie mittig mit zusammenhängender width abgehen und dann vor dem Gehweg aufspalten zu den jeweiligen toren?
“II”-Lösung: für alle Tore eine separate highway=service, service=driveway Linie zeichnen und die breite durch die Anzahl Tore teilen?
https://radverkehrsatlas.de/regionen/parkraum
Ich möchte aber gern diese Auswertung füllen, dafür braucht es alle Einfahrten und wenn möglich auch deren breite, darum diese spezielle Frage.
Im Endeffekt ist es egal welche ich nehme, ich möchte nur gern wissen, ob eine Variante einen Vorteil hat, den ich gerade nicht sehe.
Hallo,
dann würde ich bei beiden Varianten nicht über mögliche Vorteile sondern mögliche Nachteile nachdenken.
Beide Varianten sind doch offenbar falsch.
Y ist falsch, weil keine Zufahrt so abzweigt,
II ist falsch, weil eine gemeinsame und nicht zwei Zufahrten von der Straße abzweigen
Warum nicht eine breite Zufahrt mappen? Es ist doch für den genannten Zweck nicht wichtig, welche Grundstücke erschlossen werden oder?
Will man z.B. in Zukunft auch die Anzahl Stellplätze auf privaten Grundstücken ermitteln, bräuchte man dafür irgendeine Art Datenpunkt, z. B. die Anzahl Tore, die am Ende von Einfahrten sind.
Damit könnte man eine Untergrenze der Anzahl Stellplätze angeben, es könnten aber mehr sein.
Deshalb mag ich alle Tore mappen, die es gibt, hinter denen man mindestens einen Pkw abstellen kann.
Und ich mag diese halt auch gern mit der Straße verbinden, damit die nicht einsam auf der landuse=residential Linie liegen. Ich kann mir vorstellen, dass ohne die Verbindung zu einer Einfahrt diese als (schmales) Gartentor für Fußgänger falsch-interpretiert werden können.
Ich mappe in so einem Fall die einzelnen Tore mit
barrier=gate und width=*
in der Regel mappe ich aber nicht die Fußwege, driveways nach Gutdünken (= mit geringer Priorität). Wenn der Gehweg explizit gemappt ist, könnte man von diesem ausgehend auch die Zuwegung zu den Fußwegtoren mappen, wenn man unbedingt will (bringt nicht viele praktischen Vorteile, aber man kann z.B. den Belag mappen).
In deinen Beispielen ist es doch durch die Pflasterung relativ klar, wo eine Einfahrt ist.
Ich mappe Einfahrten zu Toren alle separat, egal, wie das später auf einer Karte aussieht. Ich mappe diese auch bis auf die Grundstücke hin und verbinde sie immer mit der Haustür. Als Wegesbreite nehme ich in der Regel die Breite des Tores und beim Teil hinter dem abgesenkten Bordstein (also auf der Fahrbahn) dann die breite des abgesenkten Bordsteines dieses Weges. Also im Prinzip Deine ||-Lösung:
Bei Garagen mache ich das nicht, sondern nur eine Zufahrt mit entsprechender width=*:
Bei Extremfällen mit Garagen lasse ich das allerding auch mal weg und setze ein entsprechendes parking:<side>=no
Wichtig finde ich, dass man es konsistent macht, Du siehst ja selbst, dass es mehrere Möglichkeiten gibt.
Na ja, es ist ja nur eine mögliche Variante, da gibt es kein Richtig oder Falsch. Ich kann höchstens mal erwähnen, welche Möglichkeiten es gibt mit den entsprechenden Vor- und Nachteilen. Ich möchte aber keine Empfehlung aussprechen
Führt das nicht irgendwie zu einem zerstückelten way dann?
Ich könnte die width des kerb auch an eine node mit barrier=kerb+kerb=lowered+width=3.14 hängen, macht das sinn?
Alternativ kann man auch den ganzen kerb die ganze Straße lang mappen, das finde ich aber schwieriger machbar, da das auf den Luftbildern meist nur sehr schwer zu erkennen ist.
Deswegen mache ich das auch nur bei 5 oder mehr Garagen, wenn das Wegsegment dadurch mindestens 10 m lang wird.
Falsch wäre es nicht, aber auswerten tut das leider niemand. Allerdings hat JOSM zumindest früher rumgemeckert, wenn man einem Node eine width=* gibt, deswegen hab ich’s mir wieder abgewöhnt.
Das halte ich nur für eine Lösung, wenn man die Straße als Fläche erfasst. Sonst eher Overkill, oder? Das Parkraumprojekt wertet derzeit auch keine kerb=*-Attribute aus, auch wenn es schön wäre. Wenn ein highway=footway in einem kerb=lowered auf eine Straße trifft, man den Bordstein aber auf dem highway=footway einzeichnet, weiß die Auswertung nicht, dass dort nicht geparkt werden darf, weil wohl nur geschaut wird, welche Highway-Arten sich da treffen.
Zunehmende Detaildichte führt meistens zwangsläufig zu Zerstückelung von Wegen.
Persönlich tendiere ich eher zur “Y-Lösung” mit Tag:placement=transition - OpenStreetMap Wiki bei den “schrägen” Wegen. Genaugenommen ändert sich ja auch häufig der access-Wert ab dem Tor.
Ich persönlich würde in solchen Fällen die “II”-Lösung bevorzugen, aber zusätzlich zu dieser und der “Y”-Lösung möchte ich auch noch die “V”-Lösung ins Spiel bringen. Sozusagen als Kompromiss zwischen II und Y.
ich würde den Fußweg separat mappen, weil er klar abgesetzt ist und Bäume dazwischen sind. Die Fußzugänge würde ich dann nicht bis zu Straße ziehen sondern straßenseitig nur bis zum Fußweg, die driveways natürlich jeweils mit der Straße verbinden.
