Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

ja klar, wenn man die Radwegeigenschaften für das Rendering an der Straße haben will muss man die Straße in diesem Schritt auch weiter aufteilen. Soweit es halt für die Renderregeln notwendig ist, und umgekehrt kann man zusätzlich auch alle Segmente verbinden, die man gleich rendern will.
Der Algorithmus könnte einen Buffer um die Radwege legen und darin alle Straßen suchen, und davon die nächste nehmen. Das für alle nodes des Radwegs machen, ggf. noch prüfen ob die Straßensegmente alle verbunden sind und ggf. fehlende Zwischenstücke suchen (per Routing). Welchen Abstand man dabei setzen will ab dem man es nicht mehr macht, das macht man abhängig von der Ziel-Zoomstufe und der Straßenbreite die man dort rendert.

Nur mal als Fragmente, ich gebe zu dass es da viele schwierige Probleme gibt, vielleicht geht es auch gar nicht zuverlässig, jedenfalls gibt es sicher Stellen wo es nicht gehen würde bzw. Fehler machen würde.

Viel einfacher wäre es dadurch, dass man als Mapper mit einer Relation die Zuordnung Straße - Radweg definiert, dann würde es ausreichen, für die Wege für die es Relationen gibt, die Eigenschaften zu übertragen, das könnte durchaus ein dauerhafter Verarbeitungsschritt sein und müsste nicht jeweils on the fly in einer Datenbankabfrage generiert werden.

Hallo Dieter, du hast *"wenn der Mapper fürs Mappen wenig Zeit hat" ins Wiki als Kriterium fürs Getrennt-Mapping geschrieben.

Das Anlegen eines einfachen separaten Radwegs im ID mit zwei Knoten braucht 6 Klicks.

Das Anlegen eines Radwegs als Attribut an eine bestehende Straßenkante braucht 4 Klicks. Wenn man erst die Vorlage “Fahrradstreifen” sucht braucht es 6 Klicks und ein “F” in der Vorlagensuche. Die Klicks für das Eingeben der Geometrie fallen komplett weg.

Weitere Attribute muss man immer eingeben, egal ob separat oder zusammen. Vorlagen können bei Beiden gleichermaßen helfen.

Fazit: Die Unterschiede sind nicht relevant, wenn, dann müsste das als Pro auf der anderen Seite stehen.

da hast du dich verlesen, das wenig Zeit haben Argument habe ich für das Gemischtmappen ergänzt, nicht für das getrennt Mappen

In Josm kannst du mit alt+a einen neuen tag hinzufügen, das Eintragen von Geometrie dauert immer länger, erst recht wenn man es sorgfältig macht

Oh, ich hab es in der Änderungsansicht gelesen und falsch einsortiert und mich echt gewundert, sorry! Als sonderlich relevant emfinde ich es trodtzem nicht. Wenn ich keine Zeit habe kann ich auch schnell Linien zeichnen, dann bin ich halt ungenauer. Besser grob als gar nicht kartiert. Aber ja, wenn man es sorgfältig macht ist das Linienmappen aufwendiger.

Wenn ich hier so mitlese scheint mir, den SOTM Vortrag von cylcestreets hat keiner angeschaut. Zur Erinnerung https://www.cyclestreets.org/news/2019/09/22/sotm2019/ - ganz besonders für die Radschienenleger, aber nicht nur, und ausgenommen freilich, wenn wir die Farbe der Pflasterung mappen, aber selbst dann?

vor allem weil ja eine Linie nicht reicht, man muss die dann auch an den Einfahrten und sonstigen Querungen verbinden, und diese ways muss man dann auch alle taggen. Und diese Details hat man sonst in der Regel auch einfach nicht, wenn man es über Attribute des highways macht, weil wenn man das alles mappen würde, dann würde man einen separaten Radweg auch mit einem eigenen way mappen :wink:

