Parkplatz-Micromapping

sehe ich auch so… Wir mappen nicht für den Renderer

Da muss Carto nachbessern für die Zoomstufe 17-18 und bei kleinen Flächen kein “P” rendern…

1 Like

Es ist insgesamt fragwürdig, parking=lane getrennt zu erfassen, weil es ein inhärenter Teil der Fahrbahn ist und eben nicht getrennt. Deswegen macht ein Getrennterfassen wirklich wenig Sinn. Bei Street-Side ist das teilweise ähnlich, nur sind diese meist durch abgesenkte Bordsteine getrennt und zählen deswegen auch nicht zur Fahrbahn.
Aber bevor wir jetzt weiter eskalieren, sollten wir akzeptieren, dass hier 2 gegensätzliche Meinungen aufeinandertreffen. Das optische Problem liegt in der Hand der Renderer, auswertungstechnisch hingegen sind Parkplätze, die nicht mit dem highway=* verbunden sind für die meisten Router wohl ein immenser Aufwand. Das trifft allerdings auf parking=street_side genauso zu, wie auf parking=lane. Was ich damit meine ist: ein Router wird Probleme haben, einem beim Fahren darstellen zu können, ob man rechts am Fahrbahnrand (oder rechts davon) parken darf. Theoretisch geht es zwar mit viel Aufwand, aber es besteht keine Direkte Beziehung/Verbindung von Fahrbahn zur Fläche.

1 Like

Dieser Theoretischer Vorteil für einen Router…ist ja ein bischen an den Haaren herbeigezogen… Würde man das 1 zu 1 auf Hausnummern umschreiben… müsste wir Hausnummern auch auf die Straße taggen…

Außerdem wird schon zu viel auf der Straße getaggt… und schon viel zu oft zerteilt. Das ich “Datentechnisch” und QS-technisch eher schlecht finde… weil sich da viele Fehler einschleichen…

Gruß Miche

3 Likes

Es geht mir nicht darum, dass der Router nicht dorthin routen kann – das kann er. Aber quasi “on-the-fly” wissen, welche Parkfläche zur aktuell befahrenen Straße gehört, das ist schwieriger.

ok ja…aber braucht man das? Da müsste man vielleicht vorarbeiten… wenn man das möchte…

Für mich wäre wichtig wie hoch mein Chance ist das ich auch wirklich da parken kann :laughing: … In Städten mit den ganzen Parksystemen -ausweisen usw. noch schwieriger… bis unmöglich

Die Chance, einen Parkplatz zu bekommen, ist leider nicht proportional zu deren Anzahl :laughing:

Was das Auftrennen von Straßen angeht, gebe ich Dir allerdings recht. Leider gibt es momentan keine sinnvolle Möglichkeit, das zu vermeiden, wenn sich die Eigenschaft einer Straße ändert. Und für mich ist Parken ja/nein eine Eigenschaft der Fahrbahn, genau wie Maximalgeschwindigkeit, die Oberfläche und Dinge wie „wird hier Schnee geräumt“. All das kann sinnvoll auch bei der Parkplatzauswertung berücksichtigt werden, müsste dann aber bei separaten Parkplätzen auch extra dort erfasst werden.
Allerdings sollte man separat erfasste Parkplätze an der Straße selbst mit parking:<side>=separate hinzufügen, sonst weiß mal wieder keiner, ob’s vergessen, oder separat erfasst wurde. Spart also in diesem Fall auch nicht das Auftrennen.

Wäre die Fahrbahn wiederum als Fläche erfasst, hätte man das Problem der Attribute beim Lane-Parking nicht mehr, weil sie von dem „Parent-Weg“ (der Fahrbahn) geerbt werden könnten, weil ja eine wirkliche Relation besteht. Aber das ist vermutlich abseits von Neukölln indiskutabel…

1 Like

Bevor das jetzt ausufert:

  • Bitte keine Grundsatzdiskussion über das Aufteilen von Straßen-Ways.
  • Bitte keine “Mappen für den Router/Renderer”-Pauschalverurteilungen.

Es geht mir nicht darum, dass einfach nur weniger blaue Ps in der Karte stehen, sondern es geht mir darum, dass ich einen qualitativen Unterschied sehe zwischen a) einer ausgewiesenen Parkfläche für mehrere bis viele Fahrzeuge und b) einer legalen Abstellmöglichkeit am Straßenrand. Und es sinnvoll fände, diesen Unterschied im Datenbestand zu berücksichtigen, damit Renderer und Router die Möglichkeit haben, das auch unterschiedlich auszuwerten.

Anders ausgedrückt, ich finde es nicht hilfreich, wenn mir Osmand auf meine Anfrage nach dem nächsten Parkplatz sagt “der nächste ist 10 Meter vor dir, der übernächste 15 Meter und der überübernächste 20 Meter”. Ich fände es hilfreich, wenn er mich gleich zu einer baulichen Anlage zum Abstellen von Fahrzeugen führt und Parklücken am Straßenrand außen vor lässt. Die kann ich unterwegs immer noch nehmen, wenn ich eine finde und mir danach ist, aber das sind für mich keine sinnvollen Navigationsziele.

