Öffungszeiten [2]

Das Wiki wird doch auch alle Nase lang von jemanden geändert, also nichts mit “Standard”, das ändern an sich ist ja nicht das Problem, wenn es nicht gegen die bisherige mehrheitlich Verwendung ist, etwa weil z.B. Leute auf die Idee gekommen sind, highway=bus_stop wäre jetzt nur noch für die public_transport=stop_position da (Siehe Diskussionsseite von highway=bus_stop).

…und nach Vereinbarung ist doch klar definiert: das ist immer außerhalb der Öffnungszeit, weil ansonsten erübrigt sich dieser Hinweis.

Und was mach ich bei einer Kirche mit Gottesdiensten, durch die auch Führungen gemacht werden?

Also zwei Zeichen, die das gleiche bedeuten sollen? Halte ich für kritisch, das provoziert geradezu editwars. Ich würde das Plus bevorzugen, es scheint mir für Otto-Normal-Nichtprogrammierer verständlicher zu sein, gerade was so Fälle wie den angesprochenen “Mittwoch Nachmittag zusätzlich geöffnet”-Fall angeht.

Nahmd,

Ich auch. Ich wollte meine Gegenden rotkringelfrei bekommen.
Der XAPI spielt da nicht mit – der wird seit Tagen nicht mehr aktualisiert.

Ich hatte schon angenommen, dass die Aktualisierungfunktion gestört sei, und habe alle zum Projekt gehörigen Dateien gelöscht, also alles frisch bauen lassen – keine Änderung.

Auf den Reload-Knopf habe ich umgestellt, weil ich das Shift-Reload auch nutzen möchte, um gecachete JS-Dateien zu aktualisieren. Das und früher das Shift-Reload stoßen nur den Nachladeprozess an. Du kannst die Kartenseite scrollen, dann siehst Du den Aktualisierungsstand der Daten – und du kannst auch die Rohdaten als CSV runterladen.

Auf den Aktualisierungsstand von XAPI habe ich keinen Einfluss – kann man den irgendwo abfragen?

Gruß Wolf

Hallo Wolf,

welchen XAPI Server verwendest du denn? Als Alternative könnte man ja auch einen anderen Server testen. Ansonsten bliebe noch das umstellen auf eine Postgisdatenbank und dann das füttern mit den Diffs. Vielleicht einfach nur die Daily diffs und dann wird jeden Tag ein neuer Stand rausgelesen.

Nahmd,

Menno!

Ich realisere einen Änderungswunsch – obwohl ich zu dem Punkt eine andere Meinung habe → falsch.
Hätte ich diktatorisch entschieden: “+” ist besser und gut damit → falsch.

Ich nagel jetzt ein Kissen an die Wand und haue den Kopf dagegen.

Gruß Wolf

Ja, das geht einem immer so, wenn man irgendwas macht :stuck_out_tongue: Lass dich nicht davon stören, wir sind trotzdem alle froh um deine Arbeit.

Na, prima! Danke für die Änderung. Aus meiner Sicht ist “!” nach z.B. der C-Syntax so viel eingängiger: als Regelbestandteil heißt das “wenn diese eine Regel nicht gilt” und als globale Notation:
Mo 6:00-14:00; ! “Außerhalb der Öffnungszeiten auch nach Vereinbarung.”, heißt das dann: "außerhalb sämtlicher Öffnungzeiten (also Status=“closed”). Ohne jegliche Ein- oder Auschlußinfo gibts dann nur die Meldung.

Ach ja, das mit dem überschreibendem Verhalten (“last match wins”) war mir nicht gleich klar, ist aber richtig von dir interpretiert und ergibt sich wirklich aus der Syntax für das “off”. Da sollte man unbedingt drauf hinweisen, weil das ist sonst eine Fehlerquelle, weil die meisten Menschen und ich auch erst, davon ausgegangen sind, das sich die regeln addieren und nicht überschreiben.
Da wäre dann

Mo-Fr 8:00-12:00;We 15:00-18:00

eben gerade; “Mittwoch ist zusätzlich auch noch nachmittags auf”. Soll heißen dieses Verhalten provoziert geradezu wieder menschliche Interpretationsfehler.

