Es gibt durchaus viele Parkplätze, bei denen Parkscheiben vorgeschrieben sind. Dies ist auch eine durchaus relevante Eigenschaft eines Parkplatzes, denn wenn man irgendwohin will und einen Parkplatz in der Nähe ausgeguckt hat, dann wäre es ja dumm, wenn man hinkommt und feststellt, dass man nur eine Stunde parken darf, aber der Termin 3 Stunden dauert. Nach einigem Suchen habe ich “maxstay” gefunden. Damit kann man sehr schön angeben, wie lange man parken darf. Aber dies gilt ja meist nicht Nachts und am Wochenende. Hat sich schon jemand Gedanken gemacht, wie man die Zeiten tagged(?), während denen die Parkzeitbeschränkung, die man mit maxstay angibt, gilt? Karl
Hi Karl, ich habe hier gerade ein Proposal für die Leerungszeiten der Briefkästen gemacht (http://wiki.openstreetmap.org/wiki/Proposed_features/emptying_time). Dort verweise ich auch auf die Öffnungszeiten für Geschäfte. In Deinem Fall kann man die Zeit-Syntax auch verwenden, und zwar im Sinne von “Gültig zu diesen Zeiten”. Ich könnte mir also vorstellen, dass man ein Tag “affected_hours” oderso einführt, sofern es das noch nicht gibt. Das wäre dann eine ganz allgemeingültige Angabe, die u.a. für die Parkzeitbeschränkung verwendet werden kann. Für sich alleine hat sie allerdings keine Bedeutung. Vielleicht sollte man das Tag auch so stricken: affected_hours:tagname=*. Das hätte den Vorteil, dass man die Angabe ganz konkret auf eins der anderen verwendeten Tags beziehen könnte. Ein Parkplatz könnte demzufolge so aussehen: amenity=parking maxstay=3 hours affected_hours:maxstay=Mo-Fr 08:00-18:00 Ein Problem hätte man damit allerdings: Man könnte nicht abbilden, dass es zwei unterschiedliche Beschränkungen gibt, z.B. tagsüber 1 Stunde und abends 3 Stunden. Das ließe sich zwar problemlos in affected_hours notieren, aber nicht insgesamt in einem Objekt. Dieses Problem besteht allerdings mit jeglicher Angabe, die mehrere Werte haben kann. Vielleicht kannst Du anhand dieser Infos ja nochmal auf die Suche gehen, ob es schon was gibt und ggf. ein derartiges Proposal auf den Weg bringen, wie ich es gerade mit der emptying_time mache. Die normale Wiki-Suche links ist übrigens manchmal auch ganz nützlich, falls Du sie noch nicht probiert hast. PS: Man sollte sich bei Werten wie Zeiten immer auf eine Einheit einigen. Im Falle von maxstay hätte ich Stunden genommen. Damit fallen die Einheiten weg, und wenn man 7 Tage stehen darf, dann sind das eben 168 Stunden. Kristian
Suche mal nach den “opening hours” für Einrichtungen und den “access time restrictions” für solcherart Beschränkungen. Damit lässt sich das machen.
Wäre maxstay:affected_hours=Mo-Fr 08:00-18:00 nicht logischer? Da müsst ich mir nochmal den Vorschlag zu hirarchischen Schlüsseln ansehen. Wenn man maxstay und affected_hours einfach in eine Relation packt, dann brauch man keine hirarchischen Schlüssel mehr, und kann durch mehrere Relationen auch für andere Tageszeiten andere maxstay-zeiten angeben. Ich weiß zwar, dass Relatonen nachwievor umständlich sind, und kaum unterstützt werden. Aber die Möglichkeiten sind einfach enorm…
Wie willst Du denn *Tags *in eine Relation packen? By the way, hast Du den besagten Link zu den hierarchischen Schlüsseln gerade da? Ich glaube, das war ein Monster-Thread geworden, oder? Ansonsten ist Deine Variante auch nicht verkehrt, doch sie kann auch nicht mehr als meine, glaube ich 
Insofern könnten sie gleichwertig und gleichermaßen logisch sein.
Ein Monster-Thread [1] nicht gerade, aber relativ lange Beiträge. Allerdings habe ich da auch nicht alles ganz verstanden. Eigentlich wollte ich das ja im Wiki zusammenfassen, aber im Detail ist dann auch wieder nicht alle ganz klar. Wenn man Relationen lediglich zum Zusammenfassen von Tags nutzt, könnte man das Gleiche eigentlich auch mit entsprechenden Tags erreichen. Ein Vorteil wäre natürlich vielleicht bei Relationen, dass man komplizierte Beschränkungen leichter wiederverwenden kann. Andererseits ist es auch wieder gefährlich dann in der Relation was zu verändern, was vielleicht nur auf einen der Mitglieder zutrifft. [1] http://forum.openstreetmap.org/viewtopic.php?id=1284
Das ist doch kein Problem. Eine Relation ohne Tags macht doch auch nicht viel Sinn… Ich weiß zwar, dass Relationen eigentich nicht dafür gedacht sind ein hirarchisches Tagging zu ermöglichen. Aber möglich ist es. Das sähe dann etwa so aus: Way 1 - Tags: amenity=parking Relation 1 - Tags: maxstay=3 hours, affected_hours=Mo-Fr 08:00-18:00 - Members: Way 1 Relation 2 - Tags: maxstay=5 hours, affected_hours=Sa-Su 07:00-10:00 - Members: Way 1
Achso … ohje … okay, das geht natürlich. Aber das erfordert zumindest eine gute Dokumentation, damit Du die passende Relation auch findest, wenn Du sie brauchst und nachher nicht die gleiche x-mal vorhanden ist. Hm … ich weiß nicht, ob das ein Modell ist, das sich durchsetzen würde. Aber ich vermute mal, dass es mit den Richtungs- und Abbiegebeschränkungen, in deren Zusammenhang auch oft das Wort “Relation” fällt, ähnlich gelagert ist, oder? Habe mich damit noch nicht so richtig befasst. Transparenter ist natürlich, wenn alle Tags im Knoten selbst vorhanden sind. Relationen würde ich nur dann anwenden, wenn wirklich eine gemeinsame Eigenschaft von besonderer Bedeutung vorliegt, und die Parkdauer von ansonsten unabhängigen Parkplätzen zählt meiner Ansicht nach nicht dazu
Ich würde nicht die gleiche Relation für verschiedene Wege benutzen … das würde wirklich viel zu unübersichtlich werden. Man benutzt ja auch nicht die gleiche Multipolygon-Relation für alle Häuser. Ich meine, dass man die Relation nur für den einen Punkt (oder way, je nachdem) benutzt. Auch wenn das Wort “Relation” dann nichtmehr passt. Ist halt ein wenig eine Zweckentfremdung. Richtungs und Abbiegebeschränkungen finde ich sogar komplizierter, und auch noch nicht ausgereift, wesswegen ich die auch noch nicht verwende…
Die Abbiegerelationen sind wie ich finde recht einfach - ich habe sie schon oft benutzt - aber aus meiner Sicht sind sie falsch designed. Momentan gibt man z.B. mit restriction=only_left_turn an, das man von einer Straße in eine andere nur links abbiegen darf. Dies scheitert aber, wenn man eine Kreuzung hat, von der mehrere Wege mehr oder weniger nach links abzweigen. Die kann man zwar alle als “to” eintragen, aber dann ist das left in only_left_turn überflüssig. Sinnvoller wäre es zwei Gruppen zu haben: this_way und not_this_way. this_way würde die Wege kenzeichnen zu denen man vom aktuellen weg darf und not_this_way in die man nicht rein fahren darf. Je nach dem, welcher von beiden mit weniger Argumenten auskommt würde genommen. Und das via-tag in den aktuellen restriction-Relationenen ist sowieso total überflüssig; zu mindest habe ich noch keien Sinn dafür entdecken können. Evtl. sollte man zu den Restrictions noch mal eine allgemeine Diskussion lostreten. Die meisten Mapper die ich kenne setzen sie momentan noch nicht ein, weil sie sie zu kompliziert finden. Meine 2 €cent, detlef
@ zottel: Ich bin ganz genau deiner Meinung! this_way_only und not_this_way wäre wesentlich ausgereifter… und mit “komplizierter” meinte ich auch nur, dass mein Vorschlag hier zu den Parkzeiten einfacher ist, als das aktuelle Turn-Restrictions-Propos