Anzeige und Auswertung von "opening_hours"

Communities Deutschland (Germany)
61

Super… Vielen Dank…
ufff… wobei ich gerade gesehen habe, dass ich fast alle von mir getaggten Öffnungszeiten korrigieren muss… tja…

62

Zu (1): Zum Rechner sind Computer da, nicht der Mensch! Wenn ich nicht an der Starthaltestelle man eben schnell den Fahrplan Knipse oder abschreibe, dann will ich ihn nicht noch für alle Bereiche/Zeiten auf die Strathaltestelle umrechnen müssen, was außerdem zusätzlich fehlerträchtig ist. Ja, die Optimallösung ist nicht immer die beste, denn man muß bedenken, das die Daten bei OSM vom Menschen und deshalb möglichst leicht zu erfassen sien sollen. Aber ist echt OT hier, da gibts auch schon ältere Threads dazu.

63

Nahmd,

Ich sprach von der internen Darstellung. Dass die nicht trivial einzugeben ist, ist mir klar.

Aber an jeder Haltestelle den ganzen Fahrplan abtippern ist nicht machbar, insbesondere weil das 2* pro Jahr recht kurzfristig erledigt werden werden muss. Die VRS alleine hat über 6000(!) Haltestellen.

Eben wegen dieser immer wieder notwendigen Aktualisierung halte ich es für schlau, die Fahrpläne unabhängig von den Haltestellen zu speichern, möglicherweise in Relationen (sofern man irgendwie vermeiden kann, von den “Erfindern” der Relationen dafür gelyncht zu werden), möglicherweise in einer getrennten DB, und daraus die Daten für die Haltestellen abzuleiten und automatisch einzutragen.

Gruß Wolf

64

Moin moin,

Schreib einfach “Mo 23:00-01:00”. Das Skript interpretiert das schon richtig.
Es versteht auch “sunset-sunrise” – wichtig für Vampire.

Übrigens ist Splitten auch deshalb blöd, weil es zu Fehlern führen kann:
“Sep Mo 23:00-01:00” ist etwas anderes als “Sep Mo 23:00-24:00; Sep Di 00:00-01:00”, und zwar dann, wenn der Montag auf einen 30. fällt.

Sorry für die späte Antwort - ich hatte die Frage übersehen.

Gruß Wolf

65

ok, dann werde ich mal umtaggen…

66

Kann es sein, dass die Karte keine Öffnungszeiten zeigt, die auf Gebäuden getaggt sind?

Siehe z.B. http://www.openstreetmap.org/browse/way/80635180 auf http://www.netzwolf.info/kartografie/osm/opening_hours/map_at?zoom=18&lat=47.72142&lon=16.08034&layers=B00T

Viele Grüße,
Georg

67

Leider werden in der XAPI anfrage aus der die Öffnungszeiten entnommen werden nur nodes also Punkte berüksichtigt. Netzwolf hat aber bereits angekündigt später noch Verbesserungen daran vornehmen zu wollen. Zunächst war aber die richtige Interpretation aller möglichen Öffnungszeiten im Vordergrund. Wenn dies abgeschlossen ist werden vielleicht auch Linien und Flächenobjekte in die Auswertung einfließen können. Allerdings ist derzeit die XAPI unzuverlässig, so dass auch hier vielleicht andere Lösungen gefunden werden müssen.

68

Guten Abend,

