Ja ja, wer arbeitet, darf als Dank – noch mehr arbeiten.
Hmpf!
Aber im Ernst:
die formale Spezifikation drückt das aus, was mein Skript verarbeiten kann. Das muss nicht mit der “offiziellen” Spezifikation übereinstimmen. Und es ist in einem Wiki nicht wirklich gut aufgehoben, alldieweil nur der das ändern soll, der auch an dem Skript arbeitet. Hier gilt “Text follows Function”
Ich werde die Spezifikation noch aus Informatik nach Deutsch übersetzen.
Eine Entscheidung über die Aufnahme der Erweiterungen in die Spezifikation im Wiki und die Änderung im Wiki überlasse ich anderen. Diejenigen dürfen gerne meine Seite ausschlachten; ich habe soeben ein CC_BY-SA darunter gesetzt.
Ich habe nur sehr behutsam erweitert unter Beachtung vollständiger Kompatibilität mit den Beispielen aus dem Wiki und einer vernünftigen Parsebarkeit – deshalb zuerst die Grammatik und dann die Implementation.
Die Frage ist: was sollen diejenigen machen, deren Öffnungszeiten sich nicht mit den Beispielen aus dem Wiki ausdrücken lassen?
Wenn sie diese dann als Text eingeben, scheitert ein Auswertetool, das sich an den Beispielen aus dem Wiki orientiert.
Wenn sie diese in der erweiterten Notation eingeben, scheitert ein Auswertetool, das sich an den Beispielen aus dem Wiki orientiert.
Also wo ist der Nachteil, wenn sie die Daten formal angeben?
Das JavaScript ist frei, und ein Perl und ein PHP werde ich noch nachliefern – allerdings erst, wenn eine gewisse Zeit keine Rückmeldungen mehr kommen, dass irgendetwas nicht ausdrückbar ist. Für eine Version in “C” oder “C++” müsste man mich aber mit Gummibären bestechen.
Welche Geräte werten zur Zeit dieses Tag aus?
In der Tat. Als nächstes übersetze ich die formale Spezifikation in lesbares Deutsch.
Das mag dann jemand als Basis für eine Abstimmung über eine brauchbare Sprachmenge nutzen, oder auch nicht.
Das tu ich auch. Denn die Beispiele aus dem Wiki sind ein Subset der von der erweiterten Grammatik abgedeckten Fälle.
Alles was sich innerhalb ausdrücken lässt, sollte man auch innerhalb ausdrücken.
Das was sich aber nicht innerhalb ausdrücken lässt …
Das Auswertescript liegt bereit zum Download und ist wirklich trivial aufzurufen. Einfach mit dem Wert des Tags füttern, und des greift sich per new Date() die aktuelle Zeit ab und liefert den Öffnungsstatus zurück. Alternativ kann man es auch mit den Einzelkomponenten von Datum und Zeit füllen - damit ist das Online-Testformular gebaut.
Du bist herzlich eingeladen, eine eigene Seite zur Anzeige und Überprüfung von Öffnungszeiten einzurichten. Da Du einen schnellen und aktuellen Feed hast, wäre die deutlich nützlicher, und ich würde meine Karten sofort entfernen und zu Dir umleiten. Sag, wenn Du soweit bist.
Genau das “außerhalb der Öffnungszeiten auch nach Vereinbarung” ist doch damit gemeint, weil zu den Öffnungszeiten muß ich ja nichts vereinbaren, da geh’ ich einfach hin.
Also doch:
Mo-We 8:00-16:00; Th off; Fr 8:00-12:00; Fr 12:00-18:00; “und nach Vereinbarung”; “and on appointment”
Ja! Und ich wäre froh, wenn jemand die Karten übernimmt, weil mein kleiner Spielzeug-Server dafür nicht wirklich geeignet ist. Und weil ich ich keinen eigenen Geodatenfeed habe, also auf die veralteten XAPI-Daten zurückgreife. Und. Und. Und. Freiwillige vor!
Das habe ich bereits begonnen. Es gibt eine formale Grammatik. Die Auswertung ist für die kritischen Regeln darunter erklärt. Es fehlt noch die Übersetzung des ganzen in lesbare Sprace – wobei ich mich aber zum Programmieren an die formale Beschreibung halten würde. Das darf dann gerne als Ausgangsmaterial für eine Überarbeitung des Wiki benutzt werden.
Vielleicht fragst du mal bei den dev-Server-Leuten, nachdem die Tagwatch irgendwann abgeschaltet haben nach, weil das macht da wohl die meiste Last. Die XAPI ist nicht wirklich alt, irgendwo stand im WEiki, das die nur so ca. 10 min hinter der offiziellen DB hinterherhinkt. Schneller sind da bestenfalls nur die Leute, die direkt ständig jeden Minuten-diff downloaden und einspielen.
Ich hatte ausgedrückt: “Freitags von 12-18Uhr nach Vereinbarung”. Wenn “nach Vereinbarung” sich auf ALLE Zeiträume außerhalb der Öffnungszeiten beziehen soll: das kann man zur Zeit noch nicht ausdrücken. Denn: nach den Wiki-Vorgaben (von mir übernommen) zählt die letzte anwendbare Regel. Zur Erklärung:
Sep ← September ganztägig
Fr ← jeden Freitag ganztägig
Sep Fr 20:00-22:00 ← Freitag im September von 20-22 Uhr
20:00-22:00 ← Jeden Tag von 20-22 Uhr
Was man da sieht: Bedingungen, die fehlen, werden zu TRUE ausgewertet.
Also:
keine Uhrzeit → Zeitbedingung immer TRUE
kein Datumsbereich → Datumsbedingung immer TRUE
keine Tagesmaske → Tagesbedingung immer TRUE
Aus dem allen zusammen ergibt sich:
Überhaupt keine Angaben → immer True.
(Dieser Fall kommt in den Wikiangaben nicht vor, die Auswertung zu True ergibt sich aber aus der Logik)
Bei der Schreibweise »………; “und nach Vereinbarung”« hat diese letzte Regel keine Bedingung, würde also alles davor überschreiben. Das ist nicht das, was man wünscht. Oder anders ausgedrückt: diese Schreibweise bedeutet “Nach Vereinbarung!!!” und nicht wie gewünscht “und nach Vereinbarung”. Das ergibt sich zwingend aus den Grundregeln. Zur Zeit lässt sich diese Konstellation leider nicht ausdrücken.
Möglicherweise kann man eine Regel dafür behutsam erweitern. Ich guck mir das mal an.
auch nabend,
danke für die ausführlichen kommentare zu meinem post.
ich fasse mal -für mich- zusammen: “das teil kann viel und mehr als alles andere, was es derzeit gibt; ihr könnt es gerne ausschlachten. und mit etwas glück fliesst auch was ins wiki ein”
zum thema “technik”:
ne eigene opening_times-karte oder sowas ähnliches hab ich nicht vor. ich würd mich nur richtig freuen, wenn das in andere karten und auch “kästchen” integriert wird.
und beim öpnv (ja, hab ich auch mal angefangen) halte ich mich zurück, da die profis(aka steve) sich drum kümmern.
ausserdem ist “mein” server aus kostengründen nicht 24/7/… aktiv.
zu dem “aktuellen feed” bin ich nur gekommen, da ich das nach verschiedenen versuchen das als die -für mich- beste lösung erachte.
a) download planet oder extrakt; danach scannen mit perl-scripten : extrem-lahm
b) download planet und anschließendes einspielen von osc-files, perl: lahm
c) aufbau postgresql-db und pflege mit osm2pgsql: ok, blos immer dann, wenn ich was bestimmtes brauchte, war’s nicht drin.
d) postgresql im simple-schema mit osmosis + minute-updates: prima, doch schwer auszuwerten, da kein hstore da war.
e) postgresql+postgis+osmosis 0.37ff + minute-updates: das isses! die aktuellen daten strömen in mein kämmerlein und können klasse ausgewertet werden.
(z.b. ein “oberförster-trigger” war nach 30 minuten aktiv)
f) mal sehen, was da so kommt
gruss
walter
p.s. a-e haben ca 6 monate gebraucht - allerdings nicht fulltime
Doch, sollte gehen, aber das ist weder kurz noch anwenderfreundlich (obwohl, kann man mit … bestimmt noch optiimieren; ist mehr nach altem Schema):
Mo-We 8:00-16:00;Th off “und nach Vereinbarung”; Fr 8:00-12:00; Fr 12:00-18:00; Fr 18:00+ “und nach Vereinbarung”; Sa-Su off “und nach Vereinbarung”; Mo 0:00-8:00 “und nach Vereinbarung”
Ein Negationsoperator wie “!” wäre da aber echt praktischer.
Mo-We 8:00-16:00; Th off; Fr 8:00-12:00; Fr 12:00-18:00; ! “und nach Vereinbarung”
bzw.
Mo-We 8:00-16:00; Th off; Fr 8:00-12:00; Fr 12:00-18:00 ! “und nach Vereinbarung”
Ja, das ist da nicht spezifiziert, genau so wenig, wie die sinnvolle Umsetzung von dir, das die “off” Zeiten Vorrang vor den Öffnungszeiten haben sollten.
Weil
Mo-Fr 8:00-18:00; We off
schreibt sich schneller als
Mo-Tu 8:00-18:00; We off, Th-Fr 8:00-18:00
wobei man sich das We off, im zweiten Fall nachtürlich schneken kann.
Außerdem habe ich noch solche Sachen beim Korrigieren gesehen:
Nach etwas Grübeln habe ich eine kleine, aber feine Ergänzung gefunden:
Du kannst vor eine Rule ein “+” schreiben - das steht für “und außerdem”. Formal: ist das Zwischenergebnis der Vorgängerrules “TRUE”, wird diese Rule übersprungen.
Das braucht nur eine triviale Ergänzung der Grammatik (ein “[ “+” ]” am Anfang der Produktion zu ), und weniger als zehn Zeilen Code. Ist bereits eingebaut und darf ausprobiert werden: http://www.netzwolf.info/kartografie/osm/opening_hours/#examples (Beispiele 12 bis 14)
Diese Schreibweise ist auch hilfreich für das “am Vormittag offen, Mittwoch auch Nachmittags”.
In der Realität wird das häufig so geschrieben “Mo-Fr 08:00-12:00; We 15:00-18:00”, und dann ist Mittwoch vormittags geschlossen (bitte nicht mich schlagen, das ist Wiki-Vorgabe). Diese Situation aus der Realität kann man jetzt intuitiv so abbilden: “Mo-Fr 08:00-12:00; + We 15:00-18:00”.
Ich hoffe, es gefällt.
Gruß Wolf
Nachtrag zur Erkärung:
Ich sehe das “und nach Vereinbarung” nicht als Zeitangabe – die Zeitangabe erfolgt außerhalb, denn insbesondere soll “nach Vereinbarung” ja auf bestimmte zeitbereiche begrenz werden können – sondern als alternativer Ergebniswert neben “open” und “closed”.
Beispiel (Club)
Th-Sa 21:00-03:00; Sa 22:00-03:00 “Krawattenzwang”
Oder (Schwimmbad):
Mo-Fr 08:00-12:00, 15:00-18:00; Sa 10:00-14:00 "nur bei gutem Wetter; We 15:00-18:00 “freier Eintritt”; Th 08:00-09:00 “Damenschwimmen”
Oder (Berghütte, die irgendwann im Juni öffnet und irgendwann im Oktober schließt):
Jun-Oct “Ist von Mitte Juni bis Mitte Oktober geöffnet, genauen Termin bitte nachfragen”; Jul-Sep 00:00-24:00
So bekommt man ein “open”, wenn sicher offen, ein “close”, wenn sicher zu, und ein “Ansagetext” für die Fälle, bei denen man sich verabreden muss, die Sache vom Wetter abhängt, man keine genauen Angaben hat oder die Angabe nicht alle Nas lang korrigieren will, oder wenn das “open” von Merkmalen des Besuchers abhängt. Mit einer sehr einfachen syntaktischen Kostruktion kann man sehr viele Fälle der realität abdecken.
was einen Server 24/7 angeht, so wäre eventuell ein Angebot von bplaced.net interessant. Dort gibt es eine Postgisdatenbank und einen Webspace von 2 GB je Account. Bei Bedarf sind mehrere möglich. Ich würde mich auch bereit erklären einen solchen Account anzulegen. Derzeit besitze ich schon einen zu Testzwecken.
Es ist nur die Frage ob man das vernünftig exportieren könnte. Mein Problem ist ja immer noch die Datenbank.
Was da aus meiner Sicht gebraucht wird, ist kein zweiter “und”-Operator, weil wenn ich “und außerdem” machen will, kann ich ja schon ; machen, sondern eine Negation:
“(am Freitag|immer) außerhalb der Öffnungszeiten auch nach Vereinbarung”. Das “und” hast du doch schon dadurch, das der Zusatztext ja schon mit der Regel “und”-verknüpft ist.
Ich bilde auf möglichst einfache Weise die Wünsche aus der OSM-Gemeinde in eine formale Grammatik ab und implementiere die dann auch. Soll ich mich dafür entschuldigen?
Natürlich kann man sich so über Open-Source äußern. Ich bevorzuge allerdings eine etwas respektvollere Sprache.
Du kannst dem Glück auf die Sprünge helfen. Ich hab die Seite bereits auf CC-B-SA gesetzt.
Also immer frisch ans Werk …
Lies Dir bitte die Beschreibung im Wiki einmal durch: die letzte passende Regel entscheidet. Das wirkt nur dann als Oder, wenn die Regeln sich auf unterschiedliche Tage beziehen, die Gültigkeitsbereiche also paarweise disjunkt sind.
Beispiel: “Mo-Fr 08:00-12:00; We 15:00-18:00” ← Mittwoch vormittag ist geschlossen, weil die zweite Regel den Mittwoch in der ersten vollständig überschreibt.
Genau das drückt das “+” doch zwanglos aus: diese Regel überschreibt nicht, diese Regel ergänzt.
danke für die info aber bei der db wird’s wirklich kritisch.
die meinige ist ca 60 giga-breit und manche queries machen bestimmt den stärksten server platt. und da genau achten die sehr drauf.
lg
walter
Sehr schön, wir stimmen bezüglich der Nutzung zu 100% überein. Einzig in der Syntax für den zweiten Fall unterscheiden wir uns: Du bevorzugst das ‘!’ statt des ‘+’. Ich hab das ‘!’ eben in die Grammatik und das Skript aufgenommen:
sorry für den Ausrutscher; ist eigentlich auch nicht mein Stil
womit ich bei deiner Karte noch ein richtiges Problem habe, ist die Frage der Datenaktualisierung.
ich hab am freitag folgenden briefkasten, den ich irgendwann mal mit “opening_hours” erfasst hatte, erfolgreich in osm korrigiert. http://www.openstreetmap.org/browse/node/976213720
seid dem versuchte ich mehrfach durch verschiedene verfahren (einfach warten, shift reload, aktualisieren!-button) das ergebnis (kein briefkasten von mir in deiner auswertung) zu erreichen.
leider ohne erfolg.
(und das ist letztendlich der grund, weswegen ich mich etwas intensiver damit beschäftigt hatte).
gruss
walter
Manchmal wird die Realität in Datenbestand halt zu einem Problem, wenn man den in Wiki notierten Standard einhalten will.
Deine Notationserweiterung der Form “nach Vereinbarung” hat zudem ein massives Problem: Es läßt eine starke Varianz zu und müßte zudem nach den anerkannten Regeln auf englisch sein. Ich würde hier eher ein opening_hours:appointment sehen [Vorsicht, ich bin kein Muttersprachler!].
Dein Vorschlag zu den Führungszeiten halte ich für sehr sinnvoll. Nur das auf der Wiki-Seite bereits ein Tag service_times dokumentiert ist.
An dem PHP-Code wäre ich sehr interessiert (zumal es auch ein Ersatz für den “alten” PHP-Code auf der Wikiseite wäre).
