Hi, bin mir keiner Schandtat bewusst. :-( Sieht auf jeden Fall gut aus, was du korrigiert hast. :)

Dito. :-)

Ja, genau. Sorry, wenn du das schon erwähnt hattest.

Ich hab die Motivation die Position der Bürgersteigkante nicht zu abstrahieren sondern möglichst genau nach dem Luftbild festzulegen (trotz aller systembedingten Ungenauigkeiten) schon verstanden. Mir geht es wie beschrieben nur darum, das die Position des kurb-Objektes am Schnittpunkt (Knoten) zwischen Bürgersteigende (Kante) und Querungsbeginn platziert wird und nicht auf der Querungslinie.
Da so zwischen der Mittelpositionierung der Bürgersteiglinie und der Bürgersteigkante eine Distanz entsteht, sollte diese, wie im WiKi-Bild gezeigt, mit einer zusätzlichen kleinen Bürgersteiglinie überbrückt werden. Das ist alles.

PS: Sollte mal jemand im Wiki ergänzen. :)

Ja, das Bild meine ich. Es sind drei Ecken zu sehen, die mit Querungen verbunden sind. Während die oberen rechten Ecken zwischen uns glaube ich unstrittig sind. Ist es die linke untere Ecke, auf die ich mich beziehe. Hier ist zu sehen das der rote Punkt, der die Bürgersteigkante (kurb) repräsentiert auf einem Knoten zwischen Bürgersteinline und Querungslinie platziert ist und nicht auf einer Querungsline. D.h. wenn du es genauso gemacht hast wie im Bild müsstest du die Distanz zwischen der Position deines kurb-Punktes und der Bürgersteigmittellinie von „Querung“ auf „Bürgersteig“ umkategorisieren.

Hallo Zusammen,
im Wiki-Artikel zum Thema findet sich unter „Beispiele“ eine bildliche Darstellung einer Kreuzung mit Übergängen, die meine Position, aus meiner Sicht, stützt. Hier sind die „kerbs“ nicht auf der Querungslinie positioniert, sondern am Knoten zwischen einer zusätzlichen Bürgersteiglinie und dem Beginn der Querung. Wenn also die „Mittellage“ auf dem Bürgersteig vermieden werden sollte, wie auch die Lage auf der Querungsstrecke, scheint mir die zusätzliche Bürgersteigstrecke von der „Mittellage“ zur Bürgersteigkante die einzige Lösung (wie im Bild angezeigt aber leider nur unzureichend beschrieben). Habe auch schon Mapper entdeckt, die das genau so machen.

Stimme dir mit dem Flächenthema in der deiner Beschreibung zu. Bin davon auch überhaupt kein Fan.
Im OSM-Wiki zum Thema steht: "Idealerweise sitzen separate Punkte mit barrier=kerb an der tatsächlichen Position des Bordsteines auf den Wegen zur Querung." Also ja, wie du beschrieben hast und gleichzeitig auch nein, denn nicht „auf der Querung“ sondern „auf den Wegen zur Querung", was aus meiner Sicht die Knoten zum Bürgersteig sind. Wenn das nicht deine Sicht ist, müsste statt des Knotens eine kleine Strecke/Linie den Bürgersteig-Knoten mit dem Querungs-Knoten-Verbinden (Kategorie: neutral Fußweg) und auf dieser Strecke kann dann die (vermeintlich) „tatsächliche Position“ des „kerb“ abgelegt werden. Der Anspruch die „tatsächliche Position“ z.B. für sehbeeinträchtige Personen in der Karte festzuhalten ist sicher lobenswert aber, wie du weißt mit dem Luftbild nur sehr unzureichend möglich, wenn keine korrigierten GPS-Daten zur Verfügung stehen. Im schlechtesten Fall sind die Abweichungen im Meterbereich. Nicht hilfreich, wenn ein Fußgänger danach navigieren will.

PS: Wenn ich von „Karte“ spreche, spreche ich nicht von der Editor-Version in OSM sondern – wie du – von den X-Karten-Versionen, die aus den Daten entstehen.

"Wie es auf der Karte aussieht, ist völlig egal". Ich dachte wir arbeiten gemeinsam an einer Abstraktion der Wirklichkeit in Form einer Karte. Mir scheint es in keiner Weise "egal" (zumal, wenn die Daten Grundlage vielen Kartenapps, Navigationsapps und anderer Anwendungen sind).
Warum bei dir mal die Abstraktion gilt (siehe deine Ausführungen) und mal die genaue (nicht abstrahierte) Lage im Luftbild ist mir unverständlich, weil widersrpüchlich. Würde mich freuen, wenn du mich auf OSM-Regeln verweisen könntest, die diese Vorgehensweise beschreiben.

Das musst du bitte erklären. Das macht für mich überhaupt keinen Sinn. Entweder markiert der Berührungspunkt zwischen Bürgersteig und Querung die Position der Bürgersteinkante oder die Position im Luftbild, was dann aber in der Konsequenz eine notwendige Verschiebung der Bürgersteiglinie zur Kantenposition im Luftbild zur Folge hätte (eine Abweichung von der klassischen Mitte-Positionierung). So wie jetzt platziert liegen die Objekte in der Kartenanzeige (nicht im Luftbild) mitten auf dem Übergang, also auf der Straße und nicht an der Schnittstelle zwischen Straße und Bürgersteig.