folgende Fortschritte gabs in letzter Woche:

  1. Abstimmung mit dem Entwickler des JOSM-Plugins

  2. Auf dessen Wusch deutlich schärfere Syntaxabfragen

  3. Das Script versucht soweit möglich, trotz Fehlern weiter auszuwerten, und liefert als Ergebnis ein Objekt bestehend (u.a.) aus Öffnungsstatus und Fehlermeldung. Es kann gleichzeitig einen Fehler werfen und “geöffnet” melden: “Mp-Du 10:00-12:00; Su 18:00-20:00” ist fehlerhaft, aber jetzt (So 18:05) zu “geöffnet” auswertbar.
    Die Idee: in Testumgebungen werden mit Priorität die Fehler angezeigt, in echten Anwendungen dagegen wird man dem Nutzer so exakte Information liefern wie möglich: wer nach einer offenen Apotheke sucht, interessiert sich nicht für syntaktische Feinheiten.

  4. Die Karten zeigen diese kombinierten Zustände an: blauroter Ring für geöffnet und Fehler, grauroter Ring für geschlossen und Fehler.

  5. Ich bin die Werte der meisten Knoten in DE,AT,CH durchgegangen und habe die abbilden können. Die Syntax und das Auswerte-Skript sind damit für das erste stabil. Ich warte jetzt auf die Rückmeldung des Plugin-Entwicklers und auf (ausdiskutierte) Änderungswünsche aus der OSM-Gemeinde.

  6. Ich habe die Funktionsweise der Auswertung einmal mit vielen Beispielen ins Unreine geschrieben:

http://www.netzwolf.info/kartografie/osm/opening_hours/erklaerung.htm

Keine Panik, das Teil ist wegen der vielen Beispiele so lang.

An dieser Stelle brauche ich Hilfe: kann sich jemand des Materials annehmen, das aus Benutzer-Sicht umstellen/umschreiben/neuschreiben und dann ins Wiki packen? Ich bin mittlerweilen zu betriebsblind und weiß gar nicht, was es da zu erklären gibt, “weil doch alles offensichtlich ist” .oO( zumindest für mich )

Ich stehe natürlich jederzeit für Rückfragen oder auch zum Durchsehen zur Verfügung.

  1. Als Vorbereitung für die “collection_times” habe ich eine Syntaxerweiterung (Taktrate) gegenüber “opening_hours” in Grammatik und Auswerte-Skript eingebaut. Die Auswertung von “collection_times” droht also (und damit drohen von roten Kringeln übersähte Karten) , ist aber leider etwas schwieriger als die von “opening_hours”. Am Beispiel: die Öffnungszeit “Feb 29: Fr 10:00-12:00” ist trivial auszuwerten (Monat=2 Tag=29 Wochentag=Fr Zeit im Bereich), die collection_time “Feb 29: Fr 10:00” braucht listige Kalenderarithmetik oder wildes Suchen.

Jetzt zu den Fragen:

Leider ja.
Das Abrufen der Lines ist vorbereitet - nur geht bereits das Abholen der Nodes immer wieder schief.

Der Stand ist erreicht. Bis auf das Fixen möglicher Fehler und das Einarbeiten von Änderungswünschen ist im Moment nichts mehr zu tun.

Die XAPI ist ein Quell der Frustration.
Aber wie sonst soll ich an die Informationen kommen?

Eine eigene GEO-DB mit Feed mag ich nicht aufsetzen (Overkill für die paar Datensätze, die ich brauche), und die normale API liefert mir die Daten nicht.

Ich sehe die Möglichkeiten:

  • jemand flickt die XAPI
  • jemand mit einem eigenen Feed realisiert die “XAPI”-Abfrage für mich bei sich und liefert mir die Daten
  • die Karten ziehen zu jemandem mit eigenem Feed um
  • ich nagle ein Kissen an die Wand und haue den Kopf dagegen.

Gruß Wolf

69

Hi Netzwolf,
sehr gute arbeit, danke!

a) die xapi ist meines wissens nicht defekt, sondern überlastet.
b+c) ich hatte schon mal auf toolserver.org hingewiesen. das ist der deutsche wikimedia-server, der auch für viele lokale osm-projekte genutz wird.
die helfen gerne, gerade wenn es ein reifes produkt ist.
d) das arme kissen :wink:
gruss
walter

