Ja, die Bilder auf mapillary sind uralt.
Ich bin die Strecke B 286 eben abgefahren, von der A 70 in Richtung Schweinfurt kommend. Ab Höhe Mediamarkt ist 100 per Schild erlaubt, ab Brücke H.-B.-Str. 70 und ab Ende der Mittelleitplanke nur 50. Ich hab's im Changeset #167552674 aktualisiert.

Also ich bin skeptisch, ob das mit den maxspeeds auf und in Richtung Hahnenhügelbrücke richtig ist. Ich bin letzte Woche Mittwoch die Strecke gefahren, und da war noch ab Brücke Hans-Böckler-Str. 70 und ab Ende der Mittelleitplanke 50. Ich hab auch Bilder gemacht, leider hab ich die schon gelöscht, nachdem ich changeset #167240214 gemacht hab.
IMHO ist da über die gesamte Länge der Hahnenhügelbrücke 50, weil die doch kaputt ist bzw. "am Ableben" ist, und deswegen nur 50 gefahren werden soll / darf, damit die Belastung kleiner ist.

Hi,

sicher dass der Weg osm.org/way/1370709019 ein Feldweg bzw. für Landwirtschaft ist und nicht einfach bloß ein Fußweg?

Well, I just made a node (#4734072).

Are you sure that line 160 is routed over Sachsberg and not over Raiffeisenplatz?

Für diese kurzen Kreuzungs-Verbindungs-Wege habe ich zuletzt das Tag placement=transition gefunden:
osm.wiki/Tag:placement%3Dtransition

osm.org/way/1370978544

(Sorry für die späte Antwort)

𝘋𝘢𝘴 𝘸𝘶̈𝘳𝘥𝘦 𝘦𝘴 𝘮𝘰̈𝘨𝘭𝘪𝘤𝘩𝘦𝘳𝘸𝘦𝘪𝘴𝘦 𝘙𝘰𝘶𝘵𝘦𝘳𝘯 𝘦𝘳𝘩𝘦𝘣𝘭𝘪𝘤𝘩 𝘭𝘦𝘪𝘤𝘩𝘵𝘦𝘳 𝘮𝘢𝘤𝘩𝘦𝘯, 𝘥𝘪𝘦 𝘴𝘦𝘱𝘢𝘳𝘢𝘵 𝘨𝘦𝘮𝘢𝘱𝘱𝘵𝘦𝘯 𝘎𝘦𝘩𝘴𝘵𝘦𝘪𝘨𝘦 𝘻𝘶 𝘦𝘳𝘬𝘦𝘯𝘯𝘦𝘯/𝘧𝘪𝘯𝘥𝘦𝘯.

Stimmt, so etwas ließe sich verbessern, in dem man dem Gehsteig noch ein footway=sidewalk spendiert. Auf der anderen Seite müsste ein Router doch die Logik haben, den nähesten, parallelen Way zur Straße, der für Fußgänger erlaubt ist, entsprechend zum Routing zu verwenden.

𝘌𝘴 𝘴𝘤𝘩𝘦𝘪𝘯𝘵 𝘦𝘵𝘸𝘢𝘴 𝘬𝘰𝘮𝘪𝘴𝘤𝘩, 𝘥𝘢𝘴𝘴 𝘥𝘦𝘳 𝘴𝘦𝘱𝘢𝘳𝘢𝘵 𝘨𝘦𝘮𝘢𝘱𝘱𝘵𝘦 𝘴𝘪𝘥𝘦𝘸𝘢𝘭𝘬 𝘦𝘪𝘯𝘦𝘳 𝘚𝘵𝘳𝘢ß𝘦 𝘯𝘪𝘤𝘩𝘵 𝘮𝘪𝘵 𝘥𝘦𝘳 𝘚𝘵𝘳𝘢ß𝘦 𝘴𝘦𝘭𝘣𝘴𝘵, 𝘢𝘶𝘧 𝘥𝘦𝘳 𝘴𝘪𝘥𝘦𝘸𝘢𝘭𝘬=𝘴𝘦𝘱𝘢𝘳𝘢𝘵𝘦 𝘨𝘦𝘵𝘢𝘨𝘨𝘦𝘥 𝘪𝘴𝘵, 𝘷𝘦𝘳𝘣𝘶𝘯𝘥𝘦𝘯 𝘪𝘴𝘵.

Das ist wohl abhängig von der Gegebenheiten vor Ort. Hier in diesem konkreten Fall endet der separate Gehsteig zufällig in zwei anderen Wegen. Hier z.B. ist es anders, da fängt die Separierung mitten drin an: osm.org/node/254525192

𝘋𝘪𝘦𝘴𝘦𝘳 𝘴𝘦𝘱𝘢𝘳𝘢𝘵𝘦 𝘎𝘦𝘩𝘸𝘦𝘨 𝘪𝘴𝘵 𝘥𝘪𝘳𝘦𝘬𝘵 𝘮𝘪𝘵 𝘥𝘦𝘳 𝘒𝘳𝘦𝘶𝘻𝘶𝘯𝘨-𝘕𝘰𝘥𝘦 𝘷𝘦𝘳𝘣𝘶𝘯𝘥𝘦𝘯.

Hier empfinde ich immer das Dilemma, wohin mit dem Ende des separaten Ways. Lieber direkt an die H.-M.-Str. oder doch 90°-Knick und zur T.-M.-Str.? In solchen Fällen gehe ich den Mittelweg und nehme einfach die Kreuzungs-Node. 😬

𝘞𝘶̈𝘳𝘥𝘦𝘴𝘵 𝘋𝘶 𝘞𝘦𝘨𝘦 𝘸𝘪𝘦 ... 𝘢𝘶𝘤𝘩 𝘭𝘰̈𝘴𝘤𝘩𝘦𝘯 (𝘣𝘻𝘸. 𝘵𝘢𝘨𝘨𝘪𝘯𝘨 𝘮𝘪𝘵 𝘥𝘦𝘳 𝘚𝘵𝘳𝘢ß𝘦 𝘻𝘶𝘴𝘢𝘮𝘮𝘦𝘯𝘧𝘶̈𝘩𝘳𝘦𝘯), 𝘰𝘥𝘦𝘳 𝘸𝘦𝘨𝘦𝘯 𝘥𝘦𝘮 𝘦𝘳𝘩𝘰̈𝘩𝘵𝘦𝘯 𝘉𝘰𝘳𝘥𝘴𝘵𝘦𝘪𝘯 𝘣𝘦𝘪𝘣𝘦𝘩𝘢𝘭𝘵𝘦𝘯?

Diese Wege würde ich nicht als separaten Way mappen sondern die Information Gehsteig / Fahrradweg mit an den Breite-Wiese-Way nehmen. Dann gibt es auch keine Probleme bezüglich oneway für den ganzen Gehsteig-Way vs. nur für Fahrräder.

Einen absolut standardmäßigen Gehsteig, also bei dem der Gehsteig mittels Bordsteinen von der Fahrbahn getrennt ist (wie https://upload.wikimedia.org/wikipedia/commons/9/91/Eselsh%C3%B6he_West-II.jpg) ist doch sinnlos als eigenen Way zu mappen. Deswegen habe ich diese "Standard-Gehsteige" gelöscht und die Information, das ein Gehsteig vorhanden ist, zum Straßen-Way hinzugefügt (sidewalk:left/right=yes). Ich glaube das mappen als separaten Way kommt aus Ländern, in denen es illegal ist, die Straße ohne Überweg zu queren (USA z.B., "jaywalking"). Da schaut das dann natürlich ganz anders aus, wenn der Fußgänger die Straße nicht betreten darf, da macht das mappen als separaten Way absolut Sinn. Was ja aber in DE kein Problem ist.

Insofern mache ich es normalerweise so: "Standard-Gehsteige" werden wie gesagt als sidewalk-Tag zur Straße hinzugefügt. Kann man vom Gehsteig aus aber nicht direkt die Fahrbahn betreten, weil da ein Objekt zwischen Fahrbahn und Gehsteig ist, mappe ich das aber als separaten Way. Das ist z.B. der Fall bei Parkbuchten, Bäumen (wie im Bild), Grünflächen, usw., dann mit sidewalk=separate am Straßen-Way. Ist der "Weg für den Fußgänger" jedoch deutlich von der Straße getrennt (z.B. durch einen Höhenunterschied, nicht im Gehsteig integrierte Grünfläche, usw.), gibt's natürlich auch ein eigenen Fußgänger-Way, jedoch ein sidewalk=no an die Straße. Das ist z.B. der Fall bei Verbindungsstraßen außerorts, an denen an der Seite noch ein extra Fußgänger/Radfahr-Weg entlangführt, der meist für die Landwirtschaft freigegeben ist.

Dazu bin ich der Meinung, das dieses Problem separater / nicht-separater Way auch daher kommt, dass das OSM-Datenmodell so wie es aktuell existiert, eigentlich falsch ist. Wir mappen Straßen (und allgemein Wege) als Ansammlung von Vektoren, obwohl das eigentlich Flächen sind. Genauso die Bordsteinkanten: Die sind ein Node (barrier=kerb) obwohl sie besser ein Vektor bzw. Way wären.

Halb-OT: Ich finde den Key "sidewalk" eigentlich falsch gewählt, denn von der Begrifflichkeit her beschreibt das für mich erst mal nur den "Gehsteig". Gewollt ist ja aber eher zu beschreiben, wo Fußgänger laufen dürfen. IMHO wäre der Key "footway" hier vom Namen her besser geeignet. Also so wie für die Radfahrer: Dort heißt der Key "cylceway", IMHO korrekterweise...

👍 :-)

Ja, das mit den data-consumer ist so 'ne Sache. Für mich persönlich ist sowas eher ein Fall für "Tagging für den Renderer" (osm.wiki/Tagging_for_the_renderer) wobei hier statt renderer consumer besser ist. Schlussendlich ist der Name ja vorhanden, er ist ja in der Relation enthalten, von der die sop_position referenziert wird. Im Wiki steht auch, das der Name an die stop_position besser nur ran kommt, wenn es keine Relation gibt (osm.wiki/Proposal:Public_Transport#Stop_Position).

stop_position bei Bussen ist ja noch einfach, da gibt es nur eine. Kompliziert wird es bei Zügen, dort gibt es wirklich unterschiedliche Stop-Positionen, je nachdem wie lang der Zug ist. :-)

