Parkbuchten an Straßen

Immer langsam mit den Pferden.
Die Reihenfolge ist: Vorschlag - Diskussion - Abstimmung - Benutzung - Map-Features.
Da sollte man sich schon dran halten.

Die Absicht mag ja lobenswert sein, aber die Umsetzung mit bis zu vier Hierarchie-
ebenen (“parking:condition:side:time_interval=interval”) scheint mir doch etwas
übertrieben. Außerdem fehlen wichtige Informationen, als da wären:

• Parken auf der Fahrbahn,
• Parken auf der Fahrbahn in markierten Bereichen
• Parken in Parkbuchten (neben der Fahrbahn)
• Abwechselndes Parken auf der Fahrbahn (beliebt in Wohngebieten)

Ich würde für diesen doch recht komplexen Sachverhalt einen eigenen Schlüssel
(zum Beispiel Key:parking_lane) vorschlagen. Dann sind ausgewiesen Parkplätze,
wie sie bisher schon erfasst werden und Parkregelungen entlang einer Straße
sauber getrennt. Damit werden die Straßen nicht durch hunderte von Parkplatz-
Symbolen zugepflastert.

Edbert (EvanE)

Hi,

ich glaube, Kay liest dieses Forum nicht, daher ist es sicher sinnvoll, ihm diese Anmerkungen auf der Kommentarseite hinterlassen. Mich interessiert das Thema auch nicht besonders, ich wollte nur darauf hinweisen, weil er uns das bei unserem Würzburger Stammtisch vorgestellt hat.

Mit Sicherheit ist das noch nicht reif für Map-Features und bedürfte ausführlicher Diskussion. Die Erfahrung hat jedoch gezeigt, dass es durchaus auch mal sinnvoll ist, Ideen auch inoffiziell auszuprobieren, bevor man sie zur Diskussion stellt. Der formale Prozess alleine hilft ja oft nicht weiter.

Ich werd mal auf der Würzburg-Liste Bescheid geben, vielleicht gibts dann ja auch Einschätzungen von Leuten bei uns, die das mal ausprobiert haben.

Nundenn, noch viel Spaß beim Parkplatz-Mappen und viele Grüße!

Die Idee ist sche nicht schlecht, aber ich denke auch, daß man zwischen extra ausgewiesenen Flächen (also den Parkbuchten, um die es mir geht) und einer Parkerlaubnis auf der Straße unterscheiden sollte.

Hallo zusammen,

von mir (unter anderem) ist der “Würzburger” Vorschlag, der sich hauptsächlich/ursprünglich um Parken “auf der Straße” dreht. In Würzburg gibt es (wie wohl in jeder größeren Stadt) einen Wust an verschiedenen Parkmöglichkeiten.

Genau. Grundsätzlich glaube ich aber, dass es 3-4 grobe Arten von Parkmöglichkeiten gibt: parallel (inline) auf der Straße, egal ob auf der Straße, halb auf dem Bürgersteig, ganz auf dem Bürgersteig (das könnte man vielleicht noch hinzunehmen), dann diagonal, oder senkrecht (orthogonal), oder es handelt sich um einen extra Parkplatz. Im Würzburger Schema wären dies (Beispielhaft für die rechte Straßenseite):

• parking:lane:right=inline

• parking:lane:right=diagonal

• parking:lane:right=orthogonal

• amenity=parking (historisch)

Könntest du nochmal genauer erklären, worin sich die Parkbuchten von den genannten 4 unterscheiden? Gibt es z.B. “parking_aisles”?

Ich habe normalerweise einen live Mapnik-Server laufen wie die gerenderten Parkmöglicheiten aussehen, z.B. “senkrecht einparken”, aber da ich z.Zt. im Osterurlaub bin, steht der Server voraussichtlich erst Montag wieder zur Verfügung. Bitte schreibt mir, dann schicke ich euch einen Link - ich möchte ihn im Moment nicht auf einer google-indizierten Seite nennen, weil mir der Traffic sonst zu groß wird, es ist ein schwächlicher PC Aber das ändert sich bald.

l3u, wir können gerne beispielhaft zusätzlich ein paar deiner Parkbuchten nach dem Würzburger Schema taggen (stört ja nicht in OSM), und ich importiere Montag komplett Bayern (statt wie bisher nur Unterfranken), dann können wir hier alle sehen wie das gerendert aussieht, das hilft sicherlich bei der weiteren Diskussion.

Viele Grüße aus München und schöne Ostertage
Kay

Hab in Asseln heute ein paar Parkbuchten eingezeichnet.
Was haltet ihr davon diese als amenity = parking; parking = lane einzutragen?