p.s. es gibt noch die möglichkeit, planet-extrakte (z.b. germany.osm) lokal zu scannen. liegt im aufwand etwa zwischen (x)-api und lokaler datenbank.
bischen wget, etwas script und perl-auswertung mit garies tools. http://svn.openstreetmap.org/applications/utils/gary68/

70

Klasse Arbeit Wolf… Sieht gut aus…

Bei der CH-Karte überfliegen, bin ich auf einen weissen Kreis gestossen, mit folgendem Node: http://www.openstreetmap.org/browse/node/403229201
opening_hour=“once a month” kann ja zwangsläufig nicht ausgewertet werden… nur, wie müsste man das taggen? Die Öffnungszeiten bis Ende 2011 sehen wie folgt aus: http://www.extra-ball.ch/?page_id=6

71

Nahmd,

16. Dezember 2010:

* Spielabend mit Barbetrieb und Tapas Köstlichkeiten 19:00

20. Januar 2011:

* Spielabend mit Barbetrieb und Tapas Köstlichkeiten 19:00

24. Februar 2011:

* Spielabend mit Barbetrieb und Tapas Köstlichkeiten 19:00

17. März 2011:

Das ist immer die gleiche Öffnungszeit, aber nur an einer willkürlichen Auswahl von Tagen. In diesem Fall muss man die Tage einzeln angeben, man erstellt also einen entarteten “Zeitraum” aus Einzeltagen:

2010 Dec 16, 2011 Jan 20, Feb 24, Mar 17: 19:00+

Gruß Wolf

72

Mir gefällt das Schema sehr gut, da es endlich eine präzise Definition bietet.

