Öffungszeiten [2]

Moin,

user_5359 wrote:

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

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:

"nur nach Anmeldung"
Mo-Su; Fr "nur nach Anmeldung"
Mo-Fr 10:00-12:00, 14:00-17:00; Fr 15:00-16:00 "nur nach Anmeldung"
Oct 23 - Dec 03 "bitte telefonisch reservieren"

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

user_5359 wrote:

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

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:

tourism=museum
name=Museum für angewandten Irrsinn
guidance:times=Sa,So 12:00,15:00; Mo-Fr 18:00-20:00 "Nach telefonischer Anmeldung"
guidance:phone=0900 666666
guidance:price=…

aber auch so:

amenity=place_of_worship
denomination=…
service:times=Sa 18:00; So 08:00,11:00

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.

aighes wrote:

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.

Netzwolf wrote:

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

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".

Netzwolf wrote:

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

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. ;-)

wambacher wrote:

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.

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.

Fabi2 wrote:

wambacher wrote:

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.

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!

aighes wrote:

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

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.

Gruß Wolf

Nahmd,

wambacher wrote:

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.

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?

wambacher wrote:

wer soll das - ausser mit genau diesem tool - vernünftig darstellen?

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.

wambacher wrote:

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?

Welche Geräte werten zur Zeit dieses Tag aus?

wambacher wrote:

gibt es inzwischen ein proposal oder irgendwas auf wiki, was die ganze sache mal präsentiert?
da ist wohl noch einiges zu tun.

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.

wambacher wrote:

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

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 …

wambacher wrote:

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.

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.

wambacher wrote:

abgesehen davon, dass ich einige technische bedenken zu der art und weise der datenaktualisierung habe - aber das wäre ein andere thema.

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,

Fabi2 wrote:

Das Problem was ich da hatte, war eher, ob der Text mit in den Kontext der Regel fällt oder nicht.

Einfache Regel: der text wirk genau wie das "off".

Fabi2 wrote:

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"
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".

Das schreibt man es so:

Mo-We 8:00-16:00; Th off; Fr 8:00-12:00; Fr 12:00-18:00 "Nach Vereinbarung"

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

Gruß Wolf

Nahmd,

wambacher wrote:

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.

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

Gruß Wolf

Netzwolf wrote:

Das schreibt man es so:

Mo-We 8:00-16:00; Th off; Fr 8:00-12:00; Fr 12:00-18:00 "Nach Vereinbarung"

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

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,

errt wrote:

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.

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!

errt wrote:

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

Netzwolf wrote:

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!

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,

Fabi2 wrote:

Netzwolf wrote:

Das schreibt man es so:

Mo-We 8:00-16:00; Th off; Fr 8:00-12:00; Fr 12:00-18:00 "Nach Vereinbarung"

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

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"

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

Netzwolf wrote:

wambacher wrote:

abgesehen davon, dass ich einige technische bedenken zu der art und weise der datenaktualisierung habe - aber das wäre ein andere thema.

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.

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

Netzwolf wrote:

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"

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.

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"

Netzwolf wrote:

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)

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,

Fabi2 wrote:

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"

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 <rule>), und weniger als zehn Zeilen Code. Ist bereits eingebaut und darf ausprobiert werden: http://www.netzwolf.info/kartografie/os … /#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.

Netzwolf wrote:

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.

Was da aus meiner Sicht gebraucht wird, ist kein zweiter "und"-Operator, weil wenn ich "und außerdem" machen will, kann ich ja schon <rule1> ; <rule2> 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.

Nahmd,

wambacher wrote:

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"

Das ist fast richtig:

wambacher wrote:

das teil kann viel und mehr als alles andere, was es derzeit gibt

Das ist für mich kein Kriterium.

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?

wambacher wrote:

ihr könnt es gerne ausschlachten

Natürlich kann man sich so über Open-Source äußern. Ich bevorzuge allerdings eine etwas respektvollere Sprache.

wambacher wrote:

und mit etwas glück fliesst auch was ins wiki ein

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 …

Gruß Wolf

Netzwolf wrote:

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.

Es gibt aber in der Praxis 3 Fälle:

"open" + Ansagetext:

Mo-Fr␣7:00-13:00␣"Bitte␣vorher␣telefonisch␣anmelden!"

"closed" + Ansagetext:

