öffnungszeiten für tor?

Wie trägt man die Öffnungszeiten eines Tors (barrier=gate) ein? Etwa mit opening_hours? Hier in Berlin kenne ich einige, wo diese Zeiten dran stehen, aber bisher habe ich’s noch bei keinem eingetragen, weil ich nicht wusste wie.

Nochwas: Die breite des Tors? Vielleicht so: width=0.8 ?

hi,

vielleicht mit dem Key access

http://wiki.openstreetmap.org/wiki/DE:Key:access

Grüße

Michael

Ah. Also für ein von Mo-Sa von 6 bis 23 Uhr geöffnetes Tor trage ich was ein?

hour_on=23
hour_off=6

(oder umgekehrt?)

Und
day_on=Mo
day_off=Sa

(oder day_off=Su, weil das der ersteTag ist, an dem das Tor zu ist)
Auf der Wikiseite steht, dass man die Wochentage ausschreiben soll. Wieso nicht wie bei opening_hours und collection_times? So ein Chaos!

Ich muss sagen mit etwas wie opening_hours ist es viel einfacher, weil man da den Wochentag gleich mit dabei hat.

Kann mir bitte jemand helfen, der sich damit auskennt? Oder gibt es da keinen Konsens?

Ich denke es gibt (noch) keinen Konsens, weil das nicht unbedingt ein häufiges Problem ist.

*_on bezeichnet die Zeit/den Tag an dem eine Einschränkung beginnt.
Du hast aber zwei Tages-Typen:
Montag-Samstag mit Nachtsperrung und Sonntag mit Vollsperrung.
Das kann man meines Erachtens mit on/_off nicht sauber abbilden.

Ich würde das abhängig von der Situation machen:

  • Durchgang wird gesperrt → hours_on/hours_off
    eventuell access-Rechte an den Weg.
  • Eingang zu einem Gelände → Gelände eintragen
    (falls noch nicht erfolgt) und daran opening_hours

Edit:
Breite des Tors mit width=, evtl. auch maxwidth= falls das Tor schmaler ist als der eigentliche Weg. Dann bitte ein width=* auch an den Weg.

HTH
Edbert (EvanE)

+1
Da weiß man gleich, was gemeint ist!
Mach es einfach so, einer muss mal anfangen.

Ich sehe noch ein anderes Problem mit dem hour_on und _off. Jetzt mal abgesehen von dem Tor gibt es auch Straßen mit temporären Einschränkungen. Das wäre Beispielsweise die Geschwindigkeit. Speziell vor Schulen und das Parken meist vor kleineren Geschäften. Wie soll man jetzt wenn beide Einschränkungen zusammenfallen, das eine vom anderen trennen? Immerhin ist es ja möglich vor der Schule zu parken, nicht nur wenn die Geschwindigkeitsbegrenzung gilt.

Gut, dann werd’ ich’s wieder zu opening_hours ändern.

Mit Doppelpunkten trennen? Das ist doch bei vielen anderen Dingen auch so, wo sich ein Schlüssel-Wert-Paar auf ein anderes bezieht.

Jetzt mal mit opening_hours – wobei das für maxspeed wieder nicht passt, eigentlich müsste da zu opening_hours (was Zeiträume angibt) und collection_times (was Zeitpunkte angibt) noch was drittes, denn bei opening für 'ne Geschwindigkeitsbegrenzung ist nicht klar, ob die Zeiträume für die Begrenzung oder die freie Fahrt gelten, also noch active_hours? Oder sogar nur hours?


maxspeed=30
maxspeed:active_hours=Mo-Fr 6:00-17:00

oder


maxspeed=30
maxspeed:hours=Mo-Fr 6:00-17:00

Und Parken? Wenn man nur nachts parken darf beispielsweise:


amenity=parking
parking:hours=Mo-Sa 21:00-6:00; Su 0:00:24:00

oder


amenity=parking
access:hours=Mo-Sa 21:00-6:00; Su 0:00:24:00

Mit diesem hours oder active_hours könnte man automatisiert alle Vorkommen von day/hour_on/off in der Datenbank ändern.