IMHO ist das "Maibacherstraße" ein Schreibfehler auf dem Schild. Sowohl im Fahrplanbuch und im Liniennetzplan ist die Straße korrekt geschrieben: https://imgur.com/a/H7zibiO
Hast Du zufällig ein Foto? Dann würde ich das an den Verkehrsmeister der Stadtwerke schicken, damit die sehen, das sie hier einen Schreibfehler gemacht haben.

Frage: Wieso hast Du den Namen der Haltestelle an die platform und stop_position nodes dran gemacht? IMHO sollte der Name der Haltestelle (solang auch wirklich alle Haltepositionen usw. gleich heißen) in der stop_area-Relation reichen.
Außerdem sollten keine Abkürzungen verwendet werden, siehe osm.wiki/DE:Abk%C3%BCrzungen
("Geschw.-Scholl-Str." --> "Geschwister-Scholl-Straße")

Hat die SKD BKK da echt 'ne Apotheke? Oder ist das bloß eine Geschäftsstelle? (osm.wiki/Tag%3Aoffice%3Dhealthcare)

Ich hab's jetzt doch so gelassen, schließlich sind die Hausnummern schon in den Häuser-Ways mit drin.

Das stimmt, sorry, das habe ich übersehen. Ich fixe es sobald ich heute Abend von der Arbeit komme...