Mo-Fr␣8:00-16:00;␣!␣"Außerhalb␣der␣Öffnungszeiten␣Termine␣auch␣nach␣Vereinbarung"

nur Ansagetext (selbst bei 'nen Dorfkneipe Sachen wie "sporadic" gesehen):

"sporadisch␣geöffnet"

Nahmd,

Fabi2 wrote:

Was da aus meiner Sicht gebraucht wird, ist kein zweiter "und"-Operator, weil wenn ich "und außerdem" machen will, kann ich ja schon <rule1> ; <rule2> machen

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.

Fabi2 wrote:

, sondern eine Negation:
"(am Freitag|immer) außerhalb der Öffnungszeiten auch nach Vereinbarung".

Genau das drückt das "+" doch zwanglos aus: diese Regel überschreibt nicht, diese Regel ergänzt.

Gruß Wolf

viw wrote:

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.

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

Nahmd,

Fabi2 wrote:

Es gibt aber in der Praxis 3 Fälle:

"open" + Ansagetext:

Mo-Fr␣7:00-13:00␣"Bitte␣vorher␣telefonisch␣anmelden!"

"closed" + Ansagetext:

Mo-Fr␣8:00-16:00;␣!␣"Außerhalb␣der␣Öffnungszeiten␣Termine␣auch␣nach␣Vereinbarung"

nur Ansagetext (selbst bei 'nen Dorfkneipe Sachen wie "sporadic" gesehen):

"sporadisch␣geöffnet"

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:

http://www.netzwolf.info/kartografie/os … evaluation

Gruß Wolf

Netzwolf wrote:

wambacher wrote:

ihr könnt es gerne ausschlachten

Natürlich kann man sich so über Open-Source äußern. Ich bevorzuge allerdings eine etwas respektvollere Sprache.

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

Netzwolf wrote:

Dieses "Problem" ist kein Problem, sondern Bestandteil der Realität, sogar ein häufiger.

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!].

Netzwolf wrote:

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

␣␣␣tourism=museum
name=Museum␣für␣angewandten␣Irrsinn
guidance:times=Sa,So␣12:00,15:00;␣Mo-Fr␣18:00-20:00␣"Nach␣telefonischer␣Anmeldung"
guidance:phone=0900␣666666
guidance:price=…

aber auch so:

␣␣␣amenity=place_of_worship
denomination=…
service:times=Sa␣18:00;␣So␣08:00,11:00

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.

Netzwolf wrote:

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.

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).

user_5359 wrote:

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.

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.

user_5359 wrote:

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.

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

Netzwolf wrote:

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:

http://www.netzwolf.info/kartografie/os … evaluation

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,

wambacher wrote:

womit ich bei deiner Karte noch ein richtiges Problem habe, ist die Frage der Datenaktualisierung.

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.

wambacher wrote:

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.

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,

errt wrote:

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.

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 😛 Lass dich nicht davon stören, wir sind trotzdem alle froh um deine Arbeit.

Netzwolf wrote:

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:

http://www.netzwolf.info/kartografie/os … evaluation

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.

Netzwolf wrote:

Ich realisere einen Änderungswunsch – obwohl ich zu dem Punkt eine andere Meinung habe → falsch.

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,

Fabi2 wrote:

user_5359 wrote:

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.

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

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,

viw wrote:

welchen XAPI Server verwendest du denn?

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

viw wrote:

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.

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

Netzwolf wrote:

Fabi2 wrote:

user_5359 wrote:

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.

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

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.

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.

Fabi2 wrote:

Na, prima! Danke für die Änderung. Aus meiner Sicht ist "!" nach z.B. der C-Syntax so viel eingängiger

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 😛

@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.

Netzwolf wrote:

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

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

errt wrote:

Fabi2 wrote:

Na, prima! Danke für die Änderung. Aus meiner Sicht ist "!" nach z.B. der C-Syntax so viel eingängiger

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 😛

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,

flaimo wrote:

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.

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

flaimo wrote:

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.

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,

Fabi2 wrote:

errt wrote:

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 😛

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

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

Netzwolf wrote:

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.

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.

Netzwolf wrote:

Nahmd,

flaimo wrote:

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.

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

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.

Fabi2 wrote:

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

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 😉

errt wrote:

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 😉