Die Objekte "Abgesenkter Bordstein" waren auf den Linien der "Gehweg-Querung" platziert statt unmittelbar an den Berührungspunkten zwischen Bürgersteig und Querung. Habe dies korrigiert.

PS: Tippen auf dem Handy mit Autokorrektur ist nicht mein Fall: 2x „keinen“ statt „keiner“ :)

Der Bogen macht in der Tat keiner Sinn, ist korrigiert. Allerdings machen die Positionen der ergänzten Gehwegabsenkungen auch keiner Sinn. Innerhalb eines Straßenübergangs platziert würde bedeuten, das die Absenkungen auf der Straße wären. Definitorisch deutet ja der Beginn der Übergangs auf das Ende des Bürgersteigs hin. Ergo müssten die Absenkungen an dieser Schnittstelle platziert werden und nicht an der Position, die das Luftbild anzeigt. Hab ich korrigiert. :)

Hallo Negreheb, stimme dir zu, die Erfassung ist zur Zeit ambivalent. Ich sehe nur viele Kartenapps, die die an Straßen-getaggten Sidewalk-Angaben nicht nutzen, während alle die separat erfassten abbilden. Ergo bin ich für eine separate Erfassung, die zu dem den Geh- oder Radwegverlauf um Verkehrsinseln, Parkplätze, Grünstreifen, etc. viel genauer abbildet als das Tagging. Bzgl. „ortsfremd“: War in letzter Zeit mehrfach in Salzburg unterwegs und habe dabei auch meine Wege durch die Stadt getrackt. Dabei ist mir aufgefallen, wie oft ich über unkartiertem Gelände war. Deshalb jetzt mein Fokus auf Salzburg.
Danke für die Korrektur meiner Flüchtigkeitsfehler und danke für den Hinweis auf die 360-Grat-Fotos, nutze in schon bei Unklarheiten im Luftbild.

Servus, ich denke es besteht Konsens bzw. der Ergänzung von Bürgersteigen, Fußwegen, Hauszugängen, Fuß- und Radwegen um die Navigation für nicht Autofahrer zu verfeinern und eine detaillierte Punkt-zu-Punkt-Navigation zu erlauben (ergo die separaten Gehsteige). Danke für den Hinweis zum Plugin war mir nicht bekannt. Schau ich mir mal an.

Habe die Strassenparameter nicht definiert, sollte mit dem Autor geklärt werden. Für mich sieht dieser Abschnitt sehr nach einem Fußgänger dominierten Bereich aus. Gepflastert von Haustür zu Haustür, Mülltonnen auf dem Pflaster, keine Andeutung einer Fahrbahn.

Auf dem kurzen gepflasterten Strassenabschnitt, ohne Bürgersteige gibt es nur ein Verkehrszeichen: ein absolutes Halteverbot mit Zusatz „für den gesamten Verkehr“ sonst nichts.

Danke für den Link. Ist sehr aufschlussreich. Der für mich wichtigste Punkt in der sogenannten Methode A (Tagging der Straße) ist, das Renderer aktuell den Parameter nicht zur Darstellung von Bürgersteigen verwenden. Solange das nicht gewährleistet ist scheint mir die separate Erfassung, mit allen genannten Nachteilen sinnvoller. Diese Sicht scheint mir auch von vielen Mappern geteilt zu werden, wenn ich die Vielzahl separater Erfassungen sehe. Ich werde in jedem Fall deinen Hinweis beachten und zukünftig auch das Straßentag anpassen. Danke noch mal für deine Anmerkungen.

Hallo Reinhard, du wirfst ein für mich als OSM-Novitze neues Thema auf. Welche Funktion haben diese Sidewalk-Tags? Sie führen sicher nicht zur Anzeige von Bürgersteigen im Kartenbild und damit zur Möglichkeit diese Wege in die Navigation einzubinden. Ist für Fußgänger und Radfahrer aber relevant. Ich folge in meinen Ergänzungen nur den Vorarbeiten anderer, die vorhandene Bürgersteige und Straßenübergänge als separate Weglinien erfasst haben. Selbst wenn ich diese Anpassung bei den Straßenparametern immer vornehmen wollte könnte ich dies nur bedingt, da ich bei Stichproben kaum eine Straße gefunden habe bei der diese Parameter (Tags) gepflegt sind. So etwas auf Datenbankebene zu korrigieren ist sicher leichter und wirksamer als zu versuchen dies Element für Element nachzupflegen.

Nachtrag: Kann es sein, das bei Auswahl „Ohne Fahrbahnmarkierung und Ampel“ das crossing:markings nicht automatisch von „yes“ auf „no“ gesetzt wird? Irritierend, wenn alle anderen Parameter der deutschen Auswahl angepasst werden. Dann mach ich hier einen systematischen Fehler, da ich bisher noch nie überprüft habe ob, die deutsche Parametereinstellung von der englischen abweicht. Kann mir vorstellen das ich nicht der einzige OSM-Novize bin dem das passiert. Warum wird der Parameter nicht, wie die anderen, automatisch angepasst? Würde doch Sinn machen oder?

Hallo Mottiger, danke für den Hinweis. Wie viele von diesen falsch kategorisierten Übergängen hast du gefunden. Würde gern wissen ob ich hier einen systematischen Fehler mache oder ob das nur punktuelle Flüchtigkeitsfehler sind. Hast du die Fehler schon korrigiert?