Öffungszeiten [2]

Bei den Korrekturen der Öffnungszeiten (natürlich über Netzwolf-Karte, klasse Arbeit) sind mir noch zwei Problemkreise aufgefallen, zudem ich gerne Eure Meinung zur Notation hätte:

  1. Termine nach Vereinbarung (mit Zeiten We 14:00-18:00 oder auch ohne Zeiten)

  2. Führungszeiten statt Öffnungszeiten, aber collection_times wäre wohl genauso falsch

MfG Georg V. [OSM=user_5359]

Moin,

Dieses “Problem” ist kein Problem, sondern Bestandteil der Realität, sogar ein häufiger. Ich habe das so abgebildet, dass die Auswertungsroutine vier verschiedene Werte liefern kann:

  • true (offen)
  • false (geschlossen)
  • string “Hinweistext”
  • null (unbekannt, z.B. bei Syntaxfehlern)

Den Hinweistext kann man am Ende jeder Rule (“Rules” sind für mich die durch “;” getrennten Konstrukte) angeben:

Unter dem Auswerteformular http://www.netzwolf.info/kartografie/osm/opening_hours/#examples findest Du diese Beispiele. Anklicken übernimmt ins Formular, und das Ergebnis wird bei jeder Änderung der Zeitangaben neu ausgewertet.

Während “opening_hours” auf viele Objekte anwendbar ist, Läden, Arztpraxen, Schwimmbäder, Spielplätze und Parks (da braucht man das -sunset), aber auch Recycling-Container (Einwurfzeiten), passt der Name “collection_time” nur auf wenige Arten von Objekten – das Konzept dagegen auf viele. Der Name erscheint mir unglücklich gewählt.

Schlauer wäre möglicherweise ein “*:times”. Das ließe sich dann so nutzen:

aber auch so:

Gruß Wolf

Hallo Wolf,
da du ja hier einen Quasi-Standard schaffst, wäre es evtl. sinnvoll das ganze auch auf den entsprechneden Seiten im Wiki zu dokumnetieren.

das hab ich mich vorhin auch gefragt: “was machen denn die anderen”?
hier wird das tagging von opening_hours bis auf das letzte aufgebohrt, damit man eingeben kann, dass dieser laden ostermontag von 23:00-00:15 auf hat, aber nur wenn es dienstag ist und die verkäuferin nicht schwanger ist.

wer soll das - ausser mit genau diesem tool - vernünftig darstellen?
klar, es gibt die quellen vom validator aber was ist mit den anwendungen, die es sonst so gibt?
ich denke da gerade an die vielen navi-kästchen oder handies - was ist mit denen?
gibt es inzwischen ein proposal oder irgendwas auf wiki, was die ganze sache mal präsentiert?
da ist wohl noch einiges zu tun.

ich halte mich weiterhin an das, was im wiki steht, weil das eine basis ist, auf der auch andere anwendungsprogrammierer aufbauen können.

die auswertung, die ich weiterhin als QA-Instrument sehe, halte ich für sehr hilfreich aber ich möchte nicht schon wieder eine neue spezialkarte aufrufen müssen, blos damit die öffnungszeiten auch “vernünftig” dargestellt werden.
abgesehen davon, dass ich einige technische bedenken zu der art und weise der datenaktualisierung habe - aber das wäre ein andere thema.

lg
walter

Ich denke, die Karte ist vor allem eine Testumgebung, um das Schema so auszubauen, dass es möglichst allgemeingültig ist und zugleich zu zeigen, wie es maschinell auswertbar ist. Wenn so neue, funktionierende Wege gefunden werden, sollten die natürlich über das Wiki allen zugänglich gemacht werden - vor allem auch der Aufbau des Auswertungsalgorithmus. Und dann kann jeder Anwendungsentwickler den auch implementieren und so eine vernünftige Darstellung in jeder Umgebung ermöglichen.

Das Problem was ich da hatte, war eher, ob der Text mit in den Kontext der Regel fällt oder nicht. Weil nach deinem Schema müßte man ja eigentlich Sachen wie:

Mo-We 8:00-16:00;Th off;Fr 8:00-12:00**;** “und nach Vereinbarung”
schreiben anstatt nur:
Mo-We 8:00-16:00;Th off;Fr 8:00-12:00 “und nach Vereinbarung”

weil das wäre ja: “nur Freintags zusätzlich auch nach Vereinbarung” anstatt dem eigentlich gemeinten “und außerhalb der Öffnungszeiten auch nach Vereinbarung”.

In dem Falll wäre das sinnvoll, solange bis dann irgend jemand mal auf die Idee kommt, Sachen wie building:room=* für die Raumnutzung zu machen und man dann später gerne auch die Räume in office=* taggen können möchte. :wink:

Verlinkt hat es ja der Wolf schon und er schreibt da bestimmt auch noch eine Beschreibung und einen Anwendungsfall pro Regele rein, damit auch Leute, wie wohl eher die meisten, die mit der Spezifikation nichts anzufangen wissen, die Zusatzregeln benutzen können. Sinnvoll und abwärtskompatibel sind die Erweiterungen ja alle die muß man nur noch für Ottonormalmapper dokumentieren und die Leute die dann evtl. noch angejammert kommen hierher verweisen.

na ja, mir ging es hier nicht um Otto Normalmapper sondern um das andere Ende der Fahnenstange: die Anwendungen und deren arme Programierer.
Die finden eventuell auf einmal massig neue “komische” tags vor, die sie wohl erst mal ignorieren werden.

Mahlzeit!

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” :slight_smile:

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.

Gruß Wolf

Nahmd,

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.

Gruß Wolf

Nahmd,

Einfache Regel: der text wirk genau wie das “off”.

Das schreibt man es so:

Sofern der Betroffene nicht wirklich 0:00-24:00 meint :slight_smile:

Gruß Wolf

Nahmd,

Ja. Und genau das gleiche machen sie auch, wenn sie ein “von Frühlingsanfang bis Totensonntag” finden.
Ich sehe da keinen Nachteil.

Gruß Wolf

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”

Nahmd,

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.

Gruß Wolf

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.

Nahmd,

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.

Gruß Wolf

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 :wink:

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:

Mo,We-Th 8:00-12:00,13:00-17:00

Nahmd,

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.

Hallo,

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.