Bei der Erklärung sind mir einige Fragen offen geblieben:

  • Wenn “sunrise-0:30” “eine halbe Stunde vor Sonnenaufgang” bedeutet, wie taggt man dann “von Sonnenaufgang bis eine halbe Stunde nach Mitternacht”?
  • Die Abgrenzung zwischen Gültigkeitszeiträumen und Zeiten ist mir etwas unklar (gibt es überhaupt eine?). Da könntest du in der Einleitung evtl. etwas genauer eingehen.
  • Sollte es eine solche Abgrenzung geben: Wohin gehören dann die Feiertage/Ferien?
  • Kann man Hinweistexte auch über mehrere Zeiten definieren? (Ich hatte dieses Problem bei einem Schwimmbad wo ich Sommer-/Winterabhängig “Hallenbad” bzw. “Hallen- und Freibad” ausgeben wollte (natürlich unabhängig vom Wochentag).
  • Wäre es evtl. sinnvoll, optional mittels Klammern die Bereiche deutlicher zu kennzeichnen?

Dann wäre es m.E. auch an der Zeit mal wieder das Thema bedingter Fahrbeschränkungen auszugraben, da es ja eng mit der Frage von Zeitangaben verbunden ist. Gibt es da evtl. weitere Punkte zu berücksichtigen (z.B. wie man Zeit- und andere Bedingungen verknüpft)?

Gruß
GeoCounter

73

Sehr schön. Ich habe da nur eine Frage:

Was ist dann mit “von Sonnenaufgang bis nachts um halb eins”?

Edit: Argh, man sollte vielleicht vor dem posten mal F5 drücken, wenn man ne halbe Stunde gelesen hat^^

74

Nahmd,

Probiers einfach aus:
http://www.netzwolf.info/kartografie/osm/opening_hours/?OH=sunrise-0:30#evaluation
:slight_smile:

BTW: wie bekommt man das Formular zum Ausprobieren ins Wiki?
Kann man da JS benutzen? Und wenn nicht, ist ein IFRAME möglich?

An der Stelle spielt die deutsche Sprache nicht mit. Der Gültigkeitszeitraum hat nichts mit Zeit, sondern nur mit Tagen zu tun. Ich hoffe, dass die überwiegende Mehrheit der Anwender mit einer “elementaren Regel” auskommen und die darüber hinaus gehenden Mechanismen nicht nutzen müssen.

Die “Zeiträume” sind der Mechanismus, um unterschiedliche Regeln für unterschiedliche (hehe) Zeiträume angeben zu können, also z.B. für Winter und Sommer.

Feiertage und Ferientage werden zur Zeit auf der gleichen Ebene wie Wochentage behandelt. “Sonn- und Feiertage” = “Su,PH”. Man könnnte die Grammatik leicht so modifizieren, dass Schulferien und Feiertage auch zur Definition von “Zeiträumen” genutzt werden können – das würde aber das Konzept des “Zeitraums” sehr verwässern.

Zu mehreren Tagen kann für mehrere Zeiträume (aber die Gleichen!) ein Text mitgeliefert werden ( ):

Mo-Fr 08-12:00, 14:00-16:00 open “Hallenbad”

selection = Mo-Fr
timeranges = 08-12:00, 14:00-16:00
status = open “Hallenbad”

Mehrere Tage mit unterschiedlichen Zeiten lassen sich nicht zusammenfassen.

Das hängt vom Blickwinkel ab. Ich wäre z.B. sehr glücklich mit einer Grammatik a la SQL, die aus Elementarabfragen und logischen Operatoren zum Zusammenbauen besteht. Wäre viel einfacher zu bauen gewesen als die jetzige Version.

Ich hatte aber aus der Wiki-Spec das Ziel entnommen, eine lesbare und für >Normalmenschen< eingebbare Sprache zu finden.

“WDAY=MO OR WDAY=FR” ←→ “Wir haben Montags UND(!) Freitags geöffnet”

Logische Operatoren und Umgangssprache vertagen sich nicht wirklich gut.
Mir ist klar, dass man in manchen Fällen mit Klammern Geschwätzigkeit vermeiden könnte. Ich denke aber (bin mir aber bei all diesen Entscheidungen nirgendwo 100% sicher), dass man eher im Einzelfall etwas Geschwätzigkeit akzeptiert/fordert, statt eine endlose Fülle an Ausdrucksmöglichkeiten zu bieten.

Da bräuchte ich jetzt ein Beispiel.

Gruß Wolf

75

Nahmd,

Ist drin (bis März 2011):

http://www.netzwolf.info/kartografie/osm/opening_hours/map_ch?zoom=17&lat=47.20613&lon=7.52989

Was dabei auffällt:
der Unterschied zwischen collection_times und opening_hours ist noch geringer als ich dachte. Bei Orten mit so seltenen Öffnungszeiten ist nicht nur die Frage “ist jetzt offen?” (=opening_hours), sondern auch “wann ist das nächste Mal offen” (=collectíon_times) angebracht.

Gruß Wolf

76

Ja, scheint, dass es letzteres auswertet. Das ist aber natürlich auch nur mäßig gut, denn was, wenn es sich wirklich auf die halbe Stunde vor Sonnenaufgang beziehen soll. Man könnte dagegenhalten, dass in diesem Fall wohl eine weitere Zeit als Ende mit “-” folgen dürfte, aber sicher ist das nicht, denn sowas wie “We 10:00” ist ja auch erlaubt ohne Endangabe. Was auch dein Script nicht auswertet. Unter welcher Bedingung heißt sunrise-0:30 denn dann das von dir beschriebene?

77

Hier noch mal systematisch:


|                   05:29 06:01 12:00 00:01 00:31
sunrise-0:30       |false|true |true |true |false|
sunrise            |false|false|false|false|false|
06:00-0:30         |false|true |true |true |false|
06:00              |false|false|false|false|false|
06:00+             |false|true |false|false|false|
sunrise+           |false|true |false|false|false|
sunrise-0:30+      |false|true |true |true |false|
05:30+             |false|true |false|false|false|
sunrise-0:30-11:00 |false|true |false|false|false|
05:30-11:00        |false|true |false|false|false|

sunrise-0:30 scheint nur im letzen Fall als “halbe Stunde vor Sonnenaufgang” ausgewertet zu werden.
Das Verhalten bei sunrise-0:30+ wundert mich, hier hätte ich schon “ab 30 min vor Sonnenaufgang” erwartet.

Gruß
GeoCounter

78

Nahmd,

erstmal für alle zum Mitschreiben: wir sprechen von Öffnungszeiten.
Öffnungszeiten sind – anders als Abfahrtszeiten von Bussen – Zeitintervalle und keine Zeitpunkte.

Zeitintervalle sind dadurch gekennzeichnet, dass sie einen Anfangszeitpunkt und eine Endzeitpunkt haben. Fallen Anfangszeitpunkt und Endzeitpunkt zusammen, so ist dieses leere Zeitintervall nur für Wesen mit Ruhemasse 0 von Interesse.

Nun zu der Frage:

Da verweise ich doch glatt auf meinen einführenden Text: wir sprechen von Öffnungszeiten.
Und zu einer Öffnungszeit gehören – richtig – zwei Zeitangaben.

Die Prioritäten des Parsers sind so gesetzt, dass er in allen (vernünftigen) Fällen die richtige wählt.

Was hat das eine mit dem anderen zu tun?

  1. Im Umfeld von Opening-Hours sind nur Zeitbereiche sinnvoll, Einzelzeitpunkte dagegen sinnfrei.
    Der Parser wählt bei Mehrdeutigkeit die sinnbehaftete Alternative.
    Was genau ist daran falsch und/oder schwer zu verstehen?

  2. Zeitangaben können syntaktisch korrekt und gleichzeitig sinnfrei sein.
    Das liegt einfach daran, dass ich die exakt gleiche Syntax für Opening_hours und Collecting_times nutze.
    Das spart Arbeit. Das spart Doku. Das spart dem Nutzer Lernaufwand.

Natürlich könnte ich Einzelzeitpunkte bei der Auswertung als Opening_hours verbieten (was ich übrigens temporär einmal aktiviert habe). Nur was gewinne ich dabei?

Du irrst.
Die Einzelzeitangabe wird bei Auswertung als opening_hours sowohl sinnvoll als auch verträglich mit der Auswertung als collection_times interpretiert. Wenn Du die Granularität der Zeitangaben berücksichtigt, kommst Du wohl auch drauf, wie genau es interpretiert wird. Das soll und braucht aber niemand zu nutzen.

00:00-sunrise-0:30
sunset+0:30-sunrise-0:30
sunrise-0:30-sunset+0:30
sunrise-sunset-0:30

Was willst Du ausdrücken und funktioniert naiv hingeschrieben nicht?

Gruß Wolf

79

Ist eine Frage ohne konkreten Anwendungsfall gewesen. Nur ob da nicht theoretisch zwei Dinge, die unterschiedliche Aussagen treffen sollen, gleich dargestellt werden. Ansonsten nimm als Anwendungsfall eben eine collection_time an, da machen Einzelzeitpunkte ja Sinn und ich kann trotzdem nicht den Zeitpunkt “30 Minuten vor Sonnenaufgang” angeben. Ich sage ja nicht, dass das tragisch ist, aber bedenken sollte man es theoretisch. Vor allem, wenn auf der Erklärungsseite eben dieses Beispiel steht und das nicht in einem Kontext wie die vier Beispiele, die du jetzt gebracht hast. Das könnte verwirren. Zumindest hat es mich und offensichtlich GeoCounter verwirrt :wink:

80

Nahmd,

ich habe in die Übersicht hineingemalt:

Hmpf! Es wundert Dich zurecht. :frowning:

Ich habe den Fehler sogleich korrigiert:
http://www.netzwolf.info/kartografie/osm/opening_hours/?OH=sunrise-0:30%2b#evaluation

Danke für den ausgiebigen Test und genauen Fehlerhinweis.

Gruß Wolf