Anzeige und Auswertung von "opening_hours"

Netzwolf · 2010-12-11T17:33:59.000Z

Nahmd,

viw:

So jetzt muss ich nochmal nach den Unterschieden zwischen “,” und “;” fragen.
Wenn Mo-Fr 10-16 Uhr und zusätzlich Do bis 20 Uhr auf wäre würde ich dann schrieben Mo-Fr 10:00-16:00; Do 16:00-20:00 oder besser Mo-Mi,Fr 10:00-16:00;Do 10:00-20:00 oder noch ganz anders?

Solange der Spezialtag nur zusätzliche Öffnungszeit hat und nicht weniger, kommt man mit der einfachsten Form aus:

Mo-Fr 10:00-16:00, Th 16:00-20:00

Hier ist für Donnerstag die “zusätzliche” Zeit notiert.

Man kann aber auch die komplette Zeit angeben:

Mo-Fr 10:00-16:00, Th 10:00-20:00

oder

Mo-We,Fr 10:00-16:00, Th 10:00-20:00

Die beiden letzten Fälle könnte man auch mit “;” schreiben bei gleicher Bedeutung. Ich will in der Doku aber das “;” als seltene Ausnahme darstellen. Die meisten Objekte haben an Feiertagen geschlossen und kommen in der Beschreibung ohne “;” aus.

Gruß Wolf

Fabi2 · 2010-12-11T18:31:09.000Z

viw:

So jetzt muss ich nochmal nach den Unterschieden zwischen “,” und “;” fragen.

Ich versuch es auch mal:

Erst mal die ganz wichtige Erkenntnis von mir: das ganze System basiert auf der Grundeinheit “Tag”, wird etwas neu definiert, dann wird also immer minimal auf Tagesbasis überschrieben. Die Bereichs-/Wochen-/Monats- etc. Regeln überschreiben dann einafch nur ein Vielfaches an Tagen.

Vom Prinzip her sind “,” und “; +” von der Bedeutung gleich, es wird immer zu den bestehenden Regeln (uberschreibend auf Tagesbasis) hinzugefügt, nur daß man bei “,” eben keine anderen Gültigkeitszeiträume angeben kann, und deshalb dafür einen neue Regel braucht.

Die Bedeutung von “;” ist quasi “vergiß für die Auswertung alle bisher definierten Regeln” und die von “; +” ist das Gegenteil, also “vergiß die bisher definierten Regeln nicht, sondern ergänze sie”.

Ich hoffe die Erklärung ist halbwegs richtig.

Netzwolf · 2010-12-11T20:40:48.000Z

Nahmd,

Fabi2:

Erst mal die ganz wichtige Erkenntnis von mir: das ganze System basiert auf der Grundeinheit “Tag”, wird etwas neu definiert, dann wird also immer minimal auf Tagesbasis überschrieben.

Ja, genau. Das war für mich so offensichtlich, dass ich nie darauf hingewiesen habe.
Eine Regel ist vollständig für einen Tag zuständig oder gar nicht.

Fabi2:

Die Bereichs-/Wochen-/Monats- etc. Regeln überschreiben dann einafch nur ein Vielfaches an Tagen.

Die Bereiche sagen, ob eine Regel anwendbar ist oder auch nicht.

Fabi2:

Vom Prinzip her sind “,” und “; +” von der Bedeutung gleich, es wird immer zu den bestehenden Regeln (uberschreibend auf Tagesbasis) hinzugefügt, nur daß man bei “,” eben keine anderen Gültigkeitszeiträume angeben kann, und deshalb dafür einen neue Regel braucht.

Ja.

Fabi2:

Die Bedeutung von “;” ist quasi “vergiß für die Auswertung alle bisher definierten Regeln” und die von “; +” ist das Gegenteil, also “vergiß die bisher definierten Regeln nicht, sondern ergänze sie”.

Ich versuche es mal anders:

Prinzip:
Eine “Regel” ist eine Folge von Tag→Zeit-Zuordnungen mit “,” aufgereiht ohne “;” drin.
(Ich bin auf der Suche nach einem besseren Namen als Regel)
Prinzip
Eine Regel ist anwendbar, wenn einer ihrer Tagesangaben zutrifft (Mo-Th ist an Dienstagen anwendbar) und wenn Sie in einem aktiven Zeitbereich sitzt (Nov-Feb: Sa-Su ist an einem Samstag im Dezember anwendbar)
Prinzip:
Es wird genau eine Regel zur Auswertung herangezogen, und zwar die letzte, die anwendbar ist.

Gruß Wolf

GeoCounter · 2010-12-11T21:25:15.000Z

Nur mal zum Verständnis: Das was du hier “Regel” nennst ist aber nicht dasselbe, was du in der Spezifikation als “rule” bezeichnest? (rule enthält, wenn ich es richtig lese, doch auch die Zeitbereiche)

Gruß
GeoCounter

Netzwolf · 2010-12-11T23:03:09.000Z

Nahmd,

GeoCounter:

Nur mal zum Verständnis: Das was du hier “Regel” nennst ist aber nicht dasselbe, was du in der Spezifikation als “rule” bezeichnest? (rule enthält, wenn ich es richtig lese, doch auch die Zeitbereiche)

In der Grammatik nenne ich es noch “Command”; ich meine damit alles, was kein “;” enthält.
Ich versuche gerade, treffende Namen zu finden …

Gruß Wolf

Fabi2 · 2010-12-12T04:47:59.000Z

Netzwolf:

Es wird genau eine Regel zur Auswertung herangezogen, und zwar die letzte, die anwendbar ist.

Danke. Das war entscheidend und damit ist daß ganze ja dann doch einfacher, als ich dachte.

GeoCounter · 2010-12-15T00:25:48.000Z

Hallo Netzwolf,

Mir ist gerade aufgefallen, dass du die Spezifikation noch einmal überarbeitet hast.

Die Bezeichnungen und besonders die farbliche Absetzung erleichten das Verstehen ungemein (wobei ganz am Anfang <calendar_ranges> auch noch rot sein könnte - oder wird es dann optisch zu dominant?)

Das “||” soll (wenn ich es richtig verstehe) das “+” ersetzen und ver-oder-t die Regeln?

“off” bezieht sich auf den kompletten Wochentag, “closed” dagegen nur auf Uhrzeiten - wäre es da nicht sinnvoller beides zuzulassen?

Was soll “/” bedeuten? Ich bin mir ziemlich sicher es irgendwo hier schon mal gelesen zu haben, aber ein Kommentar in der Spezifikation wäre nicht schlecht.

Gruß
GeoCounter

Netzwolf · 2010-12-16T00:38:33.000Z

Nahmd,

GeoCounter:

Mir ist gerade aufgefallen, dass du die Spezifikation noch einmal überarbeitet hast.

Die Bezeichnungen und besonders die farbliche Absetzung erleichten das Verstehen ungemein (wobei ganz am Anfang <calendar_ranges> auch noch rot sein könnte - oder wird es dann optisch zu dominant?)

Ich hab das Ergebnis der Diskussionen eingearbeitet: Syntax und Semantik sind bei Erhalt aller Ausdrucksmöglichkeiten soweit vereinfacht, dass ich mir jetzt eine Rohform der Dokumentation zutraue und die als nächstes angehe. Ich hoffe, dass danach jemand anders den Feinschliff und Layout übernimmt.

GeoCounter:

Das “||” soll (wenn ich es richtig verstehe) das “+” ersetzen und ver-oder-t die Regeln?
“off” bezieht sich auf den kompletten Wochentag, “closed” dagegen nur auf Uhrzeiten - wäre es da nicht sinnvoller beides zuzulassen?
Was soll “/” bedeuten? Ich bin mir ziemlich sicher es irgendwo hier schon mal gelesen zu haben, aber ein Kommentar in der Spezifikation wäre nicht schlecht.