Für meine Tore könnte man dann statt opening_hours auch das allgemeinere hours benutzen:


barrier=gate
access=private
access:hours=Mo-Sa 6:00-23:00

oder


barrier=gate
access=private
gate:hours=Mo-Sa 6:00-23:00

wobei bei letzterem wieder nicht eindeutig ist, ob gate:hours die Zeiten meint, wo man durch kann, oder die Zeit, wo das Tor zu ist. Also lieber mit access.

Man müsste was eindeutiges, einfach verständliches und universelles erfinden. Auf jeden Fall dieses hour_on hour_off ersetzten (erst mal im Wiki und in den Editoren, dann irgendwann auch automatisiert in der Datenbank.

Damit kann man zwar einen einzigen Wert an- und abschalten, aber es funktioniert nicht für mehrere unterschiedliche Werte - etwa maxspeed 30 von … bis, 50 von … bis …

Funktionierende Varianten sind:

  • Zeit im Schlüssel, z.B. maxspeed:(Mo-Fr 6:00-17:00) = 30
  • Zeit und eigentliche Werte im Wert, z.B. etwas wie maxspeed = Mo-Fr 6:00-17:00 “30”
  • “Verbindung” von mehreren Tags über Nummern o.ä., z.B. maxspeed_1=30 maxspeed_1:hours=Mo-Fr 6:00-17:00
  • “Verbindung” von Tags durch Relationen

Andere Alternativen hab ich in den jahrelangen Diskussionen zum Thema noch nie gesehen. Zumal die eh immer wieder von vorne anfangen, nämlich beim unbrauchbaren hours_on/hours_off…

@Tordanik: +1

Und ich würde die zweite Variante (allerdings eventuell mit anderer Schreibweise) präferieren. Besonders flexibel und es gibt nur ein Tag auszuwerten. Problem ist bloß, dass es dann keinen ‘Standardwert’ gibt, z.B. für Renderer, die ja nicht alle fünf Minuten einen neuen Stand rendern können.

Also es gäbe dort sicherlich dutzende Möglichkeiten das auszudrücken. Netzwolf hatte sich auch schonmal Gedanken dazu gemacht. Allerdings wurde das verworfen, weil es nicht sehr einfach umzusetzen ist.

Hmmh, schlechtes Beispiel.

  • Mappe die Parkmöglichkeit getrennt von der Straße.
  • Hier in Bonn gibt es keine zeitabhängige Vmax vor Schulen.
    a) Schulen werden auch ausserhalb der Schulzeit genutzt.
    b) Für jemand ohne schulpflichtige Kinder sind Schul-/Ferienzeiten
    nicht offensichtlich.
    → Vmax rund um die Uhr

PS: Das Problem hat man immer, wenn man zuviel Dinge (Parken, Radweg, …) per Tagg an eine Straße hängt.

JM2C
Edbert (EvanE)

du möchtest also eine Parkspur neben der Straße obwohl die baulich nicht davon getrennt ist. Mhhh

Ob der jenige Schulkinder hat oder nicht spielt keine Rolle. Es steht am Verkehrsschild auch dran 30 Mo-Fr 6:00-19:00 Somit weiß jeder was los ist. Das kommt hier sehr oft an Schulen vor. Aber nicht nur.

OK, dann ist diese Stelle eindeutig.
Es soll auch Stelle geben wo sinngemäß steht: An Schultagen … Einschränkung.

Edbert (EvanE)

Das ist ganz schlecht automatisiert auszuwerten, da es keinen festen Schlüssel oder wenigstens einen Satz fester Schlüssel gibt.

Das ist eine Möglichkeit, allerdings fehlt da der Hinweis, das es sich bei der 30 um die maxspeed=* handelt.

Das ist eine schlechte Notlösung, das macht man besser über Relationen, um solche Sachen zu vermeiden hab ich bessere Möglichkeiten zur Abbildung von Baumstrukturen die für API 0.7 vorgeschlagen.

Aus meiner Sicht das momentan einzig sinnvolle, indem man den Kindes- und Kindeskinder-Mechanismus dazu nutzt, eine Baum für das Objekt zu basteln, der mehr der Realität entspricht.

