You are not logged in.

#101 2022-01-10 10:48:03

dieterdreist
Member
From: Roma, Italia
Registered: 2010-09-22
Posts: 3,626
Website

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

SafetyIng wrote:

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....

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.

Offline

#102 2022-01-10 23:33:10

Supaplex030
Member
Registered: 2016-09-12
Posts: 25

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

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...

Hungerburg wrote:

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 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.

Hungerburg wrote:

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?

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).

SafetyIng wrote:

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.

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).

dieterdreist wrote:

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.

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).
Fahrradkarte_Neuk%C3%B6lln_beta.png

Offline

#103 2022-01-11 09:31:23

dieterdreist
Member
From: Roma, Italia
Registered: 2010-09-22
Posts: 3,626
Website

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

[zum Thema Kanten der landuse=residential]

Supaplex030 wrote:

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...)

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 ).

Offline

Board footer

Powered by FluxBB