Als Fläche eingetragen finde ich es gut. Anahnd des parking-TAG’s kann dann jeder filtern, ob er sie haben möchte, oder nicht.

Ich sträube mich weiterhin tags mit : zu vergeben. Das macht die ganze Taggerei nur komplizierter. Außerdem interessiert es mich wirklich nicht, wenn ich nach einem Parkplatz suche, ob ich dort schräg einparken kann. Es interessiert mich eher, wieviele Parkplätze zu Verfügung stehen und ob es irgendwelche Restriktionen gibt. Macht die Sache nicht komplizierter als es sein muss!

Wirklich interessant ist das Zeichnen von Parkplätzen, erst wenn man Luftbilder hat. (siehe Dortmund).

Gruß

Volker

Warum? Wie willst du Tags dann genauer vergeben? Wie z.B. maxspeed:wet?
Aber “parking:lane:right:surface:middle” fände ich schon ein bisschen krass.

Wozu brauche ich maxspeed:wet.

Dazu müsstest Du ein internes Navi mit der Wischautomatik verknüpfen, damit es automatisiert angezeigt wird. Dann müssten sich die internen Navis aber erst für OSM öffnen.

Ich bleibe dabei Tags mit Doppelpunkt verkomplizieren die ganze Sache. Es mag ja wunderbar in Editoren funktionieren. Wenn Du aber schnell mal in POTLATCH einen Tag änern willst sieht es schon anders aus.

Dan wird OSM relativ schnell ein Projekt für Spezialisten und die Breite geht verloren.

Gruß

Volker

Die Zukunft wirde aber wohl dahingehen, dass es einen vernünftigen Editor braucht, um OSM unterstützen zu können. Da wird sich Potlatch anpassen müssen oder eben es wird abgelöst.

Sei es, dass mehrere Layer im Datengerüst kommen oder einfach die Schemen komplexer werden.

Btw: Ich sehe derzeit den : als ganz normales Zeichen ohne ander Bedeutung. Ähnlich wie dem _.

Du brauchst es weil wir ∗Trommelwirbel* Mantra Nicht für’s Routing, sondern die Wirklichkeit taggen. Und da existieren nunmal Höchstgeschwindigkeiten bei Nässe. Der Doppelpunkt ist ein wichtiges Zeichen, viele Tagging-Schemata arbeiten damit und kommen damit gut klar. Wie das mit Potlatch aussieht, weiß ich nicht, aber wenn es schlecht ist, dann ist das nur ein weiterer Punkt auf der Liste der Probleme mit Potlatch.

Parken ist kompliziert. (siehe )

Bei dem Doppelpunkt habe ich mir nichts besonderes bei gedacht, ausser dass er mir syntaktisch logisch (analog Namespaces, wird so auch schon in OSM benutzt) erschien.
Mit parking_lane_left=inline sähe es vielleicht “lesbarer” aus, aber gewonnen wäre an Komplexität gar nichts.

Mir ist klar, dass meine Lösung komplizierter als trivial ist, aber sie ist ein (imho ausgewogener) Kompromiss, in dem die alltäglichen (und für die Benutzer sinnvollen) Parksituationen abgebildet werden können.

Folgendes kann man damit z.B. noch nicht abbilden:
Das Problem ist, dass es mehrere (parallel geltende) Bedingungen gibt, für die man sowas schreiben müsste:

parking:lane:left = inline
parking:condition:left:1 = ticket
parking:condition:left:1:time_interval = Mo-Sa 09:00-23:00
parking:condition:left:2 = residents

Jede Bedingung kann ja wieder zeitlich begrenzt sein, usw. Aber das halte ich im Moment für übertrieben, die Leute interessiert doch nur, wenn sie in eine Stadt fahren:

a) wo kann ich kostenlos parken, oder
b) wo kann ich überhaupt parken

Insofern würde ICH (Achtung: Meinung) den Beispielparkplatz als “ticket” erfassen und die “residents” in diesem Fall unter den Tisch fallen lassen. Verbessern kann man später immer noch.

Und JA, ich glaube, dass mit der Zeit auch Navigationssoftware existieren wird, die nach der aktuellen Uhrzeit schaut, so dass z.B. nach 19 Uhr auch die “ticket”-Parkplätze als kostenfrei nutzbar dargestellt werden. Aber das ist ja nur eine Anwendung, wichtig ist, dass es in der Datenbank richtig steht.

Übrigens: Aktuell habe ich gerade ganz Bayern auf meinem Zuhauseserver importiert (mehr verträgt er nicht), in Bälde kommt hoffentlich der ganze Planet: http://parking.openstreetmap.de

Viele Grüße,
Kay

Hi,