Danke für den Hinweis, das hatte ich übersehen zu spezifizieren.
Erklärung ist jetzt in den Vorspann der Syntax aufgenommen.

Die logischen Gründe für die Änderungen nehme ich in die Doku auf.

Gruß Wolf

GeoCounter · 2010-12-16T01:02:42.000Z

Danke!
Mir ist noch ein kleiner Fehler in der Auswertung aufgefallen:


Feb 29: 00:00-24:00

führt am 01.03.2010 zu “true”.

Gruß GeoCounter

Fabi2 · 2010-12-16T01:39:15.000Z

Netzwolf:

In der Diskussion tauchte das “!” als Not-Operator auf.
Gemeint war aber offensichtlich ein “Kurzschluß-Oder”.
Ich habe versuchsweise “||” eingeführt:
man tippt es nicht “aus Versehen”, es zeigt typografisch sehr gut die Zäsur,
und jeder Programmierer versteht die Bedeutung sofort.

Das ist gut das das weg ist, da hatte ich das Schema auch noch nicht verstanden, selbst jetzt bin ich mir da ja noch nicht wirklich sicher (muß ich noch nen bißchen ansehen, weil wenn die Regeln an sich in sich abgeschlossen sind und die letzte passende, oder aber von hinten betrachtet erst passende, gewinnt, wozu brauch ich dann noch das “oder/‘||’”?). Wichtig ist nur, daß die Symbole wenigstens für Teile der Benutzer halbwegs eingängig oder bekannt sind. Und das “||” kennen sicher genau so viele Leute wie die an z.B. “50+” angelehnte Notation für 18:00+.

Netzwolf · 2010-12-16T02:25:58.000Z

Nahmd,

GeoCounter:

Mir ist noch ein kleiner Fehler in der Auswertung aufgefallen:
Feb 29: 00:00-24:00
führt am 01.03.2010 zu “true”.

Ich prüfe das Tagesdatum nicht: auch der “Apr 31” liefert am 1. Mai ein “true”.

Die jetzige Implementation benutzt: 29.Feb = 1 Tag nach dem 28. Feb. in Normaljahren und in Schaltjahren.

Wie würdest Du in Normaljahren auswerten wollen:
Feb 29
Feb 27-Feb 29
Feb 29-Mar 2

Gruß Wolf

GeoCounter · 2010-12-16T18:52:17.000Z

Netzwolf:

Wie würdest Du in Normaljahren auswerten wollen:
Feb 29
Feb 27-Feb 29
Feb 29-Mar 2

Ich denke, wer den 29.02. explizit verwendet, sollte sich im klaren darüber sein, dass es ihn nur ca. alle 4 Jahre gibt (einen Hinweis könnte das Script auswerfen). Eine automatische Verschiebung auf den 01.03. in Normaljahren halte ich für falsch und macht eigentlich nur in dem 3. genannten Fall Sinn.
Als Lösung würde ich vorschlagen alle drei Varianten nur in Schaltjahren auszuwerten und den Parser einen deutlichen Hinweis darauf ausgeben zu lassen.

Wenn man den letzten Tag des Februars meint, kann man ja auf


Mar 1 -1 days

zurückgreifen.

Gruß GeoCounter

PS.: Für meine ständigen Korinthenkackereien bitte ich um Entschuldigung

Netzwolf · 2010-12-16T23:47:36.000Z

Nahmd,

GeoCounter:

Ich denke, wer den 29.02. explizit verwendet, sollte sich im klaren darüber sein, dass es ihn nur ca. alle 4 Jahre gibt (einen Hinweis könnte das Script auswerfen).

Das war der Hinweis, den ich gebraucht habe.

Ab jetzt ist “Feb 29” nur zulässig, wenn ein Jahr angegeben wird.
“Feb 29” → Fehler
“2012 Feb 29” → Ok

GeoCounter:

Eine automatische Verschiebung auf den 01.03. in Normaljahren halte ich für falsch und macht eigentlich nur in dem 3. genannten Fall Sinn.
Als Lösung würde ich vorschlagen alle drei Varianten nur in Schaltjahren auszuwerten und den Parser einen deutlichen Hinweis darauf ausgeben zu lassen.