Wieso ist das falsch? Wollen wir denn echt die 3. Bedutung für das “+” in den opening_hours=* haben?
Bitte laß das auf “!”. Danke!

  1. hinter Uhrzeiten: 22:00+
  2. Mar 25 + 5 days

Edit: gerade nachgesehen: “+” und “!” als Alternative gehen natürlich auch als Kompromiss, ich wollte nur versuchen die Benutzerverirrung zu reduzieren.

Nahmd,

Sorry, da habe ich wohl für Verwirrung gesorgt.

Mir ging es an der Stelle nicht um die exakte Definition der Tags, sondern nur darum, dass wenn Tags der Form “*:times” immer den “Datentyp” <opening_hours_t> haben, man bei einer automatischen prüfung jetzt schon Tags berücksichtigen kann, die noch gar nicht erfunden sind. Ich mag es, Dinge so einfach zu bauen, dass sie für Zwecke genutzt werden, an die ich nie gedacht hätte. Das war also nur ein Gedanke und nichts, worüber zu diskutieren sich lohnte.

Gruß Wolf

von diesen hardgecodeten strings in “opening_hours” halte ich nicht recht viel. was macht ein tourist mit englischen kartenmaterial? dem sagt zB der string “im sommer nach vereinbarung” überhaupt nichts. sowas gehört, wenn schon, in einen tag “description:opening_hours” bzw. “description:opening_hours:en”.

das reine “nach vereinbarung” gibt es ja auch in anderen ländern. da sollte ein englischer fixwert her. beispiele:

“Mo-Fr 09:00-18:00; on_demand” für fixe öffungszeiten + generischen “nach vereinbarung”
“Mo-Th 09:00-18:00; Fr, Sa on_demand” für fixe öffungzeiten zw mo-do und “nach vereinbarung” am freitag und samstag.

Nahmd,

Ich habe osm und ifw ausprobiert – beide keine aktuellen Daten. Warum auch immer.

Der Aufwand erscheint mir als Ersatz für eine banale Abfrage recht hoch.

Kann vielleicht einer derer, die einen Postgis-Server hoher Aktualität haben, mir eine einfache API dranbauen?

Ich suche jeweils nur nach Knoten mit einem bestimmten Tag oder einer bestimmten Tag=Wert-Kombination in einer Bounding-Box. Ich akzeptiere jedes Ergebnisformat, muss kein XML sein. Direkte Ausgabe vom PostgreSql reicht mir schon.

Gruß Wolf

Nein, die Verwirrung habe wohl eher ich verursacht!
Ich wollte eigentlich sagen, daß service_times=* neben Führungen zusätzlich auch schon für Gottesdienstzeiten definiert ist. Soll heißen da sind guidance:times=* bzw. :times= ein deutlich besserer Vorschlag.

Und wie viele Prozent der Menschheit kennen die C-Syntax? Zugegeben, es wäre die dritte Bedeutung für ein +, trotzdem finde ich, kann man’s auseinanderhalten. Alternativ würde ich & vorschlagen: Bisher ungenutzt, eingängig für die Bedeutung “außerdem auch noch”/“und” und auch für C-Programmierer nicht völlig fremd :stuck_out_tongue:

@flaimo: Ganz ohne Strings wird man nicht auskommen, manche Dinge lassen sich einfach nicht ausdrücken. Zustimmung allerdings zu dem Punkt, dass ein fester Wert mit der Bedeutung “nach Vereinbarung” nicht schaden kann.

in der xapi-antwort steht es anscheinend drin, aber es dürfte nicht so einfach sein, dannzukommen.

 <?xml version='1.0' standalone='no'?>
 <osm version='0.6' generator='osmxapi: OSM Extended API' 
  xmlns:osmxapi='http://www.informationfreeway.org/osmxapi/0.6'
  osmxapi:uri='/api/0.6/node[amenity=hospital]'
  osmxapi:planetDate='200803150826'                              <---------------
  osmxapi:copyright='2008 OpenStreetMap contributors' 
  osmxapi:instance='zappy2'>
   <node id='672180' lat='48.2111685091189' lon='16.3035366605548' timestamp='2006-09-11T16:28:25+01:00'>
     <tag  k='amenity' v='hospital'/>