Aber das ist unabhängig davon, ob separat erfasst, oder nicht, bereits mit parking=* gegeben. Dass die Router das nicht auswerten, ist ein ganz anderes Problem. Aber tun sie das wirklich nicht, oder glaubst Du das nur, weil’s auf der Karte separat gerendert wird? Auch zum Rendern wäre genug Information vorhanden, um z.B. parking=lane oder parking=street_side einach auszublenden. Ich dachte, es ging hier um die Frage, ob es so, wie es erfasst ist, falsch ist. Und das ist es nicht.

2 Likes

Wenns genutzt wird, ja. Die allermeisten Straßenrand-Ps in der Karte sind amenity=parking getaggt, ohne weitere Information.

1 Like

Ein Router könnte zudem auch die Fläche ausrechnen und das mit in die Entscheidung einbeziehen. Aber auch da ist es natürlich nur möglich, wenn’s der Router auch macht.

Ich denke, eine Lösung hier wäre, wenn man parking=… ergänzen würde. Mit dem Satelitenbild kann man das sicherlich bei etlichen entscheiden. Den Rest müsste man aber vor Ort mappen.

3 Likes

Eben. Und das ist der richtige Ansatzpunkt hier. Der erfassten Flächen müssen durch parking=* weiter spezifiziert werden.

2 Likes

es gibt allerdings auch Parkplätze die sich nicht für deine Anforderung “Bauliche Anlage” qualifizieren, weil da z.B. einfach Autos auf eine Wiese oder andere Freifläche gestellt werden, die ggf. auch entsprechend beschildert ist oder wo es Einweiser gibt, die dir einen Platz zuweisen und fürs Parken kassieren, es steht also außer Frage, dass es sich um einen Parkplatz handelt, aber baulich ist dort nichts.

Ich seh schon: Die beiden, die ich geprüft hatte, waren korrekt getaggt :rofl: Na dann mal los :slight_smile:

Du bist Jurist, oder? Sorry, dass das keine wasserdichte Definition war. Es sollte aber klar sein, was ich meine.

Ich glaube, das passt ganz gut zum Thema: OSMCha. Zunächst drängte sich bei mir der Verdacht auf, dass man verhindern will, dass dort Fremde parken. Allerdings frage ich mich, ob die gemappten Flächen tatsächlich Parkplätze sind nur weil hier und da Autos stehen. Was tun?

Das optische Problem ließe sich reduzieren, wenn man die einzelnen Parkbuchten entlang eines Straßenabschnitts zu einem Parkplatz zusammenfügen würde (als Multipoligonrelation), dadurch würde das P nur einmal angezeigt.

Das habe ich auch so gesehen, als ich in dieser Innenstadt die Parkbuchten neben der Straße erfasst habe:

Begründung: Für mich sind solche Parkbuchten kein Parkplatz im egentlichen Sinne. Aber es handelt sich um PKW-Stellplätze, die zwischen Fahrbahn, Bürgersteig und Straßenbäumen angelegt wurden.

Ergänzung: In dem Wiki-Artikel https://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dparking_space
heißt es:
" Nutzung
[…]
Jeder einzelne Parkplatz sollte als einzelne Fläche eingetragen werden. Es gibt einige Ausnahmen, in denen eine Fläche für mehr als einen Parkplatz genutzt werden kann:
[…]
Parkplätze sollten in einer site relation mit type=site und site=parking zusammengefasst werden
[…]"
Dieser Textabschnitt erscheint mir nur sinnvoll, wenn man hier statt des Begriffs “Parkplatz” den Begriff “Stellplatz (parking_space)” annimmt. Denn es ist ja wohl kaum gemeint, dass mehrere (große) Parkplätze in einer solchen Relation zusammengefasst werden. Und es erscheint mir auch absolut unnötig, eine solche Relation zu verwenden, wenn es sich um das Mapping einzelnder Stellplätze innerhalb einer größeren Parkplatzfläche handelt. Für micht ist dieses Zusammenfassen nur für den Fall sinnvoll, wenn es sich (so wie von mir verwendet) um einzelne Stellplätze handelt, die eben nicht innerhalb einer größeren Parkplatzfläche liegen.

Ich hatte dich so verstanden dass nur dann ein Parkplatz getaggt werden soll, wenn etwas gebaut wurde. Ich würde es eher so sehen dass es reicht wenn die Fläche fürs Parken genutzt werden soll.

“eine ausgewiesene Parkfläche für mehrere bis viele Fahrzeuge” hatte ich im Absatz davor geschrieben. Besser? :wink:

Das Proposal zu dieser Relation sagt, dass es anstelle von amenity=parking genutzt wird, um Stellplätze, die zusammengehören, aber nicht notwendigerweise auf demselben Parkplatz sind, zu gruppieren und dazu optional noch mit Eingang und Ausgang zu versehen. So gesehen kann man es nutzen, um einzelne Stellplätze entlang der Straße zu gruppieren, auch wenn das wohl nicht die Intention war :wink:

Aber: wie viele davon gruppierst Du zu einem Parkplatz? Von Kreuzung zu Kreuzung? Den ganzen Straßennamen entlang? Davon abgesehen haben viele parking=lane und parking=street_side gar keine Markierungen. Wie will man denn da einzelne Stellplätze eintragen? Spätestens dann wird man doch eher zu parking:<side> greifen, weil viel einfacher. Und dann gibt’s ja auch noch gemischte, wo ein Stellplatz, z.B. für behinderte, eingezeichnet ist und beim Rest muss man schauen, wie viele passen.