warum das denn? die sind doch da. bei uns gibt es dafür auch parkautomaten. aber die kapazität sollte schon rein.
mantra …
mfg
walter
Naja, aber als Fläche getaggt nebendran … das trifft’s doch nicht so richtig, oder?
kleine park-“plätze” als node, gößere als fläche. so mach ich es. wo da die grenze liegt, bleibt dir überlassen. meine liegt bei der anzahl der reihen (>1)
dein eigentliches “problem” liegt bei den renderen, deren autoren das abhängig von der zoom-stufe gemacht haben. und ich glaube nicht, dass sich daran was ändert.
gruss
walter
Hallo Walter, i3u
Das muss man vor Ort entscheiden, ob das eine Besonderheit ist,
die man in der Karte haben will oder ob es etwas so normales ist,
dass es eigentlich keiner Erwähnung wert ist.
Es gab ja genug Vorschläge für ein abgestuftes Vorgehen, dass die
Situation entschärften kann. Davon hast du ja auch einiges umgesetzt.
(Ist in Mapnik aber noch nicht neu gerendert worden.)
Edbert (EvanE)
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