DE talk:Key:opening hours
Open End?
gibt es schon einen tag für zB 20:00Uhr-? also einem undefiniertem Ende? wenn noch nicht, undefined kurz un. Das würde dann im Beispiel so lauten: Mo-Fr 07:00-18:00; Sa 07:00-un --Fuss-im-Ohr 23:27, 10 October 2009 (UTC)
- Dokumentiert ist dazu jedenfalls noch nichts, das gehört zu den zahlreichen Dingen, um die man die Syntax noch erweitern könnte. Bei einer Diskussion auf der Mailingliste talk-de kam auch kein abschließendes Ergebnis raus, am ehesten Unterstützung hatte wohl open_end. Auf jeden Fall würde ich darauf achten, etwas zu nehmen, das auch ohne Nachschlagen der Dokumentation klar ist - also nicht so ein Kürzel wie "un" (oder, von der Mailingliste, "DOG"). --Tordanik 19:42, 11 October 2009 (UTC)
- Das ist mir auch schon aufgefallen und ich hatte in der Praxis wirklich Läden (das war in dem Fall ein Blumenladen) da steht dann z.B. "So ab 9:00 Uhr" dran uns sonst nichts weiter, des weiteren betrifft das ja quasi alle Kneipen, etc. welche bis "open end" geöffnet haben. Es haben auch schon diverse Leute notgedrungen "xx:00-epen_end" ausgeschrieben. Ich hatte da auch schon mal mit einem anderem User drüber geredet, dass das opening_hour-Schema nicht unbedingt ausgereift ist und alle Fälle abdeckt, z.B. gibt es bisher auch nichts für "1. und 3. Sa im Monat: xx:yy-aa:bb". Jedenfall ist seit heute die "+"-Erweiterung auf der Seite, die sollte auch nicht zu Doppeldeutigkeiten mit dem bisherigen Schema führen und bgebraucht wird sie alle mal und dafür extra ein neues Proposal schreiben ist auch affig, weil die Voterei ist ja eh für'n Arsch (Wer liest schon innerhalb der vorgesehenen Zeit immer alle Proposals? Nicht alle Leute bevorzugen/benutzen die Mailinglisten, etc.) so das sie eh als Vorschläge zu sehen sind und da müllt diese Mini-Erweiterung nur mehr die Kategorie weiter zu. Am Ende entscheidet eh Tagwatch, osmdoc, etc. Kleiner Nachtrag: Da "geöffnet ab xx:yy Uhr" und "von xx:yy Uhr bis open end" von den Auswirkungen her das Gleiche ist (man weis nicht, wann die Einrichtung nun wirklich schließt), ist es sinnvoll, das zusammen zu fassen, weshalb aus meiner Sicht das auch besser durch "+" ausgedrückt wird, als durch "-open_end". --Fabi2 22:31, 1 March 2010 (UTC)
- Du magst ja von Abstimmungen nichts halten, und in der Tat können sie durch häufige Verwendung eines Tags überflüssig werden. Allerdings ist das für den vorliegenden Fall irrelevant, da "+" bislang keineswegs häufig verwendet wird.
- Ich für meinen Teil würde aber gerne mal den - möglichst internationalen - Mailinglisten- oder Forenthread sehen, in dem diese Syntax vor der Änderung besprochen wurde. Ich würde mir jedenfalls nicht zutrauen, alle Eventualitäten und Probleme selber bedacht zu haben. Wenn in einem Diskussionsthread keiner einen entscheidenden Einwand geäußert hätte, dann wäre ich mir schon eher sicher, dass es sich um eine zweifelsfrei gute Lösung handelt. --Tordanik 10:41, 2 March 2010 (UTC)
- Eine größere Userzahl ist aber auch nicht zwangläufig die Gewähr für gute Lösungen, wie man ja an den Postings der "open_end"-Diskussion sieht. Ich maße mir auch nicht an, die Patentlösung für alles gefunden zu haben, aber das Produkt meiner 2-Mann-Privatdiskussion deckt zumindest, aus meiner Sicht, die bisher bekannten Fälle, besser und allgemeiner ab als "-open_end". Ich mache übrigens auch keine ad-hoc Änderungen für Sachen die ich nicht überschaue, dazu sind ja die Proposal-Diskussionen gut, aber wie man an diesem Beispiel sieht, sind die ja auch irgendwann vorbei, egal wie viele Leute sich daran beteiligt haben, so ist das doch wie ich schrieb immer nur eine Submenge der Nutzer, und dann ist das Ergebnis quasi erst mal fest und man darf ein neues Proposal schreiben (mache ich im Normalfall auch). Ich habe auch absolut nichts gegen die Proposal-Diskussionen, weil meistens fördern die ja zumindest noch einige Nebenfälle zu Tage, die man nicht bedacht hat, aber gerade bei opening_hours gibt es genug was man verbessern könnte, aber da hab ich auch keine Ideen wie man das vernüftig mit dem bisherigen Schema integriert, deshalb hab ich es ja auch nicht weiter versucht, bis auf diese kleine Erweiterung. --Fabi2 18:53, 2 March 2010 (UTC)
- Nein, gute Lösungen gibts von einer großen Teilnehmergruppe leider nicht unbedingt - mir geht es da auch eher um interessante Einwände, und beim Meckern über einen Vorschlag ist mit Mailinglisten & co meist doch zu rechnen. ;) Beim "+" habe ich selber keine schwerwiegenden Bedenken, weshalb ich im konkreten Fall jetzt nicht in Opposition gehen werde. Allenfalls würde ich hier gewisse Verständnisschwierigkeiten vermuten: Versteht der Mapper das einzelne Zeichen ohne Zuhilfenahme der Dokumentation genauso gut wie ein (englisches) Wort? Das kann ich allein schwer beurteilen. --Tordanik 19:34, 2 March 2010 (UTC)
- Ja, das die Tags und Werte möglichst eingängig und für Menschen leicht überprüfbar sein sollten ist völlig korrekt. Die Erfahrung zeigt ja auch, das die einfacheren Varianten sich gegenüber den komplizierten durchsetzen, siehe z.B. das Karlsruhe Schema und die AssociatedStreet-Relation. Das Problem ist nur, das die Sachen möglichst leicht verständlich, eindeutig und dann auch noch gut maschinenlesbar sein müssen, ja das erfordert eigentlich mal eine Grundsatzdiskussion zu dem Thema, weil definitiv ist "-open_end" schneller zu verstehen als der an Sachen wie "Generation 50+" angelehnte "+"-Operator. Aber da ist ja auch die Frage was ist möglichst eindeutig zu parsen und trotzdem noch verständlich, wo es dann doch besser 22:00+ zu schreiben als "-open_end", weil dann da manche schnell "open end" oder vielleicht sogar "open-end" daraus machen (ist muß man dann wieder zusätzlich den Parser fehlertolerant machen, das Groß-/Kleinschreibung bei solchen Keys eh normalisiert wird habe ich da schon angenommen) oder ein vertippen macht ein "sunrise" zu "surise" und dann korrigiert das vielleicht jemand zu "suprise". Besser ist es da wenn es möglichst gleich eindeutig per Definition ist. Das gilt übrigens auch für die laut aktueller Syntax führende Null bei den Öffnungszeiten, nachdem ich eine Weile keine opening_hours mehr gemappt habe, hatte ich das glatt vergessen, das man die noch angeben muß, wobei die besser wahlfrei sein sollte, denn bei komplexen Öffnungszeiten lesen sich die einheitlichen Zweiergruppen deutlich besser, aber eingängiger und intuitiver ist die Schreibweise ohne führende Null, wenn man mal eben nur ein ganz simples Öffnungszeitenschema mappen will. Für den Computer ist das an der Stelle kein Unterschied, da beides eindeutig ist. Ich plädiere auch dafür im Zweifelsfall lieber den Computer ein paar Microsekunden länger rechnen zu lassen, wenn es dadurch leichter zu benutzen ist. Denn warum man nicht Öffnungszeiten wie "Mo 22:00-06:00" statt "Mo 22:00-24:00;Di 00:00-06:00" zu läßt, fragen sich ja auch manche Leute zu recht. Das ist viel eingängiger und dem Computer läßt sich sehr schnell beibringen das der Tag um 24:00 Uhr wechselt. Genauso mappen manche Leute lieber alle Fuß-/Radwgeigenschaften an die Straße, weil da mal jemand in DE-Land eine Verordnung gemacht hat, daß der Fußweg juristisch Bestandteil der Straße ist und begründen das ganze dann damit, das Routingsoftware nicht in der Lage sein soll, die Fuß- und Radwege einfach über ihren Tag zu ignorieren. Hoffentlich kommen die wheelchair-Mapper bald auf die Idee, die Bürgersteigauffahrten und deren Eigenschaften einzeichnen zu wollen... *g* --Fabi2 21:24, 3 March 2010 (UTC)
- Es gibt Fehler, die erkennt man ohne Kenntnis der gewünschten Bedeutung als solche und hat sie schnell korrigiert. Dazu gehören Vertipper bei so etwas wie "open_end". Andererseits gibt es aber auch Fehler, die erkennt man nicht als solche: wenn etwa jemand das "+" als Symbol für das akademische Viertel fehlinterpretiert hat oder der Meinung war, mit "Mo 23:00-08:00" werde ausgedrückt, dass es schon am Sonntag um 23:00 losgeht. Ich bevorzuge im Zweifelsfall Lösungen, die Fehler der erstgenannten Art produzieren. Wenn ein Parser an so einem Fehler "scheitert", dann ist das kein Nach- sondern ein Vorteil - denn das heißt ja, dass man die Fehler sogar automatisch finden kann! Toleranz gegenüber hinsichtlich ihrer Bedeutung unproblematischen Varianten (z.B. mit und ohne führende Null) ist eigentlich ein anderes Thema. --Tordanik 12:51, 7 March 2010 (UTC)
- + Als Syntax für das aademischen Viertel war mir völlig unbekannt und ich kenne auch zumindest zwei Unis die geben grundsätzlich die volle Stunde, also z.B 8:00-10:00 Uhr, an, wenn xx:15 gemeint ist, um nicht zu sagen, das das aus meiner Sicht extrem unüblich ist. Sicher erkennt man Rechtschreibfehler, aber nicht ohne größeren Aufwand (RegEx's für Standardverpipper (welche man ja auch erst mal ermitteln muß) bedeuten bei diesemn Datenmengen nun mal einen merklichen Mehraufwand) automatisiert, sondern nur manuell und für Menschen kann ich ja auch ganz genau in note= etc, reinschreiben, was damit gemeint ist, nur das hilft mir für meinen hypothetischen "Welcher x hat denn jetzt eigentlich hier möglichst in der Nähe noch offen"-Service dann herzlich wenig. Ja, den hätte ich gern und zwar gleich mit passender und auf die Öffnungszeit optimierter ÖPNV-Anfahrtroute! Ich bin auch nicht der erste der schon die Idee hat, die Fahrpläne mit zu erfassen ( siehe http://www.netzwolf.info/kartografie/osm/bus_und_bahn/), denn die sind von Natur aus hochredundant und das neue ÖPNV-Schema ist wie geschaffen dafür, einfach in die jeweilige Linienvariantenrelation deren Fahrzeiten mit aufzunehemen. Ich sehe keinen Vorteil wenn der Parser an uneinheitlichen und mehrdeutigen Tags scheitert, weil letztendlich sollen Rechner die Daten verarbeiten und da helfen mir möglichst viele und dafür genaue Freitextfelder (Vertipper sehe ich als deren entschärfte Variante) herzlich wenig, weil wenn man schreibt ja auch highway=residential, name=X-Straße, surface=asphalt und nicht "An diesem zweispurigen, asphaltierten Weg, befinden sich rechts mehrere dreistöckige Reihenhäuser. Das Starßenschild steht nur links und nur am Anfang und ist mit "X-Straße" beschriftet." --Fabi2 19:48, 16 March 2010 (UTC)
- Der Vorteil, wenn der Parser scheitert, besteht darin, dass man dann einen Menschen auf diese Tatsache aufmerksam machen kann. Als Betreiber eines hypothetischen "welches x hat offen"-Dienstes könnte ich problemlos als Nebenprodukt eine Liste aller opening_hours in der Datenbank erstellen, an denen mein Parser gescheitert ist, und eine Bereinigungsaktion starten. Idealerweise würde ich die Fehler natürlich gar nicht erst entstehen lassen - beispielsweise könnte ich ein JOSM-Plugin schreiben, das beim Eintippen von syntaktisch fehlerhaften opening_hours-Werten das Eingabefeld rot hinterlegt und so auf Tippfehler aufmerksam macht. Ich kann kein JOSM-Plugin erstellen, das ein Feld rot hinterlegt, wenn der Mapper irgendein Sonderzeichen falsch interpretiert hat.
Daher - wegen der Möglichkeit also, Fehler automatisch zu entdecken - finde ich Unmissverständlichkeit wichtiger als eine Verringerung der Tippfehlergefahr. Deshalb finde ich auch, trotz der ganzen "residental"-Vertipper, highway=residential besser als highway=r. Für nicht automatisiert auswertbare, natürlichsprachige Beschreibungen wie "rechts mehrere dreistöckige Reihenhäuser" habe ich mich nie ausgesprochen. --Tordanik 20:26, 16 March 2010 (UTC)- Der Vorteil daran, das der Parser scheitert, ist, daß man die Karten ja auch immer noch mit seinem Lieblingszeichenprogramm erstellen kann. ;-) In der Praxis ist es doch so, das es zwischen Eindeutigkeit für den Rechner und guter Verständlichkeit für den Menschen der best möglichste Kompromiß gefunden werden muß. Die obige Freitextbeschreibung sollte ja auch nur Zeigen, das man es für den Menschen noch eindeutiger und besser verständlich machen kann, als highway=residential. Ja, wo ich angefangen habe, wußte ich mit der Bezeichnung "Wohnstraße" auch nichts anzufangen (das Erste woran man da möglicherweise denkt, ist, ist ob das nicht eine Straße für die Leute ist die "auf der Straße" leben wollen oder müssen...), ja "Straße durch ein Wohngebiet" oder "Straße durch bewohntes Gebiet" würde es echt besser treffen. Die Idee von Wizards in JOSM, etc. z.B. für die Öffnungszeiten ist ja gut, aber andererseits erschafft man ja da die Beschränkung neu, die man durch die Benutzung von XML gerade vermeiden wollte und außerdem muß dann das Format nicht mehr unbedingt menschenlesbar sein, was ja aber gerade wichtig ist, da die Daten hauptsächlich von Menschen bearbeitet und gewartet werden müssen, aber dann deshalb trotzdem noch möglichst gut maschinenlesbar sein sollten. Ja, ich denke auch das der +-Operator besser konzipiert ist, als auf der englischen Liste mal eben schnell von ein paar Leuten beschlossene "1./x. letzter-Wochentag" im Monat Erweiterung, weil Su[-1] ist ja wohl alles andere als eingängig, gerade auch weil z.B. "-1" in gängigen APIs und Progammiersprachen eher "nicht definiert" bzw. Fehler bedeutet und die Vertipperwarscheinlichkeit zu Su[1] ja auch nicht gerade gering ist. --Fabi2 17:23, 21 March 2010 (UTC)
- Der Vorteil, wenn der Parser scheitert, besteht darin, dass man dann einen Menschen auf diese Tatsache aufmerksam machen kann. Als Betreiber eines hypothetischen "welches x hat offen"-Dienstes könnte ich problemlos als Nebenprodukt eine Liste aller opening_hours in der Datenbank erstellen, an denen mein Parser gescheitert ist, und eine Bereinigungsaktion starten. Idealerweise würde ich die Fehler natürlich gar nicht erst entstehen lassen - beispielsweise könnte ich ein JOSM-Plugin schreiben, das beim Eintippen von syntaktisch fehlerhaften opening_hours-Werten das Eingabefeld rot hinterlegt und so auf Tippfehler aufmerksam macht. Ich kann kein JOSM-Plugin erstellen, das ein Feld rot hinterlegt, wenn der Mapper irgendein Sonderzeichen falsch interpretiert hat.
- + Als Syntax für das aademischen Viertel war mir völlig unbekannt und ich kenne auch zumindest zwei Unis die geben grundsätzlich die volle Stunde, also z.B 8:00-10:00 Uhr, an, wenn xx:15 gemeint ist, um nicht zu sagen, das das aus meiner Sicht extrem unüblich ist. Sicher erkennt man Rechtschreibfehler, aber nicht ohne größeren Aufwand (RegEx's für Standardverpipper (welche man ja auch erst mal ermitteln muß) bedeuten bei diesemn Datenmengen nun mal einen merklichen Mehraufwand) automatisiert, sondern nur manuell und für Menschen kann ich ja auch ganz genau in note= etc, reinschreiben, was damit gemeint ist, nur das hilft mir für meinen hypothetischen "Welcher x hat denn jetzt eigentlich hier möglichst in der Nähe noch offen"-Service dann herzlich wenig. Ja, den hätte ich gern und zwar gleich mit passender und auf die Öffnungszeit optimierter ÖPNV-Anfahrtroute! Ich bin auch nicht der erste der schon die Idee hat, die Fahrpläne mit zu erfassen ( siehe http://www.netzwolf.info/kartografie/osm/bus_und_bahn/), denn die sind von Natur aus hochredundant und das neue ÖPNV-Schema ist wie geschaffen dafür, einfach in die jeweilige Linienvariantenrelation deren Fahrzeiten mit aufzunehemen. Ich sehe keinen Vorteil wenn der Parser an uneinheitlichen und mehrdeutigen Tags scheitert, weil letztendlich sollen Rechner die Daten verarbeiten und da helfen mir möglichst viele und dafür genaue Freitextfelder (Vertipper sehe ich als deren entschärfte Variante) herzlich wenig, weil wenn man schreibt ja auch highway=residential, name=X-Straße, surface=asphalt und nicht "An diesem zweispurigen, asphaltierten Weg, befinden sich rechts mehrere dreistöckige Reihenhäuser. Das Starßenschild steht nur links und nur am Anfang und ist mit "X-Straße" beschriftet." --Fabi2 19:48, 16 March 2010 (UTC)
- Es gibt Fehler, die erkennt man ohne Kenntnis der gewünschten Bedeutung als solche und hat sie schnell korrigiert. Dazu gehören Vertipper bei so etwas wie "open_end". Andererseits gibt es aber auch Fehler, die erkennt man nicht als solche: wenn etwa jemand das "+" als Symbol für das akademische Viertel fehlinterpretiert hat oder der Meinung war, mit "Mo 23:00-08:00" werde ausgedrückt, dass es schon am Sonntag um 23:00 losgeht. Ich bevorzuge im Zweifelsfall Lösungen, die Fehler der erstgenannten Art produzieren. Wenn ein Parser an so einem Fehler "scheitert", dann ist das kein Nach- sondern ein Vorteil - denn das heißt ja, dass man die Fehler sogar automatisch finden kann! Toleranz gegenüber hinsichtlich ihrer Bedeutung unproblematischen Varianten (z.B. mit und ohne führende Null) ist eigentlich ein anderes Thema. --Tordanik 12:51, 7 March 2010 (UTC)
- Ja, das die Tags und Werte möglichst eingängig und für Menschen leicht überprüfbar sein sollten ist völlig korrekt. Die Erfahrung zeigt ja auch, das die einfacheren Varianten sich gegenüber den komplizierten durchsetzen, siehe z.B. das Karlsruhe Schema und die AssociatedStreet-Relation. Das Problem ist nur, das die Sachen möglichst leicht verständlich, eindeutig und dann auch noch gut maschinenlesbar sein müssen, ja das erfordert eigentlich mal eine Grundsatzdiskussion zu dem Thema, weil definitiv ist "-open_end" schneller zu verstehen als der an Sachen wie "Generation 50+" angelehnte "+"-Operator. Aber da ist ja auch die Frage was ist möglichst eindeutig zu parsen und trotzdem noch verständlich, wo es dann doch besser 22:00+ zu schreiben als "-open_end", weil dann da manche schnell "open end" oder vielleicht sogar "open-end" daraus machen (ist muß man dann wieder zusätzlich den Parser fehlertolerant machen, das Groß-/Kleinschreibung bei solchen Keys eh normalisiert wird habe ich da schon angenommen) oder ein vertippen macht ein "sunrise" zu "surise" und dann korrigiert das vielleicht jemand zu "suprise". Besser ist es da wenn es möglichst gleich eindeutig per Definition ist. Das gilt übrigens auch für die laut aktueller Syntax führende Null bei den Öffnungszeiten, nachdem ich eine Weile keine opening_hours mehr gemappt habe, hatte ich das glatt vergessen, das man die noch angeben muß, wobei die besser wahlfrei sein sollte, denn bei komplexen Öffnungszeiten lesen sich die einheitlichen Zweiergruppen deutlich besser, aber eingängiger und intuitiver ist die Schreibweise ohne führende Null, wenn man mal eben nur ein ganz simples Öffnungszeitenschema mappen will. Für den Computer ist das an der Stelle kein Unterschied, da beides eindeutig ist. Ich plädiere auch dafür im Zweifelsfall lieber den Computer ein paar Microsekunden länger rechnen zu lassen, wenn es dadurch leichter zu benutzen ist. Denn warum man nicht Öffnungszeiten wie "Mo 22:00-06:00" statt "Mo 22:00-24:00;Di 00:00-06:00" zu läßt, fragen sich ja auch manche Leute zu recht. Das ist viel eingängiger und dem Computer läßt sich sehr schnell beibringen das der Tag um 24:00 Uhr wechselt. Genauso mappen manche Leute lieber alle Fuß-/Radwgeigenschaften an die Straße, weil da mal jemand in DE-Land eine Verordnung gemacht hat, daß der Fußweg juristisch Bestandteil der Straße ist und begründen das ganze dann damit, das Routingsoftware nicht in der Lage sein soll, die Fuß- und Radwege einfach über ihren Tag zu ignorieren. Hoffentlich kommen die wheelchair-Mapper bald auf die Idee, die Bürgersteigauffahrten und deren Eigenschaften einzeichnen zu wollen... *g* --Fabi2 21:24, 3 March 2010 (UTC)
- Nein, gute Lösungen gibts von einer großen Teilnehmergruppe leider nicht unbedingt - mir geht es da auch eher um interessante Einwände, und beim Meckern über einen Vorschlag ist mit Mailinglisten & co meist doch zu rechnen. ;) Beim "+" habe ich selber keine schwerwiegenden Bedenken, weshalb ich im konkreten Fall jetzt nicht in Opposition gehen werde. Allenfalls würde ich hier gewisse Verständnisschwierigkeiten vermuten: Versteht der Mapper das einzelne Zeichen ohne Zuhilfenahme der Dokumentation genauso gut wie ein (englisches) Wort? Das kann ich allein schwer beurteilen. --Tordanik 19:34, 2 March 2010 (UTC)
- Eine größere Userzahl ist aber auch nicht zwangläufig die Gewähr für gute Lösungen, wie man ja an den Postings der "open_end"-Diskussion sieht. Ich maße mir auch nicht an, die Patentlösung für alles gefunden zu haben, aber das Produkt meiner 2-Mann-Privatdiskussion deckt zumindest, aus meiner Sicht, die bisher bekannten Fälle, besser und allgemeiner ab als "-open_end". Ich mache übrigens auch keine ad-hoc Änderungen für Sachen die ich nicht überschaue, dazu sind ja die Proposal-Diskussionen gut, aber wie man an diesem Beispiel sieht, sind die ja auch irgendwann vorbei, egal wie viele Leute sich daran beteiligt haben, so ist das doch wie ich schrieb immer nur eine Submenge der Nutzer, und dann ist das Ergebnis quasi erst mal fest und man darf ein neues Proposal schreiben (mache ich im Normalfall auch). Ich habe auch absolut nichts gegen die Proposal-Diskussionen, weil meistens fördern die ja zumindest noch einige Nebenfälle zu Tage, die man nicht bedacht hat, aber gerade bei opening_hours gibt es genug was man verbessern könnte, aber da hab ich auch keine Ideen wie man das vernüftig mit dem bisherigen Schema integriert, deshalb hab ich es ja auch nicht weiter versucht, bis auf diese kleine Erweiterung. --Fabi2 18:53, 2 March 2010 (UTC)
- Das ist mir auch schon aufgefallen und ich hatte in der Praxis wirklich Läden (das war in dem Fall ein Blumenladen) da steht dann z.B. "So ab 9:00 Uhr" dran uns sonst nichts weiter, des weiteren betrifft das ja quasi alle Kneipen, etc. welche bis "open end" geöffnet haben. Es haben auch schon diverse Leute notgedrungen "xx:00-epen_end" ausgeschrieben. Ich hatte da auch schon mal mit einem anderem User drüber geredet, dass das opening_hour-Schema nicht unbedingt ausgereift ist und alle Fälle abdeckt, z.B. gibt es bisher auch nichts für "1. und 3. Sa im Monat: xx:yy-aa:bb". Jedenfall ist seit heute die "+"-Erweiterung auf der Seite, die sollte auch nicht zu Doppeldeutigkeiten mit dem bisherigen Schema führen und bgebraucht wird sie alle mal und dafür extra ein neues Proposal schreiben ist auch affig, weil die Voterei ist ja eh für'n Arsch (Wer liest schon innerhalb der vorgesehenen Zeit immer alle Proposals? Nicht alle Leute bevorzugen/benutzen die Mailinglisten, etc.) so das sie eh als Vorschläge zu sehen sind und da müllt diese Mini-Erweiterung nur mehr die Kategorie weiter zu. Am Ende entscheidet eh Tagwatch, osmdoc, etc. Kleiner Nachtrag: Da "geöffnet ab xx:yy Uhr" und "von xx:yy Uhr bis open end" von den Auswirkungen her das Gleiche ist (man weis nicht, wann die Einrichtung nun wirklich schließt), ist es sinnvoll, das zusammen zu fassen, weshalb aus meiner Sicht das auch besser durch "+" ausgedrückt wird, als durch "-open_end". --Fabi2 22:31, 1 March 2010 (UTC)
Status der Übersetzung
Hallo kann es sein, dass die deutsche Übersetzung die Regel
* non-consecitive or semi-consecutive days of the week will be tagged as wd[x] (eg Su[3] 09:00-12:00)
This is used to indicate the 3rd Sunday of the month from 9am to 12pm. Use -1 to indicate the last day of the month, eg Aug Th[-1] means last Thursday in July. Can use grouping, (eg Su[1,3,5] and Su[1-3])
nicht beinhaltet? Wenn kein Protest kommt würde ich den den Satz in 2 Wochen ergänzen. User 5359 18:15, 26 October 2010 (BST)
- Mag sein. Wenn Du das machst, könntest Du ja das Datum der "Synchronisation" mal mit vermerken! --amai 19:38, 26 October 2010 (BST)
- Also ich frag mich eigentlich auch warum er nicht in der deutschen fassung steht. --Soldier Boy 23:46, 17 Januar 2011 (BST)
Öffnungszeiten Sommer/Winter
Wie gibt man richtigerweise Öffnungszeiten im Sommer und Winter an? Konkret geht es um eine Kirche (ja, da benutze ich service_times, nur da ist der Syntax ja der gleiche), die z. B. Donnerstags und Samstags 18.30 Uhr Messe hat, Sonntags 10.30 Uhr, aber halt Sonntags nur Oktober bis ca. Ende Mai. Bisher hab ich Th,Sa 18:30-19:30; Su 10:30-11:30
, wie muss ich den erweitern? --Quedel 10:58, 13 October 2010 (BST)
- Siehe Talk:Key:opening_hours#Daylight_Savings.--Ypid (talk) 12:50, 18 October 2015 (UTC)
- Th,Sa 18:30-19:30, Oct Su[-1]-Mar Su[-1] -1 day Su 10:30-11:30 Fabi2 (talk) 14:37, 18 December 2023 (UTC)
- Beim nochmaligen Lesen habe ich gesehen, das offenbar die Monate als Bereich gemeint sind. Für den Fall, daß statt der Winterzeit der Bereich Oktober bis Mai gemeint ist, ist die Regel wie folgt: Th,Sa 18:30-19:30, Oct-May Su 10:30-11:30 Fabi2 (talk) 21:50, 18 December 2023 (UTC)
Kombination Bereiche und Auffzählung
Hi, ist folgende Kombination auch gültig? Mo-Th, Su 9:00-3:00; Fr,Sa 9:00-6:00 --Saerdnaer 03:22, 13 March 2011 (UTC)
- Also bei mir wäre das Su-Th 09:00-03:00, Fr-Sa 09:00-06:00. (die führenden Nullen nicht vergessen.) --Lulu-Ann 14:10, 17 November 2011 (UTC)
Öffnungszeiten Behörden... werktags vormittag und einen Tag pro Woche ... länger... was ist richtig?
- "Mo-Fr 08:00-12:30, Th 13:30-18:00;" - oder
- "Mo-Fr 08:00-12:30; Th 08:00-12:30, 13:30-18:00; - oder
- "Mo-We,Fr 08:00-12:30; Th 08:00-12:30, 13:30-18:00;"
--cptechnik - DE:NRW:Windeck (talk) 10:51, 10 August 2014 (UTC)
- Alle drei Varianten sind richtig. Ich würde die erste Variante empfehlen … opening_hours=Mo-Fr 08:00-12:30, Th 13:30-18:00. Um zu prüfen, ob die Öffnungszeiten so ausgewertet werden, wie du dir das erhoffst kannst du auf dieser Seite prüfen.--Ypid (talk) 10:05, 21 August 2014 (UTC)
Und nach Vereinbarung
Wie kann das codiert werden? --Kayatim 16:31, 16 September 2011 (BST)
- Hier auf der deutschen Diskussion Seite scheint man relativ wenig Antworten zu bekommen. Ich empfehle die Frage auf der Mailingliste talk-de oder in Englisch auf der Mailingliste tagging bzw. der englischen Diskussionsseite zu stellen. --Saerdnaer 19:50, 25 September 2011 (BST)
- hab's so gemacht: opening_hours=nur nach Vereinbarung (es gibt ein ähnliches Beispiel, wo ein Text nach dem Oder-Zeichen || folgt)--Roald-linus (talk) 07:07, 11 November 2014 (UTC)
- @Roald-linus Das ist so nicht korrekt. Es gibt unter Beispiele ein entsprechendes Beispiel. Der korrekte Wert würde demnach so aussehen: opening_hours=Mo-Sa 08:00-13:00,14:00-17:00 || "sowie nach Vereinbarung" beziehungsweise so: opening_hours="nur nach Vereinbarung" --Ypid (talk) 16:30, 18 November 2014 (UTC)
- hab's so gemacht: opening_hours=nur nach Vereinbarung (es gibt ein ähnliches Beispiel, wo ein Text nach dem Oder-Zeichen || folgt)--Roald-linus (talk) 07:07, 11 November 2014 (UTC)
Öffnungszeit nur bei Tageslicht, nicht nachts
Z.B. wird der Wasserpark in Frankfurt bei Anbruch der Dunkelheit geschlossen, dass ist jeden Monat eine andere Uhrzeit. Hier scheint ein Tagging-Schema zu fehlen. --Jo (talk) 09:14, 13 November 2015 (UTC)
- Die Seite Key:opening hours/specification hat dawn | sunrise | sunset | dusk als Schlüsselwörter. --Zuse (talk) 09:25, 13 November 2015 (UTC)
Dead Link: osm24.eu
Die Domain osm24.eu stellt nicht mehr den gleichnamigen Kartendienst bereit. Ist der Dienst auf einer anderen Website verfügbar? -Fernerkunder (talk) 12:48, 10 August 2016 (UTC)
Wie kodiert man "jeden 2. Freitag" ?
Eine Tischlerei hat jeden zweiten Freitag geöffnet. Wie kann man das kodieren? --Josef73 (talk) 19:51, 29 March 2019 (UTC)
- So wie folgt, je nach dem, ob es der Freitag in der geraden (week 2-52/2 Fr 09:00-16:00) oder ungeraden Kalenderwoche (week 1-53/2 Fr 09:00-15:00) ist. Fabi2 (talk) 14:44, 18 December 2023 (UTC)
Öffnungszeiten unterschiedlicher Geschäftsbereiche
Ein Autohaus in der Nähe hat für Verkauf und Service abweichende Geschäftszeiten:
- Verkauf: Mo-Fr 08:00-18:30; Sa 09:00-16:00
- Service: Mo-Fr 07:00-18:00; Sa 09:00-13:00
Beide Bereiche befinden sich im selben Gebäude. Wie muss ich das codieren? - LWChris (talk) 09:30, 29 July 2019 (UTC)
- Ich glaube nicht, dass es dafür schon eine Lösung gibt. Ein mögliches Vorbild könnte opening_hours:kitchen=* für die Küchenzeiten von Restaurants sein. Vielleicht möchtest du eine Diskussion im Forum anstoßen? --Tordanik 14:20, 3 August 2019 (UTC)
- Schau mal in die Beispiele. Dort gibt es einen ähnlichen Fall: Dining in: 6am to 11pm; Drive thru: 24/7 -> 06:00-23:00 open "Dining in" || 00:00-24:00 open "Drive-through" analog zu Deinem Fall müßte es so sein: Mo-Fr 08:00-18:30; Sa 09:00-16:00 open "Verkauf" || Mo-Fr 07:00-18:00; Sa 09:00-13:00 open "Service" --Thetornado76 (talk) 21:55, 3 August 2019 (UTC)
- Sinnvollerweise sollte man, wenn möglich bzw. sinnvoll, die POIs immer separat eintragen, da die oder-Regeln mit "||" ja nur gelten, wenn das was vor den Strichen steht, nicht gilt. Somit wird dann immer ein Teil der Regel, bei überlappenden Bereichen nicht angezeigt, weil die Software sich da für die erste geltende Regel entscheidet. Also besser einen passenden Subtag finden bzw. kreieren (z.B. opening_hours:selling=*), wie schon geschrieben. Fabi2 (talk) 21:57, 18 December 2023 (UTC)
unregelmäßige Öffnungszeiten
An unserer Gartenkneipe steht "keine regulären Öffnungszeiten" sprich man muss anrufen oder es einfach versuchen.
Wie taggt man das?
Jochen Jo (talk) 13:48, 10 July 2022 (UTC)
- Interessante Frage, ich hab nicht so viel Erfahrung mit solchen Sonderfällen, aber ich würde tatsächlich folgendes vorschlagen:
- "keine regulären Öffnungszeiten"
- Scheint auch valide zu sein: https://openingh.openstreetmap.de/evaluation_tool/?EXP=%22keine%20regul%C3%A4ren%20%C3%96ffnungszeiten%22&lat=48.7769&lon=9.1844&mode=0
- --Nickel715 (talk) 11:53, 18 December 2023 (UTC)
Darstellung Sommer-/Winterzeit in OsmAnd
Hallo,
es gibt hier die Vorlage Mar Su[-1] - Oct Su[-1] - 1 day Mo-Su 14:00-17:00, Oct Su[-1] - Mar Su[-1] - 1 day Mo-Su 14:00-16:00 für Öffnungszeiten abhängig von Sommer- und Winterzeit.
In OsmAnd wird dieses unpassender Weise als März-Okt. und Jan.-März, Okt.-Dez. dargestellt, was ja nicht korrekt ist im Sinne von Sommer-/Winterzeit.
Das einzige, was noch etwas helfen würde, wäre das Hinzufügen der Comments "(Sommerzeit)" und "(Winterzeit)" zu den opening_hours. Das würde aber auch nur zu März-Okt. ... (Sommerzeit) bzw. Jan.-März, Okt.-Dez. ... (Winterzeit) führen, was ja auch nicht in sich korrekt bzw. verwirrend wäre.
Gibt es da eine Möglichkeit, anstelle März-Okt. Sommerzeit und anstelle Jan.-März, Okt.-Dez. Winterzeit schreiben zu lassen?
- Menschliche Interpretationen wie Sommer- und Winterzeit werden von Anwendugen nie angezeigt werden, aber wenn sie gut sind, dann machen sie aus dem Beispiel folgende Beschreibung:
Vom letzten Sonntag im März bis zum Sonnabend vor dem letzten Sonntag im Oktober täglich von 14:00-17:00 Uhr.
Vom letzten Sonntag im Oktober bis zum Sonnabend vor dem letzten Sonntag im März täglich von 14:00-16:00 Uhr. - Weil das bedeuten die Regeln im Beipiel letztendlich und die Menschen nennen es dann Sommerzeit und Winterzeit. Fabi2 (talk) 22:56, 23 September 2024 (UTC)
- Danke für den Hinweis mit dem fehlenden open. Des Weiteren musste ich feststellen, dass OsmAnd keine Klammern ( und ) im Kommentar mag.
Die vollständige Vorlage wäre also Mar Su[-1] - Oct Su[-1] - 1 day Mo-Su 14:00-17:00 open "Sommerzeit", Oct Su[-1] - Mar Su[-1] - 1 day Mo-Su 14:00-16:00 open "Winterzeit"
Nicht prickeln, aber etwas lindernd --HeiKue (talk) 13:46, 24 September 2024 (UTC)- Generell ist als Kommentar alles erlaubt, außer dem Hochkomma, Escaping wird nicht unterstützt. Dann noch generell hier mal der Hinweis, daß wenn die Anwendung die Öffnungszeiten-Syntax korrekt auswertet, es egal ist, ob die Umwandlung in eine menschliche Beschreibung eine sinnvolle oder vollständige Darstellung ergibt. Weil die ganze Syntax baut auf dem Tag als Grundeinheit auf, und innerhalb des Tages dann auf Minuten als Einheit. Wenn die Anwendung z.B. den heutigen und die kommenden Tage, vergleichbar mit dem Auswertewerkzeug, richtig anzeigt, dann ist es auch egal, ob die menschenlesbare Beschreibung vollständig bzw. sinnvoll ist, vorrausgesetzt die komplette Syntax wird für die Auswertung unterstützt. OsmAnd war da, zumindest früher, wohl nicht so gut. Fabi2 (talk) 20:55, 24 September 2024 (UTC)
- Danke für den Hinweis mit dem fehlenden open. Des Weiteren musste ich feststellen, dass OsmAnd keine Klammern ( und ) im Kommentar mag.