Jdenefalls sollte man day_on/off, usw. durch opening_hours ablösen, zum einem ist es flexibler, weil man mehrere Zeiträume, aber leider auch nur für eine Eigenschaft, angeben kann und zum anderen würde dadurch das Tagging sinnvoll vereinheitlicht.

Wie wäre es mit


maxspeed=70
maxspeed:hours=So 10:00-15:00
maxspeed:30:hours=Mo-Fr 8:00-16:00
maxspeed:50:hours=Sa 12:00-13:00

Somit hätte man einen enfachen Standartwert und ein paar Zusatzinfos für die guten Navis. So ähnlich, also mit Doppelpunkten getrennt, gibt’s doch schon andere Sachen wie name:en=Cologne, name:de=Köln, name:es=Cologna usw.

Naja, aber wirklich eindeutig und einfach ist das auch noch nicht. Aber besser, denn das System mit den Namen finde ich sehr einfach und eindeutig.

Das Problem ist, das alles mit mehr als einem variablen Subkey (also in der Regel mehr als einem “:”) schlecht auszuwerten ist. Deshalb gibt es ja z.B. auch nur name:= und nicht z.B. highway:right_side:path:access:bicycle=designated (so könnte dann ein Tag eines kombinierten rechtsseitigen Fuß-/Radweges aussehen). Nur mal als etwas übertriebenes Beispiel, weil es Leute (http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk) , die möchten offenbar gerne solche Tags haben.

Das Hauptproblem, das ich da sehe, ist dass der Wert in den Schlüssel wandert, was nicht Sinn der Sache sein kann. Außerdem ist es meiner Meinung nach einfacher, einen komplexen Wert eines eindeutigen Schlüssels zu zerlegen (wenn die Syntax gut durchdacht ist), als mehrere unbekannte Schlüssel mit einfacheren Werten auszuwerten.

Das seh ich auch so. Interessant ist da aber der Grenzfall, daß wenn zwar nicht alle Subkeys bekannt, diese aber von der Konzeption her für denn gegebenen Fall eindeutig sind (z.B. health_specialty:*=yes), ich es besser finde, man schreibt den Wert dann doch wieder in den Key, weil das ist dann prinzipiell wieder besser als alle Werte ordentlich separiert im Wertefeld aufzuzählen.

Darüber haben wir uns ja schon gestritten, ich bin da anderer Meinung. Allerdings gebe ich zu, dass in dem Fall, weil die subkeys ja mehr oder weniger aus einer bekannten Menge stammen und (meist) nicht völlig beliebig sein dürften, das ganze wohl weniger Probleme aufwirft als bei oben genannten Vorschlägen.

Deshalb schrieb ich ja auch Grenzfall, das ist natürlich sehr vom Fall abhängig und es wird auch schon bei anderen Sachen wie z.B. fuel:* oder capacity:* gemacht, wobei das ja eher bei capacity:* noch kritischer ist, weil da benutzen wohlmöglich mehrere Leute eine andere Umschreibung für die gleiche Sache, weil viele sehen ja eben nicht immer erst mal auf z.B. taginfo nach.

Eigentlich entscheidet am ende doch eher der Gesamtaufwand und wenn ich Allgemeinmediziner suche hole ich mir eben die Daten mit health_specialty:family_medicine=yes/partial, was vom Aufwand her einfacher ist, als alle health_speciality=* (es heißt übrigens “specialty” und nicht “speciality”) auf das Vorkommen von “general” hin zu untersuchen.

Ich will aber nicht hier herumzankenken, weil es eben auch sehr fallabhängig ist und ein Subkey mit “:” aus meiner Sicht noch besser ist, als solche Sachen wie highway=service + service=. Wobei man bedenke, das service= per se ja völlig unabhängig ist und so grundsätzlich auch nicht an highway=* gebunden ist, was dann lustig der Datenextraktion, eben wegen genau dieser gemischten Verwendung wird, weil man noch jede andere Verwendung von service=* mit durchforsten darf.