Anzeige und Auswertung von "opening_hours"

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.

Netzwolf · 2012-01-02T13:52:28.000Z

Guten Morgen,

yxcvbnm:

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?

Aber selbstverständlich.

Das JavaScript holt die POIs von einem Server ab. Und das Skript, welches dort läuft, kann über die URL mit Restriktionen versehen werden. Für Dich:

http://www.netzwolf.info/kartografie/osm/time_domain/map_opening?shop.seq=bakery

Mehr Treffer liefert:

http://www.netzwolf.info/kartografie/osm/time_domain/map_opening?amenity.seq=fuel

Die Bedingungen haben die Form:

{tag}.{operator}={wert}

Dabei steht das “seq” für “String equal”. Zahlenfelder werden mit “eq” verglichen, weil sonst 10 kleiner wäre als 2. Natürlich funktionieren auch “ne”, “lt”, “le”, “gt” und “ge” mit und ohne “s” davor.

Sucht man Bäcker und Metzger, so nutzt man:

shop.isin=bakery,butcher

Die Abfrage

shop.eq=bakery

fragt auf exakte Gleichheit ab, findet zwar “shop=bakery”, aber nicht “shop=bakery;kiosk”. Dafür nutzt man:

shop.smatches=bakery

Es gibt noch weitere Operatoren, die man dem Source von csv.phtml entnehmen kann. Das ist selbstdokumentierend. Bei größerem Interesse kann ich auch eine Doku dazu erstellen.

Man kann beliebig viele Bedingungen benutzen, diese werden dann “and” verknüpft.

Ich hoffe, das hilft Dir weiter.

Gruß Wolf

Netzwolf · 2012-01-02T13:56:44.000Z

Moins,

yxcvbnm:

Ok, ich hatte gehofft man könnte mit der Url rumtricksen, damit nur einzelne Themen angezeigt werden.

Kann man.

Ich denke da muß ein Programierer ran, der uns Schritt für Schritt erklärt, wie man eine Sonntagsbrötchen Map bastelt.

Viel programmieren muss man nicht, die Komponenten sind da und warten nur auf das zusammengeklebt werden.

Dann kommt das Partygirl und bastelt sich eine Discokarte nach und ein Schrotti macht sich ne Karte mit den Öffnungszeiten der Metallhändler.

Solange nicht die Satanisten kommen und sich eine Karte mit Getränkeshops, Tierheimen und Friedhöfen bauen…

Gruß Wolf

Netzwolf · 2012-01-02T14:02:15.000Z

Moins,

aighes:

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

Aber sowohl Seite als auch die benutzen Skripte sind allgemein einseh- und abrufbar.
Auch das csv.phtml, das auf dem Server die Filterung übernimmt.

Soll ich das vielleicht mal als ZIP zusammenstellen so wie für die Stolpersteine?

Bitte auch eines nicht übersehen: ein JavaScript kann sich nur mit dem Server verbinden, von dem es geladen wurde. Es gibt ein Konzept, um diese Beschränkung zu lockern (der Zielserver wird gefragt, ob er Fremdzugriffe zulässt), ohne dabei die Sicherheit zu beeinträchtigen, ich weiß aber nicht, inwieweit die Browser das schon unterstützen.

Gruß Wolf

yxcvbnm · 2012-01-11T21:26:37.000Z

Danke an alle und besonders an Netzwolf für die Antworten.

Die Möglichkeit mit den Restriktionen der Url ist genau was ich mir erhofft hatte. Klasse.
Da ergeben sich ja fast unendlich viele Möglichkeiten die brauchbare Themen-Karten ergeben.

Ich taste mich gerade durch verschiedene einfache Kombinationen der Restriktionen durch.
Dabei gehe ich wie folgt vor:

Ich öffne die Url mit Restriktionen und zoome mich auf große Städte zu den Kringeln.
Dann ein Klick auf Permalink, um das Gebiet und die Zoomstufe beim neuladen nicht zu verlieren.
Ab hier beginnt meine bastelei und für mich zu auch ganz neue Fragen.