Genau. Im Prinzip kann ich dann “meine” (eingegebenen Daten) nur noch nutzen, weil andere sie mir vor-verarbeiten oder das Produkt zur Verfügung stellen. Und wenn ich darauf angewiesen bin, dass sie mir jemand vorbereitet, wo ist dann der Sinn, sie erst komplex einzugeben.

Das ist das nächste Problem.

Nur wenn Du überall auf der Welt Daten eingibst und Karten von überall und allem produzieren willst, dann schon, ansonsten kannst Du das für “Dein Gebiet” vermutlich auch allein leisten. Ist beim Routing und Rendering ja auch nicht anders, das könntest Du alles auch alleine machen, aber ist sehr viel Arbeit, und daher wird man normalerweise den Dienst von irgendjemandem nutzen, der diese Arbeit schon gemacht hat und dir das Ergebnis zur Verfügung stellt.

Es geht ja nicht ums “komplexe” Eingeben, sondern um das einfache Eingeben ohne Sonderregeln (eigener Weg mit eigener Fahrbahn als eigener way), das halte ich für weniger komplex als abstrakte cyclway:right:width=2 Angaben auf einer in der Nähe liegenden Straße verbunden mit der Erwartung, dass deswegen der Fahrradweg nicht mehr als way gemappt wird. Was komplexer wird ist die Zuordnung der Straße zum Fahrradweg, es ist aber nicht so, dass die überhaupt für alle Datennutzer relevant wäre.

Hallo Hungerburg,

jetzt hast du nahezu den gesamten Abschnitt ohne Ankündigung gelöscht. Nach dieser Disskussion hier empfinde ich das als unangebracht. Wir hatten hier darüber diskutiert, ob die Auflistung der Vor-/Nachteile dort reingehört da die sehr groß ist. Da bin ich auch dafür, es bei einem Verweis zu lassen. Aber von Alles-Löschen hat bislang Keiner gesprochen.

Hier haben sich schon Viele einen Kopf über diesen Text gemacht, das wäre nun alles weg. In einem solchen Fall sprech deine Ansichten bitte hier erst an, es kann ja duchaus sinnvoll sein. Statt Alles zu Löschen dann auch eher das Relevante (die Handlungsempfehlung?) an eine bessere Stelle schieben.

Ich habe ihn mir angeschaut nur noch keine Zeit dazu, hier zu antworten.

Einige Probleme des Getrennmappings hat er echt gut dargestellt. Es ist Wasser auf meine Mühlen, dass weder die eine noch die andere Mappingart in allen Fällen die bessere ist. Das sollten sich z. B. die hoffentlich Mitlesenden der Berliner Verkehrswende-Mapper anschauen, deren Wiki-Formulierungen schon nach “Verfechten” des einen Schemas klingen.

Allerdings bin ich aus dem Vortrag nicht schlauer geworden. Er sagt zwar, dass er im Flächenmapping den Ausweg sieht. Er erklärt aber nicht, wie das funktionieren soll. Wie bekommt er z. B. die Zuodnung der Flächen zu den Linien hin, wenn die Attribute an den Linien stehen, die Linien aber innerhalb einer Fläche geteilt sind und dort die Attribute wechseln?

Ich hatte ja gedacht, wenn der Router etwas abstrakter routen will, nimmt er die Linien der Fahrbahn statt die der mikro-gemappten Seitenbereiche. Ihn verstehe ich aber so, dass er fürs gehweg-Routen über Gehweg-Flächen routen will (bzw. Radweg). Da frage ich mich, wie er auf einer wabernden Fläche mit ständig ändernden Breiten erkennen will, ob die Fläche einen abbiegenden Gehsteig darstellt oder nur einen etwas unförmigen Gehsteig. Ist doch auch wieder nur “Raten nach Formen”.