Bis auf das "I" in der Spezififation außerhalb von "" nicht vor kommt und es ja auch "Geöffnet jeden Tag von drei bis fünf und außerhalb unserer Öffnungszeiten auch nach vorheriger telefonischer Vereinbarung" heißt. Also wäre da ein "&" aus meiner Sicht auch falsch, dann doch lieber die dritte Bedeutung für "+".

Du hast das zweite Zeichen garnicht als kleines L identifiziert, oder? Ich meinte, es würden sicher viele einen der beiden Buchstaben statt der Pipe verwenden.

Nahmd,

aighes wrote:

Etwas zu National gedacht? Soll dein Script nur in DACH angewandt werden können?

Mist, ich bin als Nationalist enttarnt! Und das nur, weil ich faul war, nur die deutschen Feiertage eingebaut und den "grünen Tag" und Kaisers Geburtstag nicht berücksichtigt habe. Schande auf mein Haupt!

aighes wrote:

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.

Das sei Dir hiermit genehmigt.
[STEMPELABDRUCK] ←verschmiert
Unlsrlichr Krakl

aighes wrote:

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.

Auch davon hält Dich niemand ab. Du schreibst Dein Kürzel als "KRZL" und schon wird das KRZL als Ergebnis der Analyse geliefert.

Dinge übersetzen zu können ist eine feine Sache. ich sträube mich aber dagegen, Menschen Freiheiten wegzunehmen, insbesondere zu einem frühen Zeitpunkt, zu dem überhaupt noch nicht absehbar ist, was alles mit der Funktionalität angestellt werden kann.

→ Wenn jemand "KRZL" schreibt und das automatisch übersetzt wird, so ist das toll!

Wenn ein anderer schreibt »Sa 08:00-16:00; Sa 16:00-22:00 "Öffnungszeit hängt von der Laune des Bademeisters ab"«, so soll auch das erlaubt sein.

Wenn der Auswertealgorithmus beides mit dem gleichen (geringen) Aufwand schafft, umso besser.

Und wenn jetzt noch die Übersetzungsroutine Texte, zu denen sie keine Übersetzung kennt, einfach durchreicht, dann haben alle gewonnen.
Formalisierung mit automatischer Auswertung soweit wie möglich, und das bei maximaler Freiheit.

Wenn die "opening_hours" hinreichend viele Möglichkeiten abdecken soll, wird das Feld auf jeden Fall eine Komplexität haben, mit der manche Mapper überfordert sind. Da reicht aber ein einfacher Satz auf der Wikiseite: "wenn Dir nicht klar ist, wie du etwas codierst, schreib es als Text in Anführungszeichen". Das ist dann sofort für die Benutzer verfügbar, und ein anderer Mapper kann die Einträge durchgehen und soweit möglich formal ausdrücken; ein Rest informelles wird wieder als Text ausgedrückt. Und wenn bestimmte Texte häufiger vorkommen, dann lohnt sich, ein Kürzel einzuführen.

Gruß Wolf

Netzwolf wrote:

ich sträube mich aber dagegen, Menschen Freiheiten wegzunehmen, insbesondere zu einem frühen Zeitpunkt, zu dem überhaupt noch nicht absehbar ist, was alles mit der Funktionalität angestellt werden kann.

Eben, das ist eben auch genau das Problem mit künstlich beschränkter Software, da wird zum Teil selbst auf sehr sinnvolle (d.h. nicht nur für irgendeine Nischenanwendung) Funktionalität verzichtet, nur damit der Venutzer die Anwengung noch kapiert. Dabei geht beides, indem man einen Expertenmode einbaut, der standardmäßig ausgeschaltet ist. Wenn Open Source Software solche Beschränkungen hat, könnte ich jedesmal nur kotzen. Den neuen Benutzer verwirren die Sachen, aber der Daueranwender möchte nicht darauf verzichten. das gilt auch für OSM, man stelle sich vor, die Tags wären alle fest vorgegeben und ließen sich nicht ändern...

Moin

Fabi2 wrote:

man stelle sich vor, die Tags wären alle fest vorgegeben und ließen sich nicht ändern...

.oO( http://www.youtube.com/watch?v=MJbn5BtAEoc )

Gruß Wolf

wambacher wrote:

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.

hi wolfgang,
jetzt ist der Kringel gelb - eigentlich passend für briefkästen 😉
http://www.netzwolf.info/kartografie/os … ayers=B00T
aber lieber wäre mir, wenn der ganz raus wäre.
gruss
walter