Closed synchronisator closed 1 year ago
tordans
commented
1 year ago Hey @synchronisator sorry für die späte Reaktion und Danke für den Reminder. @gislars arbeitet gerade an einem Update für das Docker Setup, dann auch neue Gebiete erlaubt. Deines ist schon mit konfiguriert und wird dann verfügbar werden.
synchronisator
commented
1 year ago Super, vielen Dank.
tordans
commented
1 year ago Hallo @synchronisator jetzt sind wir (fast) soweit den Parkraum in Hannover darzustellen. Unten ein Update… Aber vorab schonmal das Fazit: Es kann losgehen! Wir würden uns freuen, wenn ihr Hannover mit Parkraumdaten ausstattet und Feedback zum System gebt.
https://parkraum.osm-verkehrswende.org/regions/hannover/ ist die "Projektseite" für dein Gebiet mit Zahlen und – in den nächsten Woche – den Links für den Export der Daten
Dort ist auch die Karte verlinkt, wo du die prozessierten Daten sehen kann
Allerdings wirst du sehen, dass Hannover noch leer ist bzw. wenn du auf "Stil: Vollständigkeit"(i~parkingPoints~a~_F~s~!(i~default~a))(i~parkingAreas~as~!(i~default~a)(i~position-separate~a~_F))(i~parkingDebug~a~_F~s~!(i~default~a))(i~parkingStats~a~_F~s~!(i~default~afilters~!(i~admin_level~o~!(i~4~a~_F)(i~9~a)(i~10~a~_F)))(i~length~a~_F~filters~!(i~admin_level~o~!(i~4~a~_F)(i~9~a)(i~10~a~_F))))(i~landuse~a~_F~s~!(i~default~a))(i~mapillaryCoverage~a~_F~s~!(i~default~a)))~) wechselst, dass keine Daten erkannt werden.
Es sieht so aus, dass ihr in Hannover noch vom alten auf das neue Schema wechseln müsst. Dazu hat Alex einen Blogpost geschrieben https://www.openstreetmap.org/user/Supaplex030/diary/401053, wo er auch unser Tool zum Update der Tags erwähnt.
Wenn ihr StreetComplete verwendet, würde das ebenfalls die Tags updaten.
Und der Zlant-Editor schreibt jetzt auch das neue Schema (und versteht auch das alte, stellt also die alten Daten auch dar).
Sobald Daten im neuen Schema auftauchen, kannst du die neue Ansicht "Parkraum Debug" in der Karte verwenden. Sie zeigt dann, wie die Prozessierung Elemente "ausstanzt"/"subtrahiert", die nicht mit gezählt werden.
Übrigens, auch neu sind die beiden Artikel Mitmachen https://parkraum.osm-verkehrswende.org/participate/ und FAQ https://parkraum.osm-verkehrswende.org/faq/ auf unserer Seite.
synchronisator
commented
1 year ago Hallo, ich bin dabei die Tags in Hannover zu updaten.
Dabei ist mir aufgefallen, dass bei einigen Flächen das Tag:
orientation = perpendicular parking = street_side
statt
parking:orientation = perpendicular parking = street_side
verwendet wird. Wie es scheint wird das dann nicht korrekt dargestellt.
Das sollte vllt auch berichtigt werden.
synchronisator
commented
1 year ago Und vllt noch eine Frage auch wenn sie hier nicht so richtig zum Topic gehört. Wie habt ihr das mappen von Einfahrten und Vorwölbungen bei Seitenparkstreifen gemacht? Das generelle Mappen wo wie geparkt werden darf geht ja mit StreetComplete gut. Aber das MicroMapping all dieser Einfahrten, Bordsteinabsenkungen etc. geht da eher weniger gut. Habt ihr da einen guten Vorschlag? Vllt Papierausdruck auf dem man unterwegs markiert und dann am PC übertragen? Danke
tordans
commented
1 year ago … orientation = perpendicular parking = street_side …
Verschoben in https://github.com/osmberlin/osm-parking-processing/issues/68. Gerne getrennte Themen in getrennte Issues. Danke fürs finden des Bugs!
tordans
commented
1 year ago Aber das MicroMapping all dieser Einfahrten, Bordsteinabsenkungen etc. geht da eher weniger gut. Habt ihr da einen guten Vorschlag?
Ich laufe mit GoMap!! rum und mappe die Einfahrten direkt vor Ort.
Man kann sich auch Geo Notes in Apps setzen und die dann als Layer in iD oder JOSM eintragen. Da gibts Workflows je nach System/Software, aber nichts super einfaches.
In Berlin haben wir außerdem guten städtische Daten, die man als Basis nutzen kann. Die haben wir auch in eine MapRoulette Challenge gepackt; aber das ist nicht so schön zu handeln.
Am einfachsten "fürs Sofa" ist IMO, vorher eine Befahrung mit GoPro Max zu machen und dann die 360° Bilder zu nutzen für das Mappen zu Hause. Damit kann man gut die Einfahrten erkennen. Eine GoPro haben wir zum Ausleihen https://wiki.openstreetmap.org/wiki/Berlin/Kameraverleih bei Bedarf (sie aber erst anderswo frei werden; müsste ich fragen).
Hoffe das hilft :-).
synchronisator
commented
1 year ago Ok, vielen Dank für die Infos. Ich war mir nicht sicher "wo" der Fehler lag. Deshalb hab ich da kein gesondertes Issue draus gemacht, aber mach ich nächstes mal :)
Aber ich stell hier trotzdem nochmal ein paar Fragen weil ich nicht weiß wo ich das sonst stellen soll. Oder gibt es ein Forum/Irc/Discord/o.ä.?
Wie mappt man am besten die "Vorwölbingen" bei Parkbuchten? Es ist dabei ja auch noch erlaubt vor der Vorwölbung parallel zu parken, wenn die Straßenbreite das zulässt. Insofern müsste man die Straße entsprechend unterbrechen und die abschnitte einzeln taggen. Oder gibt es da eine einfachere Variante?
Zur Straßenbreite noch eine Frage. Wenn kein Schild an der Straße steht, dann ist ja generell parken auf beiden Seiten, parallel erlaubt. Wenn die Straßenbreite aber zu gering ist, dann einigen sich die Anwohner ja meist auf eine Seite ohne, dass es angegeben ist. Mappt man dann:
Gibt es dazu vielleicht eine art Cheatsheet/Übersicht wie man mit den verschiedenen Situationen umgehen soll? Sonst würde ich vllt anfangen sowas zusammenzustellen.
Vielen Dank!
SupaplexOSM
commented
1 year ago Wie mappt man am besten die "Vorwölbingen" bei Parkbuchten? Es ist dabei ja auch noch erlaubt vor der Vorwölbung parallel zu parken, wenn die Straßenbreite das zulässt. Insofern müsste man die Straße entsprechend unterbrechen und die abschnitte einzeln taggen. Oder gibt es da eine einfachere Variante?
Solche Fälle sind ein bisschen komplizierter zu erfassen, aber nicht unmöglich. Eine ständige Aufteilung der Straßenlinie ist nicht nötig.
Für die Genauigkeit des Ergebnisses ist es generell vorteilhaft, Parkbuchten als separate Geometrie zu erfassen, wenn diese regelmäßig durch solche Verwölbungen unterbrochen sind (im Wiki gibt es ein paar allgemeine Hinweise zum Mappen separater Geometrien dazu bzw. eine Seite auch speziell für Parkbuchten).
In dem von dir beschrieben Fall gelten dabei gewissermaßen zwei Parkregeln gleichzeitig: Einmal für die Parkbuchten (deren Attribute – z.B. orientation – du dann an der separaten Geometrie angibst), und einmal für die Fahrbahn. Es ist ok, der gesamten Fahrbahn z.B. "Parallelparken auf der Fahrbahn" zuzuordnen, denn die Parkbuchten "überschreiben" diese Regel an den Stellen, an denen sie existieren. Wenn es dann kein explizites parking:*=separate gibt, ist das nicht so schlimm.
Wenn die Straßenbreite aber zu gering ist, dann einigen sich die Anwohner ja meist auf eine Seite ohne, dass es angegeben ist.
Dazu gibt es verschiedene "Philosophien", aber am praktischsten (und wahrscheinlich auch am verbreitetsten) ist es, die tatsächliche "traditionelle" Situation zu mappen. Denn häufig ist die "Einigung" der Anwohner ein ziemlich konstantes Ergebnis, was sich im Laufe der Jahre kaum ändert – zumindest sind das die Erfahungen, die ich hier in Berlin gemacht habe, wo wir auf jährliche Luftbilder aus dem letzten Jahrzehnt zurückgreifen können, auf denen man das gut sieht.
Also: Wenn alle quasi immer auf der einen Seite stehen und niemand auf der anderen, dann kann man das auch so mappen (z.B. parking:right=lane/parking:right:orientation=parallel + parking:left=no). Wenn mal hier, mal dort geparkt wird, wäre dann parking:both:staggered=yes die richtige Wahl (im Zweifelsfall kann man ja schauen, ob die vorgefundene Situation der gleichen wie auf einem Luftbild entspricht, dann hat man zumindest einen Anhaltspunkt, ob es da zeitliche Veränderungen gibt).
Gibt es dazu vielleicht eine art Cheatsheet/Übersicht wie man mit den verschiedenen Situationen umgehen soll? Sonst würde ich vllt anfangen sowas zusammenzustellen.
Bisher gibt es vor allem die allgemeine Wikiseite, die noch relativ jung ist und daher einige Aspekte noch eher vernachlässigt. Teils wurde sie für den "Community-Diskussionsprozess" auch noch bewusst etwas vage gehalten, da insbesondere solche Fragen, wie du sie hier aufgeworfen hast, bis vor kurzem noch relativ wenig ausdiskutiert waren. Das ändert sich zum Glück zur Zeit, sodass wir nach und nach konkretere Empfehlungen für Situationen wie diese hier formulieren können.
Wenn du so ein Cheat Sheet aufstellen willst, wäre das eigentlich ganz großartig, dann könnten wir das z.B. mit in die Wikiseite einfließen lassen!
P.S. Seit kurzem haben wir auch auf der Parkraum-Projektseite einige Hinweise ergänzt, wie man die "Basisdaten", die man z.B. mit StreetComplete gut erheben kann, mit anderen OSM-Editoren verbessern kann, um die Genaugkeit der Ergebnisse zu erhöhen. Schau da gern mal rein und wir freuen uns immer über Feedback und Fragen wie deine, um zu sehen, ob diese Hinweise/Beschreibungen/Anleitungen wirklich hilfreich sind und zu erkennen, welche Fragen offen bleiben.
synchronisator
commented
1 year ago @SupaplexOSM Danke für die Antwort. Die Variante mit "Strasse mit parallelem Parken" plus seperate Erfassung find ich super. Damit kommt man glaube ich recht kompfortabel hin.
Zu der "Philosophie" muss ich aber leider noch ein bisschen nachhaken 😄
Wir sollten doch generell die rechtlich richtige Variante erfassen, denn sonst können die Daten nur schwer für Planungszwecke benutzt werden. Wenn ich eine Seite als "no" erfasse, dann würde eine Planung auf den Daten davon ausgehen, dass man nur auf einer Seite Einschränkungen treffen müsste für z.B. Lieferzonen o.ä. Dann könnten die Anwohner aber auf die andere Seite ausweichen, was aus den Daten nicht hervorginge. Das finde ich nicht so erstrebenswert.
Auf der anderen Seite haben wir hier Strassen in denen "sehr stabil" auf beiden Seiten halb auf dem Gehweg geparkt wird.
Ist aber nicht erlaubt. Es dürfte nur auf einer Seite bzw. wecheselseitig auf der Strasse geparkt werden, da die Strasse zu schmal ist.
Hier muss also was anderes erfasst werden als die gelebte Realität.
Insofern müsste man wenn man parking:left=no nimmt auch noch ein parking:left:reason=narrow anhängen, (was es in StreetComplete leider aktuell nicht gibt)
Oder man müsste beide Seiten als zulässig erfassen und die Straßenbreite müsste in der Ermittlung der Parkplatzzahlen berücksichtigt werden.
Ob die Straßenbreite aktuell einbezogen wird weiß ich nicht, wäre aber glaube ich der beste Weg. Dann wäre der Workflow beim Erfassen mit StreetComplete immer:
Wenn man z.B. statt baulich getrennter Parkstreifen nur "aufgemalte Parkstreifen" hat, dann hat die breite die ich Messe einfluss darauf ob ich es als "auf der Strasse" oder "neben der Strasse" klassifiziere.
Theoretisch könnte man das vermessen auch per JOSM machen... hab aber noch nicht geprüft, ob das genau genug ist über die Luftbilder...
SupaplexOSM
commented
1 year ago Wir haben uns in unserem Algorithmus dagegen entschieden, Aussagen aus Straßenbreiten abzuleiten, da die Straßenbreiten – wenn sie denn erfasst sind – erfahrungsgemäß zu schlecht und unzuverlässig sind. Nicht alle gehen dabei so sorgfältig und systematisch vor wie du und häufig werden auch falsche Breiten erfasst (z.B. exklusive parkender Fahrzeuge auf der Fahrbahn).
Eine mögliche Lösung für dein Problem hast du aber im Prinzip bereits genannt: Wenn kein Parkstreifen vorhanden ist, kann man stets angeben, warum er nicht vorhanden ist und aus parking:<side>:reason=narrow in Kombination mit einem Parkstreifen auf der anderen Seite würde sich dann die Aussage ergeben, dass Parken auf dieser Seite möglich wäre, wenn auf der anderen nicht geparkt werden würde. Ja, StreetComplete kann das (noch) nicht, aber soweit ich weiß, ist zumindest langfristig eine Erweiterung geplant, um Parkbeschränkungen angeben zu können.
Um Daten in einer Genauigkeit zu erheben, die sich tatsächlich für solche Planungszwecke eignen, müsste man mMn aber ohnehin ab einem bestimmten Punkt auf andere Editoren als StreetComplete umsteigen. StreetComplete ist perfekt für die "Basisdatenerhebung", also um alle Straßen mit den grundlegendsten Attributen auszustatten, auch wenn sie gelegentlich noch ungenau bleiben. Wenn es dann um die Details geht (z.B. Einfahrten mappen, Parkbuchtgeometrien erfassen, Parkstreifendetails differenzieren), kommt man aber nur mit "vollwertigen" Editoren zu einer Datenqualität, die die Realität wirklich getreu abbilden kann.
Was das Thema des ordnungswidrigen, aber "gewohnheitsrechtlichen" Parkens angeht: Das ist bisher noch eine weitgehend ungelöste Frage, wie man das erfasst. Im Gegensatz zu Städten wie Bremen (und offenbar Hannover?) gibt es in Berlin kein systematisches illegales Gehwegparken, das durch Ordnungsbehörden geduldet wird, daher haben wir uns damit bisher nicht befasst. Höchstens Falschparken z.B. in verkehrsberuhigten Bereichen, was aber vielerorts geahndet wird, wenn denn mal ein Ordnungsamt vorbeikommt. Sowie Graubereiche auf unbefestigten Seiten- und Mittelstreifen, die wir mit informal=yes erkennbar machen. Darüber hinaus scheint weitgehend Konsens zu sein, illegales Gehwegparken nicht auf die gewohnte Art und Weise zu erfassen (siehe z.B. dieser Thread im OSM-Communityforum) – für meinen Geschmack fehlt dann aber eine Variante, dieses Parken abzubilden, z.B. mit einem Prefix (spontaner Vorschlag: irregular:parking:left=lane etc.).
synchronisator
commented
1 year ago ok, verstehe ich. Aber dann würde ich das trotzdem als Teil meines Vorgehens so machen.
Deckt das soweit alles ab?
SupaplexOSM
commented
1 year ago Das klingt gut. Was die Straßenbreite betrifft, gehe ich quasi genauso vor, allerdings haben wir in Berlin das Glück, Open Data ALKIS-Daten (mit Bordsteinkanten) nutzen zu können, aus denen sich mit JOSM recht präzise die Fahrbahnbreite abmessen lässt oder im Zweifelsfall/bei veralteten Daten geht das auch gut aus Luftbildern – je nach dem, ob man mit den Schatten Glück hat und die Fahrbahnränder ausmachen kann.
tordans
commented
1 year ago tordans
commented
1 year ago @synchronisator bei der Prozessierung ist uns aufgefallen, dass es noch highway=road ein paar Mal bei euch gibt. Vielleicht kannst du das mal umtaggen bei Gelegenheit. Mehr unter https://maproulette.org/browse/challenges/39479
Hallo, wir hatten neulich auf Twitter Kontakt. Ich würde gerne etwas beitragen und in Hannover mein Stadtgebiet verbessern. Aber ich bin alleine, ohne größere Gruppe und würde nur bei Spaziergängen u.ä. mappen können. Deshalb bitte nicht zu viel Aufwand treiben für mich. Wenn es unverhältnismäßig ist, bitte auch einfach sagen.
Es ginge entweder erstmal ganz klein um meinen Wohnblock oder meinen Stadtteil. Wohnblock: OSM-id: 31961153 Stadtteil: OSM-id: 3357529 Danke