Hallo Jochen, das gehört dort einfach nicht hin, nicht in dieser Ausführlichkeit. Ein eh schon langer Hinweis ist ja dort geblieben. Die viele Mühe, die es gemacht hat, das zusammenzustellen muss nicht umsonst gewesen sein. In einem Mediawiki geht nichts verloren - an der Stelle “In Abhängigkeit der” beginnend steht hier der Copy Paste freundliche Quelltext https://wiki.openstreetmap.org/w/index.php?title=DE:Tag:cycleway%3Dtrack&action=edit&oldid=2240251 um ihn an einem geeigneteren Ort neu zu platzieren. Vielleicht als ein Abschnitt von https://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren ? Es müsste aber selbst dort irgendwie erklärt werden, warum gerade cycleway=track so ausführlich diskutiert wird, wo es sich ja um einen Tag auf dem absteigenden Ast handelt, vgl. https://taginfo.openstreetmap.org/tags/?key=cycleway&value=track#chronology - Es muss da noch etwas Größeres dahinter stecken, das auszusprechen aber scheints nicht nur mir die Worte fehlen.

Bin diesbezüglich in keiner besseren Situation. Das erste das auffällt ist der reißerische Titel Is the OSM data model creaking? Der Anfang ist aber gleich gut: Wir modellieren flows. Das ist schon einmal eine Ansage: Wie soll ein flow OTG wahr sein? Aber eh, aus der Sicht von jemandem, der seit über einem Jahrzehnt an einem Router arbeitet, da kann es schon so aussehen. Und recht überlegt, so falsch ist es womöglich gar nicht. Denn es macht die Daten für Zwecke der Navigation brauchbar, einfach und gut. Ich kann mir vorstellen, dass Grundlagen für Navigation schaffen das Hauptmotiv von sehr vielen Edits an den Daten ist.

Weil, Neulinge bekommen das ja auf der Willkommensseite nach dem Anmelden so vorgesetzt, openstreetmap ist dazu da, Dinge in der Welt, an denen man ein Interesse hat, mit ihren Geokoordinaten in die Datenbank zu stellen. Bekannte von mir haben schon vor fünf Jahren das Interesse verloren, weil eh schon alles drin ist. Und es ist wirklich viel drin. Auch viel Unnützes, aber wer soll das entscheiden, und Platz ist Ende nie.

Der Vortrag kommt dann über ein paar Umwege zu dem Schluss, dass das Mappen von immer mehr flows, die sich ja ausgezeichnet als Linien darstellen lassen: Hier gehen die Leute, da fahren die Räder, dort fahren die Autos, die Mädchen nach links, die Knaben nach rechts; einen Haufen neue Informationen bringt, die sich für Navigationszwecke verwenden lassen, aber das Ende der Fahnenstange auch nicht ist. Nicht zuletzt, weil die Abbildung sich nicht in sinnvolle, verständliche turn-by-turn Anleitungen übersetzen lässt.

Richtig paradox wird es dann, wenn ich so Zeug lese, wie hier im Thread, "man könnte ja auch den “highway” als Attribut vom “cycleway” mappen, ganz so, als würde “highway” für Fahrbahn stehen. Highway steht für Straße, und da gehört mehr dazu als die Fahrbahn. So weit ist das Separieren scheints schon, dass Leute vor lauter flows separieren die Lebenswelt nicht mehr kennen. Das betont und damit endet ja auch der Vortrag, dass es ein Manko ist, dass es kein Konzept für so etwas alltägliches wie eine Straße gibt, das aber ein gravierendes ist, in einer openstreetmap nicht zuletzt, und dem abgeholfen werden muss. Von daher wohl der Titel des Vortrags.

Das mit den Flächen, als eine Art Relation, für die keine Linien gesplittet werden müssen, die diverse Inhalte erfassen kann, ohne dass dafür eine neue Rolle erfunden werden müsste usw. Das wäre ein Hit. Als ein Platzhirsch hat cyclestreets.net ja Ressourcen. Flächenrouter sind nicht trivial zu machen. Fußrouting das das nicht kann, das hat den Namen nicht verdient. Radrouting gehts wohl ebenso. Sogar Autorouter kämpfen ein Einzelfällen. Nur Bahnrouter nicht :wink:

damit Flächenrouting für Fußgänger überhaupt funktionieren könnte bräuchte man vollständige Daten was relevante Hindernisse angeht, jeder Zaun und jede Mauer und Böschung, jedes Cliff und jeder Graben, etc. lückenlos und detailliert, vielleicht gibt es das in Deutschland in manchen Gegenden, aber die Idee die existierenden Wege als Linien vorzugeben macht das ganze auch schon sinnvoll nutzbar lange bevor es „komplett“ ist.

Ich bin ja garnicht dagegen. Nur finde ich es merkwürdig, dass wir hier über den Rext reden und du ohne zu reden ihn einfach raus nimmst.

Schwamm drüber!

Ja, dort passt es gut.

Meines Erachtens gehört die Ausführlichkeit der Vor- und Nachteile auch dort nicht hin, da bin ich deiner Meinung. Dazu habe ich ja die Vor und Nachteile in einer eigenen Gegenüberstellung zusammengesammelt.

Eine Entscheidungshilfe passt da aber sehrwohl. Unter “Hinweise” gibt es bereits eine Überschrift “Entscheidungshilfe zwischen footway, cycleway und path”. Davor oder danach könnte es als “Entscheidungshilfe zum Erfassen des Radwegs als eigenständige Linie oder an der Straßen-Linie” .

Die übergeordnete Überschrift sollte m. E. aber nicht “Kontroversen und Mehrdeutigkeiten” heißen, wenn dort Entscheidungshilfen enthalten sind. Im Text wird ja bereits darauf hingewiesen, dass die Alternativen häufig diskutiert werden. Was mit “Mehrdeutigkeit” gemeint ist, erschließt sich mir auch nicht.

Allerdings frage ich mich, ob einige der Kontroversen nicht bereits von der Praxis beantwortet wurden:

Ist das noch kontrovers? Beschwert sich z. B. heute noch jemand, wenn man bei einem gemeinsamen Geh-/Radweg mit Zeichen 240 das ‘hw=cycleway’ durch ‘hw=path’ ersetzt?

Das ist hier im Forum doch recht oft ein Thema. Das zeigt schon, dass es wichtig ist. Auch bedarf es Aufklärung, weil gerade beim Getrennt-Mappen viel falsch gemacht wird.

Grundsätzlich finde ich die Anleitungen der Berliner-Verkehrswendegruppe dafür sehr gut. Wenn man das Zusammenführen könnte, das wäre schön. Allerdings beschreiben die Berliner nur das Getrennt-Mappen, alles andere wird eher beiläufig erwähnt. Die anderen Taggingschemen sollten in der gleichen Qualität beschrieben werden. Auch deren Empfehlung widerstrebt mir zutiefst, für Gehsteige und Radwege getrennte Linien zu zeichnen.

Noch eine mögliche Baustelle im Wiki … ich muss erstmal meine offenen Baustellen beenden.

Ich hatte auch schonmal überlegt, ob man beim Seperat-Mappen die kontinuierliche Querungsmöglichkeit über eine Fläche abbildet. Nur im Bereich der Querungsmöglichkeit ist die Fläche mit Radweg und Fahrbahn verklebt. Ein entsprechendes neues Attribut sagt aus, dass die Fläche nur eine abstrakte Übergangsmöglichkeit darstellt. Ggf. erhält die Fläche Attribute für Widerstände wie z.B. Bordsteinhöhen.

Es werden also nur die Flächen getaggt, die fürs Routing notwendig sind mit dem Ziel, bestimmte Linien in bestimmten Abschnitten miteinander zu verbinden. Das würde auch für das im Vortrag genannte Beispiel mit fußgängerrouting “nach rechts” helfen.

