Ich trage jeden Parkplatz ein, auch Firmenparkplätze,
natürlich dann nur mit entsprechendem access-Tag.
Parkbuchten/spuren an Straßen trage ich hier nicht ein,
weil sich das nur mit Luftbildern lohnt.
Hi, weil ich gerade dieses Thema sehe. Vielleicht ist das für dich interessant: Wir haben hier in Würzburg einen Mapper, der sich intensiv Gedanken gemacht hat über ein Tagging-Schema für Parkplätze und außerdem ein Spezialrendering entwickelt hat.
Schau mal auf:
http://wiki.openstreetmap.org/wiki/User:Kay_D/parking
Aber für alle Fragen dazu wend dich doch mal an Kay direkt.
Grüße
[edit: Link korrigiert]
Uii, klasse Link!
danke
Das sieht wirklich gut aus.
Sollte auf die Map_Features
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