mir ist gerade in Floridsdorf (Wien) Micromapping an Kreuzungen aufgefallen, wo ein User Straßen ein paar Meter vor Kreuzugen nochmal auftrennt um darzustellen, dass man im Kreuzungsbereich nicht parken kann.
Siehe z.B. Way: Holzmeistergasse (1264081547) | OpenStreetMap
Ich find es persönlich keine gute Idee, weil man so eine unnötig große Menge an ways schafft die Konsistenzprobleme verursachen können (a la man ändert nur zwei von drei ways zwischen zwei Kreuzungen) und eigentlich keinen Mehrwert bringen (dass man nicht mitten auf der Kreuzung parkt ist klar)
Ist sowas mittlerweile gängige Praxis? Wüsste ich gerne, bevor ich den User anschreibe
Ich weis nicht, sieht hier bei uns oft so aus, als ob das gar nicht so klar ist Nicht umsonst werden immer mehr Markierungen gemacht um anzuzeigen, dass man da nicht parken darf.
Oder direkt Fahrbanverschmälerungen (da bin ich sowieso dafür )
Aber ja, ist nicht wirklich falsch, gibt meiner Meinung nach nicht wirklich einen Grund, da etwas zu ändern. Ist einfach nur detaillierter, als es dir lieb ist
Aber jo, kann mir gut vorstellen, dass das im Kreuzungsbereich ungünstig ist, wenn man was ändert. Aber das Problem gibts sowieso, je detaillierter es wird und das wirds halt immer mehr. Drum find ichs kein Problem.
In Wiesbaden gibt es einen ähnlichen Fall, nur dass in dem Fall die Straßen wegen Bürgersteigen aufgeteilt werden, falls diese nur auf einer Straße separat eingetragen worden sind.
Ich selber sehe es schon eher kritisch wegen dem geringeren Mehrwert als andere Fälle von Micromapping und der Tatsache, dass man dadurch in Gefahr kommt, die ganzen Routen kaputt zu machen (und geschah eben auch in Wiesbaden).
tatsächlich ist das hier auch der Fall, weil du einen Teil der Straße von cycleway=opposite auf oneway:bicycle=no geändert hast, einen kleinen Teil im Kreuzungsbereich allerdings nicht. Macht in dem Fall keinen Unterschied, aber es braucht nicht viel Fantasie, dass da auch leicht kleine, unauffällige Fehler passieren können, die das Routing zerstören.
Ich finde es nicht falsch, aber auch nicht sinnvoll.
Die 5m wären der nächste Schritt, tatsächlich sind ja eigentlich nur die Bereiche mitten auf der Kreuzung ausgenommen, ohne dem vollständigen Abstand davor
Es gibt dort keine Markierungen geschweige denn Gehsteigvorziehungen. Man kann also im Prinzip wirklich parken bis zur Kreuzung. Aber selbst mit solcher Gestaltung finde ich, dass ein solches Mappen extrem geringen Mehrwert hat.
Ein anderer Fall wäre eine Straße wo im Verlauf die Parkordnung geändert wird.
Da der Detaillierungsgrad im Laufe der Zeit immer mehr zunehmen wird, erscheint mir der Ansatz die Parkplätze als separate Flächen einzutragen am nachhaltigsten zu sein - so wie es bei Gehsteigen mittlerweile schon häufig der Fall ist. Dadurch sind die Parkmöglichkeiten auf der Karte - auch von ihrer Ausdehnung her - direkt erkennbar und es ist wesentlich einfacher die entsprechenden Attribute wie Oberfläche, Parkgebühr, Parkdauer, Behindertenparkplatz, Benützungsbeschränkung, usw. zu erfassen, ohne die highways immer weiter zu fragmentieren.
Aber nicht nur die Fragmentierung, sondern auch die Anzahl der Tags am highway sehe ich als zunehmend problematisch. Mit den derzeit zur Verfügung stehenden Editoren ist es relativ schwierig bei Straßenabschnitte mit 5-10 Fragmenten und 20-30 Tags den Überblick zu wahren und mit gutem Gewissen größere Änderungen vorzunehmen - abgesehen von den möglicherweise vorhandenen Relationen, die dann dabei auch noch zu berücksichtigen sind.
Hallo, ich bin DER angesprochene mapper, bin übrigens selbst im Zwiespalt, vor allem in den Kreuzungsbereichen. Was du ansprichst ist tatsächlich das Fußgänger-Kreuzungsplateau, ich seh da jetzt keinen Unterschied ob die Regelung wg. Verkehrszeichen, Bodenmarkierung oder “virtueller” 5-Meter-Grenze besteht, die Auswirkungen sind die gleichen und jedenfalls nicht willkürlich gewählt. Die grundsätzliche Frage ist halt immer, wofür diese Daten verwendet werden, ist zB eine automatisierte Parkplatzsuche dahinter versteckt dann ist jeder “richtig” gemappte Meter ausschlaggebend.
The roadway needs to be split up where any of the properties changes, for example, when parallel parking is available only alongside the first half of a way between two intersections, split the road and tag parallel parking on the first part and no parking at the other one. For very short changes or single parking spaces with other conditions, consider mapping them separately to avoid over-fragmenting the street line. Especially in places where the parking situation is very diverse, this can actually be easier to do and easier to maintain than to split the roadway into many small segments just to accommodate for the different parameters that change down the road.
Weiter unten geht’s um Reasons for parking restrictions wo steht:
Some of the values refer to “geometric” implicit restrictions (like driveway or junction) – usually it’s not necessary to split a street line in order to map such implicit restrictions
an Kreuzungen oder wegen einer Garageneinfahrt oder wegen einem Baum nicht den way der Straße zu splitten sondern einfach z.B. die parking:right=lane zu setzen über die ganze Länge.
bei komplexeren Straßen wo die Parkordnung ständig wechselt oder nur vereinzelt Parkplätze sind diese mit eigenen Polygonen und Tag:parking=street_side - OpenStreetMap Wiki zu Mappen.
Das bietet einerseits eine hohe Detailtiefe der Parkdaten und macht andererseits die Wartung der “reglären” Straßenattribute nicht komplexer (durch eine größere Anzahl an ways).
3 Likes
Mammi71
(One feature, Six mappers and still More ways to map it)
11
Ich hoffe doch ganz stark, dass ein jeder Autofahrer seine Augen aufmacht und selbst autonomes Fahren Kreuzungsbereiche sauber erkennt und nicht mitten auf oder unmittelbar vor oder nach einer Kreuzung parken wird. Und das auch dann, wenn die OSM-Daten nicht auf den Meter genau und vollständig erfasst sein sollten.
Achtung: Nicht an jeder separat gemappten Fläche ist parking=street_side korrekt – es kann auch einfach parking=lane (gewöhnliches Fahrbahnparken) sein oder auch sowas wie parking=half_on_kerb. Die parking-Values sind die selben wie im parking:side-Tag an der Centerline.
Zum eigentlichen Thema kann ich ansonsten nur beipflichten, dass es im Allgemeinen nicht notwendig ist, Straßensegmente mit einem expliziten parking:*=no zu erzeugen, wo sich diese Information bereits implizit aus einem in OSM erfassten Feature wie einer Straßenkreuzung, einer Einfahrt, einem Gewegübergang (oder selbst einer Bushaltestelle) ergibt. Wer solche Daten mit dem Zwecke auswertet, die genaue Lage oder Stellplatzzahl von Parkplätzen zu ermitteln, wird solche Features auswerten (müssen) – einen Algorithmus dafür haben wir in Berlin bereits entwickelt.
Wer das Berliner Projekt noch nicht kennt: Mit “genauem” OSM-Parkraum-Mapping lässt sich der Parkraum nahezu exakt abbilden, wobei “genau” nicht unbedingt bedeutet, alles in kleinste Segmente teilen zu müssen, sondern vor allem auf Vollständigkeit und Genauigkeit der Informationen zu achten – z.B. Einfahrten und Gehwegüberquerungen zu erfassen oder Bereiche mit häufig wechselnden Parkanordnungen einfach separat zu erfassen. Es gibt auch eine Reihe noch nicht besonders gut dokumentierter in use-Tags mit zusätzlichen Informationen wie z.B. zu Gehwegvorstreckungen oder Hindernissen im Parkstreifenbereich.
Nicht umsonst werden immer mehr Markierungen gemacht um anzuzeigen, dass man da nicht parken darf.
)