Das ist etwas Anderes, Abstrakteres, als das Abzeichnen der Fahrbahn und Radwegflächen von den Luftbildern, wie es im Flächentagging mitunter gemacht wird.

Allerdings ist es in OSM untypisch, logische Verknüpfungen zwischen den Linien über Flächen abzubilden. Das machen sonst immer Relationen. Mit Relationen ist das aber nicht handhabbar. Es wäre eine Flut von Drei-Kanten-Relationen. Dass Radweg und Straße bei Beginn und Ende der kontinuierlichen Querungsmöglichkeit gesplittet werden müssten ist auch blöd.

Neukölln, deren “Karte” heut in der review gefeatured wurde, dort gehts in die Richtung. Ich bin immer wieder erstaunt, wofür Leute Interesse aufbringen. In meinen Augen ist die vorgestellte Ausarbeitung keine Karte, sondern ein Plan. Sie geht weit über das hinaus, was man als Stadtplan kennt. Von der Anmutung her ist das so etwas der Art, was Architekten aus den Plänen machen, die sie von den Bauherrn bekommen oder vom Tiefbauamt. Es muss im ArcGIS da einen Knopf dafür geben. Die Neuköllner erzeugen die Flächen aber aus Linien. Das ist trotzdem etwas ganz etwas anderes als eine Karte, wie OSM-Carto.

Hierbei zu tun, als sollte die ganze Welt dem nacheifern, das führt zu hypergemappten Mini-Inseln die an ihren Enden ausfransen, auf sehr sehr lange Zeit. Als lokales Projekt ist es aber recht gut gediehen. Immerhin werden sogar Radwege die als lane Attribut an der Straße erfasst sind als Flächen gerendert, was angeblich viel “post-processing” erfordert. Ich würde meinen, dass nun nicht mehr viel fehlt, mit sidewalks ebenso zu verfahren?

Ob sich die generierten Flächen für Routing weiterverwenden lassen? Selbst wenn eine Programmierstunde so viel kostet wie 100 Mapperstunden könnte sich das auszahlen.

Auch A/B-Street wurde erwähnt, das hat einen guten Fußrouter, aber die Herangehensweise ist eine ganz andere. Bei den einen geht es um ein statisches Abbild, der andere will Verkehr simulieren. Interessanterweise ist A/B Street mit Attributen viel besser bedient als mit separaten Ways. Hat auch ganz einen ganz anderen Begriff der “Straße”. In Neukölln könnte ich meinen, die Straße ist der Raum, der zwischen den Landuse=Residential ausgespart ist. In A/B-Street ist die Straße ein multimodaler Verkehrsweg.

Ich hab die Sammlung der Für und Wider im Detail durchgelesen. Das ist ein Arbeitspapier. Sehr fundiert. Aber mir fällt beim besten Willen nicht ein, wie das in den Radwege-Kartieren Artikel einfügen, obwohl die Angelegenheit dort sogar mehrfach angesprochen wird.

In diesem Zusammenhang sollte man aber auch bedenken, wie die Neuköllner dort vorgehen: Dieses Rendering basiert nicht nur auf Linien, sondern auch auf Flächen. Hier werden massiv landuse=residential für den Renderer effektiv missbraucht. https://www.openstreetmap.org/#map=19/52.47845/13.43894
Diese werden genutzt um die Grenzen des Gehweges nachzuzeichnen…

Straßenraumkarte Neukölln…

Interessant…: https://supaplexosm.github.io/strassenraumkarte-neukoelln/?map=micromap#20/52.47865/13.43815

Sven

stimmt, das halte ich für falsch, die residential landuse an der Gehwegkante aufhören zu lassen. Bei geschlossener Bauweise wie hier in Neukölln endet der residential landuse in der Regel an der Gebäudekante. Das sieht nach tagging für den Renderer aus. Die Gehwege sind klar Teil der Straßen.