Hey,
kurze Frage: Laut Changeset-Kommentar ist von charging station die Rede, der Node ist aber amenity=car_sharing. Ist da evtl. amenity=charging_station gemeint?

Wenn Du die Parkplätze auf der Straße mappst (osm.org/way/1311065657), könntest Du der Straße dann noch ein parking:<Seite>=separate spendieren?
(osm.wiki/Street_parking#Separately_mapped_parking_areas_and_spaces)

Thank you for noticing. Hopefully 58.22 will appear soon in the F-Droid repositories...

Hi,

puh, das ist 12 Jahre her. ;-)

Schlussendlich ist es eine Wiese, auf der im Sommer gern mal sonnengebadet und gegrillt wird, man muss sich nur vor der Hundekacke in Acht nehmen. Viel Vegetation ist da ja auch drauf, vielleicht wäre landuse=grass das bessere Tag...

Stimmt, das originale Proposal aus 2009 für parking=garage_boxes hatte etwas anderes im Sinn: Große Areale mit Garagen, die man sich mieten konnte. Die Praxis in 2024 zeigt, dass das Tag mittlerweile für Standard-Fertiggaragen verwendet wird: http://overpass-turbo.eu/s/1OOL
Es macht ja auch Sinn, der Name garage_boxes passt perfekt dafür. Und für die großen Garagen-Areale steht ja noch landuse=garages zur Verfügung.

Für mich bedeutet building=garages nicht das gleiche wie parking=garage_boxes. Das eine beschreibt das Gebäude, das andere den Verwendungszweck. Ich hatte z.B. schon mal in einem Garagengebäude meinen Arbeitsplatz.

Insofern würde ich kein großes Parking Lot daraus machen, aber den beiden building=garages noch ein amentiy=parking, parking=garage_boxes, access=private spendieren.

Nach den Überlegungen im Changeset 153727701: ja, stimmt.

Wie geht man hier mit den einzelnen Parkplätzen um, die nicht Garagen sind? Mir fällt da spontan nur ein, die Fläche mit parking=garage_boxes; surface zu taggen und für capacity=<Anzahl aller Parkmöglichkeiten> zu nehmen. Und an die building=garages dann noch capacity=<Anzahl der Garagen dieses Ways>. So kann man von der Gesamtanzahl aus dem amenity=parking-Way und den Anzahl aus dem building=garages-Way die restlichen berechnen.

Was meinst Du dazu? 🤔