Kleines Update an alle: inzwischen ist durch den Merge mit einem ähnlichen Vorschlag ein offizielles Proposal entstanden:
http://wiki.openstreetmap.org/wiki/Proposed_features/parking:lane und die Diskussionsseite
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/parking:lane

Ich bitte euch alle, kräftig mitzudiskutieren, bzw. besser, es selbst mal auszuprobieren. Wenn euch eure Stadt/Gegend
fehlt, nehme ich sie gerne mit in meinen Datenbankimport auf.

Danke,
Kay

Ich lehne mich mal zurück …

Wenn ich mich an einem fremden Ort auf einer Karte umsehe und finde dort einen mit einem Parkplatzschild markierten Parkplatz, so nehme ich auch an, dort parken zu können.

Ich würde es als Nepp ansehen, wenn ich vorort feststellen müsste, dass dies nur ein Kundenparkplatz für eine Gärtnerei ist, oder eine Firmenparkplatz, auf den ich nicht drauf darf.

Was fangen eigentlich die Renderer mit dem access - Tag an?

Viele Grüße
Dieter

zumindest für access=permissive und private zeigt Mapnik kein Parkplatzschild, Osmarender zeigt bei privat keins und bei permissive ein graues Parkplatzschild an. Beide zeigen aber eine gelbe Fläche. Daher setze ich die Tags auch konsequent…zumindest wenn ich dran denke, was nicht immer so ist, wie ich bei nachschauen gerade sehe

Hallo,

ich werfe mal ein, dass mir persönlich ein kompletter Spuren-Ansatz lieber wäre als Tagging-Insellösungen nur für Parkbuchten. Ich denke da an sowas wie Wayparts http://wiki.openstreetmap.org/wiki/DE:User:%C3%96mmes/Wayparts. Man hätte halt gleich verdammt viele Fliegen mit einer Klappe erschlagen. Jetzt läßt sich deftig darüber streiten, ob das Ding mit seinen Relationen zu kompliziert wird. Das ist aber nicht meine Intention, jeder möge sein Zeug taggen, wie er es selbst für richtig hält. Ich wollte es aber nur mal der Vollständigkeit halber hier erwähnen, weil es gut in den Kontext paßt.

Grüße, Gerry

Hallo Gerry

Explizites Mappen ist meiner Meinung nach immer noch das beste.
Dinge wie Fuß-/Radwege oder Parkbuchten mit in das Tagging für die
Straßen zu nehmen ist nach meiner Ansicht ein Notbehelf wie Punkte
für ein Krankenhaus, weil das Gebäude noch nicht eingetragen ist.

Etwas direkt eingetragenes ist offensichtlich, während es versteckt in
Taggs von Wegen oder in Relationen nicht direkt erkannt wird.

JM2C
Edbert (EvanE)

Meinst Du damit, für jede Spur ein eigener Way? Dann muss irgendwie die Information rein, an welcher Stelle frei gewechselt werden kann und wo nicht - wird wohl auch nicht einfacher.

Ich sehe diese Dinge als Eigenschaft der Straße (sofern keine bauliche Trennung vorliegt) und befürchte große Unübersichtlichkeit beim verwenden von Ways für jede Spur, abgesehen davon, dass ich zu faul wäre, die alle zu zeichnen. Letztenendes ist das ganze Thema aber eine Geschmackssache, deswegen sollte man die Leute erst mal machen lassen und irgendwann mal schauen, was sich durchsetzt. Aus diesem Grund möchte ich mich auch gerne gleich wieder aus der Diskussion raushalten, weil wir und jetzt Seitenweise Für-und-Wider dies und jenes an den Kopf werfen könnten, ohne nur einen Schritt weiter zu sein. Ich habe das ganze, wie gesagt, nur erwähnt, damit ein Gleichgewicht bei der Auswahl des bevorzugten Tagging-Schemas hergestellt ist, und der Spurenansatz (davon gibt es ja noch mehrere) nicht aus reiner Nicht-Kenntnisnahme verliert.

Das ist zwar auch eine Sache der verwendeten Software, vorstellbar wäre etwa ein GUI-Spuren-zusammenklick-Tool. Dass die Visualisierung möglich ist, hat Nils schon mal bewiesen. Aber das Ganze ist in praxistauglicher Form derzeit nicht vorhanden, deshalb geht der Punkt schonmal an Dich. Achso, ich wollte mich ja raushalten…

Grüße, Gerry

Hallo Gerry

Spuren muss man (mMn) nicht einzeln erfassen. Die Lanes-Angabe reicht da völlig.
Abbiegespuren sind die Ausnahme von der Regel. Sie werden jedoch bei
entsprechender Bedeutung (Umgehung der Ampel) oder baulicher Trennung
meistens heute schon erfasst. Das ist soweit (für meine Begriffe) gut gelöst.