Hallo,

als Teil der Berliner Verkehrswendegruppe und Macher der Neuköllner Straßenraumkarte fühle ich mich angesprochen :wink: Bin zum Jahreswechsel hier schonmal auf den Thread aufmerksam geworden und war heute etwas platt, wie viel seitdem dazugekommen ist. Daher nur grob ein paar Erläuterungen zum Thema unserer Mapping-Empfehlungen und -Praxis.

In der separaten Kartierweise sehen wir grundsätzlich eine Reihe überwältigender Vorteile (Barrierefreiheit, lagegenaues Routing, Übersichtlichkeit bei großen Massen an Detail-Tags, Analysen auf Basis von Attributen und Geometrien…). Viele andere Mapper an anderen Orten scheinen dies zu teilen, denn ansonsten würde sich diese Praxis wohl nicht so durchsetzen wie sie es zur Zeit tut. Gleichzeitig kennen wir als Mapper, die sich teils selbst mit Datenanalysen beschäftigten und überwiegend selbst regelmäßig damit routen, die Fallstricke, die diese Praxis mit sich bringt, insbesondere handwerkliche Fehler, daher die detaillierten Tagging-Guides und die “Warnhinweise”.

Es darf nicht vergessen werden, dass die Empfehlungen in einem großstädtischen Umfeld entstanden sind (und im Wiki im Berlin-Namensraum dokumentiert sind), wo es 1) ganz andere Ansprüche an solche Daten gibt, z.B. große Nutzergruppen, die von Barrierefreiheits-Informationen profitieren (vom Rollstuhl bis zum Lastenfahrrad), 2) traumhafte Daten-Grundlagen zum Abgleichen existieren, z.B. zentimetergenau eingemessene Bordsteinkanten, jährlich neue hochaufgelöste Luftbilder oder vielerorts stets aktuelle Mapillary-Bilder und 3) eine stärkere Community als an anderen Orten, die eher in der Lage ist, diese Daten zu pflegen und zu nutzen. In einer Gemeinde im Berliner Umland, in der vielleicht noch nicht mal alle Hausnummern gemappt sind und der Bäcker-POI das letzte mal vor 8 Jahren angefasst wurde, habe ich große Freude, schlicht ein “sidewalk”-Attribut an die Straße zu pappen. Das tolle ist ja, dass sich die verschiedenen Varianten nicht ausschließen und an einem Ort eben das entsteht, was den Mapping- und Auswertungs-Interessen vor Ort entspricht.

Für mich persönlich ist klar, dass das manchmal beschworene “Umwege-Problem” im Routing in städtischen Kontexten mit regelmäßigen Kreuzungen irrelevant ist, zumindest im Vergleich zu den dafür gewonnenen Vorteilen, die diese Methode mit sich bringt. Wenn jemand einen 100-Meter-Umweg gehen musste, weil er/sie nicht mitdenken konnte, dann ist es das für mich wert, wenn ein Rolli dafür nicht irgendwo an einem Bordstein oder einer Reihe parkender Autos hängen bleibt (denn dieses Problem lässt sich oft nicht visuell/neuronal befriedigend lösen). Einen zentralen Nachteil, den wir beobachten können, sind teils umständliche Routing-Ansagen bei komplexeren Knotenpunkt-Situationen. Aber das ist nun wirklich nicht unlösbar, sondern derzeit in der Masse wohl schlicht ein zu unwichtiges Problem. Wir hatten in letzter Zeit regelmäßig Kontakte mit Routing-Entwicklern und insbesondere für die größeren ist klar, dass sie Features erst dann supporten, wenn sie sich “lohnen” und neuere Taggings erst berücksichtigen, wenn sie wirklich weit verbreitet sind - auch wenn diese zur Lösung lange bestehender Probleme beitragen (z.B. das is_sidepath-Schema oder bicycle=optional_sidepath).