Das ist keine explizite Programmierung, sondern das "monat [d+1] ist ein Tag nach “monat d” ergibt sich zwanglos, wenn man auf die Überprüfung der Tagesnummer verzichtet. Überprüfung ist nachgerüstet. Damit:
“Feb 29” → Fehler
“2010 Feb 29” → Fehler
“2012 Feb 29” → Ok

GeoCounter:

Wenn man den letzten Tag des Februars meint, kann man ja auf
Mar 1 -1 days
zurückgreifen.

Bisher ging auch “Mar 0”, aber auch das habe ich jetzt abgefangen.

GeoCounter:

PS.: Für meine ständigen Korinthenkackereien bitte ich um Entschuldigung

Hey! Ich bitte geradezu darum!
Genau dafür ich das Testformular gebaut

Gruß Wolf

GeoCounter · 2010-12-17T00:14:12.000Z

Netzwolf:

Ab jetzt ist “Feb 29” nur zulässig, wenn ein Jahr angegeben wird.
“Feb 29” → Fehler
“2012 Feb 29” → Ok

Finde ich gut, es ist wohl zumutbar diese seltene Öffnungszeit alle 4 Jahren anzupassen (so sie dann überhaupt noch aktuell ist).

Gruß GeoCounter

Fabi2 · 2011-01-29T22:50:03.000Z

Der opening_hours-Parser hat doch noch einen Bug:
http://www.netzwolf.info/kartografie/osm/time_domain/map_opening?filter=error&zoom=13&lat=52.15022&lon=11.63562&layers=B00T

Bei
opening_hours=We 17:00-18:45; “nur jeden 2ten Mittwoch im Monat”

Gibt es den Fehler: Missing space at 2ten

yxcvbnm · 2011-12-26T17:03:53.000Z

Guten Abend, ich finde die opening_hours Karte super. Gibt es eine Möglichkeit für Nicht-Programierer die angezeigten Kringel zu reduzieren, um sich z.B. an einem Sonntag nur alle Bäcker anzeigen zu lassen?

viw · 2011-12-26T19:14:00.000Z

natürlich! Diese Kringel beruhen aufei, einer CSV Datei welche aus einer XAPI Anfrage erstellt wird. Statt dort nur nach openinghours zu filtern könnte die Anfrage auch nach openning hours und Bäckern filtern.

aighes · 2011-12-26T21:35:07.000Z

Das ist richtig, aber die csv-Datei ist in der Karte fest verdrahtet…

yxcvbnm · 2011-12-28T17:32:16.000Z

Ok, ich hatte gehofft man könnte mit der Url rumtricksen, damit nur einzelne Themen angezeigt werden.
Die CSV Datei hab ich mir angesehen und auf meine Vorstellungen reduziert, dadurch komme ich zu einer Textdatei.txt die mir bei dem einfachsten Overlay-Beispiel weiter hilft. Schöner Überblick zur Umgebung, aber die Öffnungszeiten sind futsch.

Ich denke da muß ein Programierer ran, der uns Schritt für Schritt erklärt, wie man eine Sonntagsbrötchen Map bastelt.
Dann kommt das Partygirl und bastelt sich eine Discokarte nach und ein Schrotti macht sich ne Karte mit den Öffnungszeiten der Metallhändler.
Ich wäre begeistert, wenn es so kommen würde. Und die große Mühe vom Netzwolf würde viele Früchte tragen.

viw · 2011-12-28T19:11:18.000Z

Naja dann hast du doch die hauptarbeit schon gemacht. Jetzt bleibt nur noch die übrigen Dateien herunterzuladen und auf einem eigenen Server oder gar nur im eigenen Browser aufzurufen. Dabei muss die URl für die CSV datei angepass werden, aber Netzwolf hat die Dateien im allgemeinen sehr gut kommentiert, so dass dies kein Problem sein sollte.