Mir ging es um die Fuß-/Radwege, da für diese in der Regel andere Einschränkungen
als für die Straße gelten.

Wie ich zur Zeit in Dortmund sehe, sind bauliche Trennung zwischen Fuß-/Radweg sehr
viel verbreiteter als man gemeinhin annimmt. Ich sehe es als wichtig an, Fuß-/Radwege
z.B. neben einer Primary/Trunk/Motorway insbesondere mit getrennten Fahrtrichtungen
separat zu erfassen, da deren Regelungen von der Straße oft deutlich abweichen.

Um auf das eigentliche Thema Parkbuchten neben der Straße zurückzukommen,
so sehe ich das durchaus differenziert.

• Parken auf der Straße: Das ist eine Eigenschaft der Straße
• Parken parallel neben der Straße (eigene Parkbucht): Grauzone
• Parken senkrecht neben der Straße: Kann man separat erfassen.

In Dortmund werden z.B. die Parkflächen zwischen getrennten Fahrspuren
extra eingezeichnet. Das halte ich für absolut sinnvoll, da man nicht davon
ausgehen kann, das man auf dem Mittelstreifen Parken darf oder kann.

Ein Vorteil ist natürlich, dass einzel erfasste Sachen wie Abbiegespuren eben
auch auf den Karten dargestellt werden und so ein rein optisches Erkennen
der Situation möglich ist.

Ebenso erklärt der eingetragene Parkplatz rein optisch, warum da ein Parkplatzweg
ist, und zeigt an, dass man dort ggfs. schauen kann, ob man dort ein Plätzchen
für den fahrbaren Untersatz finden kann.
Umgekehrt kann man als Fußgänger/Radfahrer ggfs. einen Bogen darum machen.

Edbert (EvanE)

Auf der Suche nach einer anderen Information auf der Karte falle ich auf einen Radweg auf dem hohen Bord dessen Verlauf eine (berüchtigte da unfallträchtige) Schlangenlinie macht, weil der Radweg von der Bordsteinkante Richtung Hausmauer gezogen wird, damit auf dem hohen Bord 6 Parkbuchten (gelesen in Bing-Luftaufnahme an der Anzahl der dort sitzenden Fahrzeugen) entstehen können. 4…5 m nach der letzten Bucht in Fahrrichtung gesehen, gibt es eine Ampel. Kürzlich gab es dort einen schrecklichen Unfall: Eine Radfahrerin wurde vom in gleicher Fahrrichtung wie sie, die allerdings gerade aus ihre Fahrt an der Ampel fortsetzte, fahrenden Rechts-Abbieger Übersehen und wurde mehrere Meter in die Luft (laut offiziellem Polizeibericht) geschleudert! Diese Konstellation gibt es oft: Parkbuchten gehindern die Sicht der fahrenden Verkehrsteilnehmer bzw. verdecken sie den Anderen, und verändern den logischen Verlauf der Rad- und Fusswegen…

Ich wollte also diese Buchten taggen, und fand sofort in Potlatch2 ein geeignetes Symbol für einen Punkt, nämlich «Car parking» Type «Surface outdoor» Capacity «6» (? von Potlatch: «The number of cars that can be parked in the car park»). Nichts zu zeichnen, ein tolle Icone erscheint jetzt an der richtigen Stelle, 3 Klicks und alle infos sind drin, da in diesem Fall weder Geld verlangt wird noch Parkzeitbeschränkung besteht… Aber natürlich, wenn man lieber malen möchte (anstatt die Funktion “bearbeiten” zu gebrauchen um mit Potlatch2 in Bing Luftaufnahmen genau zu schauen, was jeder tun kann, wenn er mehr wissen will)!

Warum das Rad neu erfinden?

Oder ist diese Potlatch2-Lösung nicht mehr gültig / gut genug?

(Hinweis: in der tagtäglichen Praxis ist es in der Wirklichkeit auch so - die gleiche Icone erscheint am Strassenrand alle zig Meter und weist auf dem Vorhandensein von Parkraum hin! Nur in Spielstrasse müssen die Parkräume meines wissen deutlich extra dargestellt werden, und nur dort darf geparkt werden - so stand es als ein grosses Baby vor einigen Monaten von einem Hummer in einer Spielstrasse überfuhr und tötete, weil man angeblich in diesen Autos rund herum nichts sehen kann (als ehemaliger Panzerfahrer weiss ich, im Panzer ist es genau so…), und das Parken irgenwie beim Unfallgeschehen eine Rolle gespielt hatte!)