Zur Straßenraumkarte…

Es ist ein Plan und Architekturkarten waren tatsächlich ein Vorbild. Präzises Mapping reduziert Generalisierung und kann dies offenbar sogar bis zu einem Maße tun, bis aus der Karte (wieder) ein Plan wird. Dafür braucht es nur Präzision, aber keinen Bruch mit OSM-Prinzipien. Soetwas zu tun kostet Geduld und Zeit (und gute Datengrundlagen, siehe oben), und ich für meinen Teil werde dafür belohnt mit dem Nutzen, Staunen und der Dankbarkeit, die einem Akteure aus Verwaltung und Zivilgesellschaft dafür entgegenbringen und dem Mehrwert, den allein der experimentelle Charakter der Karte erzeugt.

Radstreifen verlaufen stets exakt parallel zu den Kfz-Fahrspuren (denn sie sind eine Fahrspur für ein anderes Verkehrsmittel auf der selben Verkehrsebene). Gehwege bilden davon unabhängig eine andere Verkehrsebene und orientieren sich in ihrem Verlauf an einer anderen Umgebung - ihre Geometrie lässt sich also regelmäßig nicht aus der Fahrbahn ableiten. Davon unabhängig mappen wir Gehwege nicht fürs Rendering, sondern für den Datenmehrwert (siehe oben).

landuse=residential reicht in Berlin “traditionell” bis zum Bordstein; für die Straßenraumkarte ist das in keiner Weise relevant. Die Fahrbahnflächen in der Straßenraumkarte sind derzeit das einzige Feature, was nicht direkt aus OSM bezogen wird - sie sind ein “handkuratiertes” Konglomerat aus ALKIS- und OSM-Daten (barrier=kerb). Mittelfristig ließe sich das über area:highway vereinfachen, aber das steht gerade nicht auf der Agenda. Die Fahrbahn- und Radwegmarkierungen werden aus Linienfeatures gerendert - ein Radweg mit einer gewissen Breite sieht dann eben aus als wäre er eine Fläche (und man könnte geometrisch bei Bedarf auch eine daraus erzeugen).

Ich bin ganz bei dir und würde langfristig gern genau so verfahren - aber wie gesagt, so hat es sich in der Berliner Community seit Jahren eingebürgert, eine klare Regel/Empfehlung haben wir in OSM zu diesem Thema nicht und erfahrungsgemäß hat diese Variane viele Vorteile beim Mappen im öffentlichen Raum, da dieser “kerb”-Ersatz den Raum gut strukturiert und Orientierung bietet… (off topic…)

Da es zuvor hier im Thread Thema war, zum Abschluss noch ein Auszug aus einer Fahrradkarte, die ich neulich für Neukölln gebastelt habe (sie wird mittelfristig Teil der “Kartensammlung” der Straßenraumkarte) und in der auch separat gemappte Radwege keine Kopfschmerzen bereiten (in dem “separate” einfach wie “track” behandelt wird und “sidepath”-Radwege im Rendering auf dieser Zoomstufe ausgelassen werden).

[zum Thema Kanten der landuse=residential]

Kerbersatz ist ein gutes Stichwort, es ist unbestritten dass die jetzt gezeichnete Kante interessant ist, nur halt nicht als residential landuse (freue mich, dass wir uns da einig sind), im Prinzip müsste man “nur” das Tagging der ways ändern in barrier=kerb und neue landuse Polygone um die Blocks zeichnen (ist zwar ein bisschen Arbeit, aber nicht sooo viel, jedenfalls viel weniger als die Gehwegaußenkanten). Zwischen den beiden Kanten ergibt sich dadurch der Gehweg (sofern es nicht noch Vorgärten oder ähnliches gibt, z.B. hier in Tegel ist es geschlossene Bauweise, aber mit Vorgärten: https://www.openstreetmap.org/way/47149497 ).