1.) Ich bin nie ganz sicher, ob ich wirklich alle abgefragten POI angezeigt bekomme, denn

Amsterdam hat doch mehr als zehn Tankstellen mit opening_hours,oder?

http://www.netzwolf.info/kartografie/osm/time_domain/map_opening?amenity.seq=fuel&zoom=11&lat=52.38323&lon=4.90254&layers=B00T

2.) Die Kombination shop.isin=bakery,butcher will mich zancken, schaut hier:

http://www.netzwolf.info/kartografie/osm/time_domain/map_opening?shop.isin=bakery,butcher&zoom=11&lat=50.61993&lon=7.91074&layers=B00T

Trotz Einschränkung auf bakery und butcher wird alles(!) angezeigt.

Netzwolf · 2012-01-13T00:41:10.000Z

Nahmd,

yxcvbnm:

Die Möglichkeit mit den Restriktionen der Url ist genau was ich mir erhofft hatte. Klasse.
Da ergeben sich ja fast unendlich viele Möglichkeiten die brauchbare Themen-Karten ergeben.

http://www.netzwolf.info/geocaching/karten/form

.oO( everything worth doing is worth overdoing … )

yxcvbnm:

1.) Ich bin nie ganz sicher, ob ich wirklich alle abgefragten POI angezeigt bekomme, denn
Amsterdam hat doch mehr als zehn Tankstellen mit opening_hours,oder?
http://www.netzwolf.info/kartografie/osm/time_domain/map_opening?amenity.seq=fuel&zoom=11&lat=52.38323&lon=4.90254&layers=B00T

Ich hole nur DE, AT und CH ab:


<osm-script>
<query type="node">
<has-kv k="opening_hours"/>
<bbox-query s="45.8" n="55.1" w="5.8" e="17.2"/>
</query>
<print/>
</osm-script>

Außerdem zur Zeit auch nur Punktfeatures, keine Ways oder Relationen.
Bei letzteren wirft der OVP leider zuverlässig einen Timeout

yxcvbnm:

2.) Die Kombination shop.isin=bakery,butcher will mich zanken, schaut hier:
http://www.netzwolf.info/kartografie/osm/time_domain/map_opening?shop.isin=bakery,butcher&zoom=11&lat=50.61993&lon=7.91074&layers=B00T
Trotz Einschränkung auf bakery und butcher wird alles(!) angezeigt.

Wenn da nur die Metzger nicht aufgetaucht wären, hätte ich versucht, das einer fundamentalistischen Veganerorganisation in die Schuhe zu schieben.
Aber so … ok, dann muss ich das unerwartete Leistungsmerkmal wohl abstellen:

http://www.netzwolf.info/kartografie/osm/time_domain/map_opening?shop.isin=bakery,butcher&zoom=13&lat=50.79918&lon=7.59875

(×) done

Gruß Wolf

lovwyr · 2012-06-03T21:14:09.000Z

Moin,

mal eine fachfrage, wie könnte man unterschiedliche Öffnungszeiten verschiedener “Abteilungen” in einen Geschäft taggen?
Autohäuser sind hier ein gutes beispiel der Service hat z.b von 6-21 auf wärend der verkauf nur von 8-18 auf hat. Wäre opening_hours:service=06:00-21:00 & opening_hours:sales=08:00-18:00 ein gangbarer weg?

Netzwolf · 2012-06-03T21:29:08.000Z

Nahmd,

lovwyr:

Autohäuser sind hier ein gutes beispiel der Service hat z.b von 6-21 auf wärend der verkauf nur von 8-18 auf hat.

Die Situation ist ähnlich zum Gastronomiebetrieb mit warmer Küche nur von 12-14 Uhr. Eine Möglichkeit der Codierung ist:


Mo-Sa 06:00-21:00 open "Verkauf nur von 8 bis 18 Uhr"

Damit hast Du eine Chance, dass die von Dir erfassten Daten auch genutzt werden.

Gruß Wolf