....

beispiel aus dem wiki, also nicht aktuell
gruss
walter

Bis darauf das das nicht AND sondern NOT für die Regel bedeutet, aber ist schon gut…

AND-Fall: Zeitdefinition AND Meldung wäre schon:
Mo-Fr 8:00-14:00 “Bitte telefonisch anmelden!”

NOT-Fall: NOT(Zeitdefinition) AND Meldung:
Mo-Fr 8:00-14:00 ! “Außerhalb der Öffnungszeiten auch nach Vereinbarung.”

Nahmd,

Sagen wir mal so… wenn er den Hinweis nicht lesen kann, wird er auch Probleme haben, einen Besuchstermin zu vereinbaren :slight_smile:

Der fehlt noch: “nur für Gruppen” (Gedenkstätte), “nur bei gutem Wetter” (Biergarten), “nur Frauen” (Sauna) “vorherige schriftliche Anmeldung erforderlich” (Orte mit Sicherheitsüberprüfung), usw. usw.

Und natürlich muss bei jeder Änderung an dieser Liste überall die Software ausgetauscht werden. Immer noch Interesse?

Dann doch lieber eine generische Schreibweise für die Marker: #OD für “on demand” (Nur ein Beispiel! Um Himmels willen ziehe sich keiner daran hoch!)

Oder aber: “on demand” als Text. Wenn man da Phrasen vorgibt und die eingehalten werden, kann man die automatisch übersetzen. “women only”, “weather permitting”, … Wenn nicht, dann halt nicht.

Das lässt den Menschen die Freiheit, neue Dinge auszuprobieren.

Gruß Wolf

Nahmd,

Ganz genau bedeutet es: “IF NOT YET THEN”
Dafür gibts aber in keiner mir bekannten Programmiersprache einen Operator.

Selbst hier hab ichs nicht gefunden: http://www.bruhaha.de/Computer.html#digitaltechnik
.oO( wobei der 7-Bit Komplikator der Sache schon recht nahe kommt)

Das “&” ist auch schön, das müsste aber OHNE das “;” stehen, damit es gut aussieht, und dann müssen wird die Prioritäten von “;” und “&” gegeneinander festlegen – das ist einem normalen Menschen nicht zuzumuten.

Mir gefällt das “+” immer noch am besten – syntaktisch macht es überhaupt keinen Stress, und es bildet das auch gesprochene “und außerdem” sehr schön ab. Ich warte aber einfach ab, bis sich da ein Konsens einstellt.

Gruß Wolf

das “und außerdem” heißt es ja auch bei “Bitte telefonisch anmelden!”, aber aus Sicht der Umgangssprache ist “+” auch nachvollziehbar. Genau, abgestimmt wird dann per taginfo oder man findet vorher einen Konsens.

Etwas zu National gedacht? Soll dein Script nur in DACH angewandt werden können? Davon abgesehen, würde ich solche zusätzlichen Parameter lieber in einem anderen Tag sehen, damit man sie auch auswerten kann ohne das komplette opening_hours zu parsen. Wenn es aber in opening_hours stecken soll, dann nicht als variabler String, sondern als eine einheitliche Zeichenfolge, die man in jeder Sprache darstellen kann.

Um auf deine Frage zu antworen: Wenn da in einer Sprache, die ich nicht spreche etwas steht hilft mir die Anzeige nichts. Ich könnte aber bspw. dem betreffenden am Telefon auf englisch bspw. klarmachen, was ich will.

Ja, aber NOT finde ich auch nicht passender. Denn eigentlich hieße !“Nach Vereinbarung” ja wohl, dass es nicht nach Vereinbarung geht. Eigentlich ist die korrekte Verknüpfung hier ein OR, aber | möchte ich auch keinem zumuten. Ich wette, die Hälfte aller Computernutzer findet das Zeichen nichtmal auf ihrer Tastatur, mal abgesehen von Ähnlichkeiten mit I und l. Rein was die gesprochene Sprache angeht, verwendet man an der Stelle jedenfalls ein und: “Geöffnet jeden Tag von drei bis fünf und nach Vereinbarung” oder halt ein oder. Jedenfalls kein nicht :wink: