Öffnungszeiten

Wäre schade. Man muss schon aufpassen, dass OSM nicht zu einem Bastelprojekt verkommt.

Siehe auch den Thread zum Zusatzzeichen für den Spurassi. Da gibt's auch keine Hemmungen mal
eben das Semikolon umzudefinieren und damit bestehende Anwendungen inkompatibel zu machen.

Netzwolf wrote:

Die OpeningHours sind kompliziert genug. Ich halte die Existenz mehrerer inkompatibler Implementierungen für gefährlich, und ziehe deshalb meine Implementation und die zugehörigen Seiten zurück.

chris66 wrote:

Siehe auch den Thread zum Zusatzzeichen für den Spurassi. Da gibt's auch keine Hemmungen mal
eben das Semikolon umzudefinieren und damit bestehende Anwendungen inkompatibel zu machen.

Welche Anwendung meinst Du?

Keine konkrete Anwendung. Bisher war in OSM halt das Semikolon als Trennzeichen bei mehreren Values etabliert.
Und nun soll das Doppelsemikolon eine Sondersemantik bekommen. Kann aber auch sein dass
ich was falsch verstanden habe. 😉

chris66 wrote:

Keine konkrete Anwendung. Bisher war in OSM halt das Semikolon als Trennzeichen bei mehreren Values etabliert.
Und nun soll das Doppelsemikolon eine Sondersemantik bekommen. Kann aber auch sein dass
ich was falsch verstanden habe. 😉

Siehe es mal anders. A;;B = A;NULL;B bleibt weiterhin eine Aufzählung. Ob und wie eine Anwendung den Null-Wert berücksichtigt, kann ja Anwendung für sich entscheiden.

Aber um mal zum Thema zurück zu kommen. Ich finde es auch schade und kann das Argument "Ich halte die Existenz mehrerer inkompatibler Implementierungen für gefährlich" nicht verstehen. Wenn es nur eine Implementierung gibt, macht man sich von dieser abhängig und im Zweifel kann diese dann das Schema diktieren

SunCobalt wrote:

chris66 wrote:

Siehe auch den Thread zum Zusatzzeichen für den Spurassi. Da gibt's auch keine Hemmungen mal
eben das Semikolon umzudefinieren und damit bestehende Anwendungen inkompatibel zu machen.

Welche Anwendung meinst Du?

Es gibt eine alternative Implementierung. https://github.com/ypid/opening_hours.js/tree/master

Ich kann ja verstehen, dass er gerne nur eine einzige Library als authorativ hätte, aber ich habe seine Seite hauptsächich genutzt, um meine eingetragenen opening_hours zu verifizieren, da der Editor für JOSM davon nur ein sehr kleines Subset unterstützt.
Mir sieht das ein wenig nach einer übereifrigen Reaktion aus, aber nun gut, zum Glück kann man die alte Testseite aus dem Repository extrahieren.

Moins,

geri-oc wrote:

Es wird auf eine Seite verwiesen, die ich nicht verstehe (will und kann). Ich hoffe nur das die derzeitigen Angaben im WIKI erhalten bleiben. Oder soll alles "umgestrickt" werden?

Anlass für die Abschaltung ist diese geplante Ergänzung zu JOSM zusammen mit der neuen Implementation.

Die neue Implementation ist technisch *deutlich* besser als meine, damit spricht alles für eine Umstellung auf diese. Jedoch akzeptiert sie eine weiter gefasste Sprache, was im Widerspruch steht zu meinem Ziel, die Definition so eng wie möglich zu halten. Ich habe versucht, eine Änderung zu erreichen – erfolglos.

Gegen das Argument “kommt aber n mal in den Daten vor” stehe ich mit meinem “dann muss das halt n mal repariert werden” schlecht da; ohnehin ist das Bestehen auf fixen Spezifikationen zur Erleichterung der Auswertung in der OSM-Welt eher ungerne gesehen.

Deshalb mache ich lieber den Weg frei™.

Das Hosting der neuen Implementierung auf GITHUB macht eine Beteiligung der Community an der Weiterentwicklung besonders einfach. Jedenfalls in der Theorie.

Die Online-Auswertung und die Karten werden basierend auf der neuen Version sicher wiederkommen. Ich bitte darum, ypid bei der Erstellung der Seiten, speziell bei der Erstellung eines Vector-Overlays mit Popupboxen aus Overpass-Daten zu unterstützen.

Gruß Wolf

Ich bin vermutlich nicht der einzige, der hier nicht durchblickt.

Verstehe ich das richtig: Bei JOSM wird es eine neue Komponente geben, die vor dem Upload überprüft, ob die Werte in opening_hours=* sinnvoll sind? Und Netzwolfs Definition von "sinnvoll" ist enger gefasst, als die der Autoren der neuen Komponente?

Harald.

Wo finde ich eine entsprechend WIKI-Seite über die Verwendung?
Ich war sehr erstaunt, einen etablierten Schlüssel nicht mehr benutzen zu können - vor allem wurde und konnte er ausgewertet verwendet werden.

Netzwolf wrote:

Die neue Implementation ist technisch *deutlich* besser als meine, damit spricht alles für eine Umstellung auf diese. Jedoch akzeptiert sie eine weiter gefasste Sprache, was im Widerspruch steht zu meinem Ziel, die Definition so eng wie möglich zu halten. Ich habe versucht, eine Änderung zu erreichen – erfolglos.
Gegen das Argument “kommt aber n mal in den Daten vor” stehe ich mit meinem “dann muss das halt n mal repariert werden” schlecht da; ohnehin ist das Bestehen auf fixen Spezifikationen zur Erleichterung der Auswertung in der OSM-Welt eher ungerne gesehen.

Hmm... Wenn du die Spezifikation exakt anwendest und die da etwas lockerer sind, dann solltest du imo deine Implementierung trotzdem weiter anbieten. Sonst kann das doch niemand "n mal reparieren"?

Also eine Consumer-Edition und eine QA-Edition 😄

@geri-oc: Du hast bei beiden deiner Antworten was falsch verstanden 😉

Ich bin der Meinung, dass die offizielle Implementierung so liberal wie möglich Regeln verstehen sollte, eine Prüfung in JOSM oder eben eines Prüfungstools hingegen sollte immer darauf getrimmt sein, dass man sich exakt an die Specs hält. Postels Law halt.
Oder in anderen Worten: „Also eine Consumer-Edition und eine QA-Edition“ ;o)

Nahmd,

Nadjita wrote:

Ich bin der Meinung, dass die offizielle Implementierung so liberal wie möglich Regeln verstehen sollte, eine Prüfung in JOSM oder eben eines Prüfungstools hingegen sollte immer darauf getrimmt sein, dass man sich exakt an die Specs hält. Postels Law halt.
Oder in anderen Worten: „Also eine Consumer-Edition und eine QA-Edition“ ;o)

Hic Rhodos, hic salta.

Gruß Wolf

rayquaza wrote:

...

@geri-oc: Du hast bei beiden deiner Antworten was falsch verstanden 😉

Sag das mal dem Übersetzer(programm) - englisch hatte ich nie.

Netzwolf wrote:

Anlass für die Abschaltung ist diese geplante Ergänzung zu JOSM zusammen mit der neuen Implementation.

Beides leider kein Ersatz für Deine QA-Karte. (siehe auch: http://www.openstreetmap.org/user/MKnight/diary/20045 )

Das Hosting der neuen Implementierung auf GITHUB macht eine Beteiligung der Community an der Weiterentwicklung besonders einfach. Jedenfalls in der Theorie.

Hab mir das heute mal angeschaut, und muss mir da node.js installieren um überhaupt etwas weiter zu kommen, als die SPEC zu checken. Jemand der Opening_hours baut braucht das (imho) genau nicht.

Edit: +leider

Ich finde es auch sehr schade, dass du die Karte abgeschaltet hast. Soweit ich dich verstehe, sind die Implementierungen ja auch nicht inkompatibel, sondern halt nur in eine Richtung kompatibel: Was deine Implementierung versteht, versteht die Neue auch. Außerdem verstehe ich das JOSM Ticket so, dass man gerne deine Variante eingebaut hätte und dass die Entscheidung, stattdessen die andere zu verwenden von dir ausging - ich finde aber, dass Nadjita da vollkommen recht hat, dass der Validator ruhig deine strengere Auslegung verwenden könnte. Vielleicht könnte man ja auch mit einer kurzfristigen Aktion einen Großteil der Werte in der Datenbank, die die neue Implementierung akzeptiert, du aber nicht, auf deinen strengeren Standard korrigieren, dann würde das Argument mit den vielen nicht akzeptierten Einträgen wegfallen. Ich meine mich auch zu erinnern, dass deine Implementierung unterschieden hat zwischen Werten, die sie nicht verstehen kann und solchen, die zwar nicht den exakten Anforderungen entsprechen, aber trotzdem verständlich sein (Bsp. deutsche Tagesnamen, etc.), wenn man mit diesem "nicht wirklich korrekt, aber versändlich"-Zustand alle Fälle, bei denen sich die beiden Implementierungen unterscheiden abdecken könnte, würde ich sie auch nichtmehr als inkompatibel bezeichnen - dann kann ja der Validator für den einen Fall Fehler und für den anderen Warnungen ausspucken.
Dass die neue Implementierung technisch besser ist, sehe ich auch nicht als Argument. Was funktioniert, ist ausreichend gut, und dass sie funktioniert, hat deine Implementierung ja bewiesen. Und es hindert dich ja auch niemand, sie zu verbessern.
Außerdem finde ich über deine Implementierung hinaus schade, dass auch die Dokumentation dazu jetzt weg ist, die fand ich nämlich sehr nützlich - und sie wäre es immernoch, denn wenn jemand die genaue Syntax wissen will oder eine weitere Implementierung anfängt, wäre sie eine gute Basis - Sonderfälle und Ausnahmen kann man dann immernoch nach eigenem Gutdünken zufügen, auch wenn sie bei dir nicht erwähnt sind.
Zu guter Letzt würde ich mich auch freuen, wenn die Karte wieder online ginge, im Zweifelsfall mit der neuen Implementierung als Basis, denn mir ist keine vergleichbare Karte bekannt und es wäre schade, wenn es keine mehr gäbe.

errt wrote:

Zu guter Letzt würde ich mich auch freuen, wenn die Karte wieder online ginge, im Zweifelsfall mit der neuen Implementierung als Basis, denn mir ist keine vergleichbare Karte bekannt und es wäre schade, wenn es keine mehr gäbe.

Es gibt jetzt eine neue Öffnungszeitenkarte:
normaler Modus
Qualitätssicherung Modus

Ansonsten stimme ich errt zu.
Netzwolf, bitte stell die Dokumentation und den Validator wieder online!

• Wir wollen sehen bei welchen Werten sich dein Validator von dem neuen unterscheidet
• Der neue nimmt Bezug auf deine Dokumentation, diese Links führen derzeit leider ins leere
• Der neuen Karte fehlen noch collection_times und service_times

phobie wrote:

errt wrote:

Zu guter Letzt würde ich mich auch freuen, wenn die Karte wieder online ginge, im Zweifelsfall mit der neuen Implementierung als Basis, denn mir ist keine vergleichbare Karte bekannt und es wäre schade, wenn es keine mehr gäbe.

Es gibt jetzt eine neue Öffnungszeitenkarte:
normaler Modus
Qualitätssicherung Modus

Oops, die liegt aber völlig daneben! Da stimmt fast nix.

bei "Mo-Su 10:00-14:00,17:30-22:00" kommt "Die Einrichtung ist jetzt geschlossen aber wird heute, 20 Oktober, in 3 Stunden und 30 Minuten öffnen."

oder noch einfacher:
"Mo-Su 10:30-18:00" -> "Die Einrichtung ist jetzt geschlossen aber wird morgen, 21 Oktober, in 16 Stunden und 30 Minuten öffnen."
Da ist jetzt offen und morgen ist der 10. Oktober. Hab extra nochmal auf die Uhr und in den Kalender geschaut 😉

Ich hab mir die neue Syntax noch nicht angesehen; mag sein, dass die Beispiele einfach nur zu einfach sind.

Gruss
walter

wambacher wrote:

Oops, die liegt aber völlig daneben! Da stimmt fast nix.

Beim mehrmaligen herüberfahren mit der Maus über den Marker wird der Tag hochgezählt. Da scheint irgendwo ein Bug zu sein.
Die Fenster können auch kleiner... 🙂

Sven

Kleine Frage am Rande: Der Validator von Netzwolf hat mir folgenden String nicht angekreidet, der neue schon:

opening_hours=Mar␣Su[-1]␣-␣Oct␣Su[-1]-1␣days:␣Mo-Fr␣10:00-13:00,15:00-19:00;␣Sa␣10:00-15:00;␣Oct␣Su[-1]␣-␣Mar␣Su[-1]-1␣days:␣We-Fr␣15:00-18:00;␣Sa␣10:00-14:00

Die meldung ist: „Mar Su[-1] - <--- (Unexpected token: "-" This means that the syntax is not valid at that point.)“ doch genau dieser Teil stammt aus dem deutschen Wiki. Wie wäre es denn nun korrekt?

ps. Das ist ein Fahrradladen, die haben wirklich so komische Öffnungszeiten ;o)

phobie wrote:

Es gibt jetzt eine neue Öffnungszeitenkarte:

Die wertet keine Geschäfte aus, die als Flächen gemappt sind (bei Supermärkten sehr häufig).

Nahmd,

Nadjita wrote:

opening_hours=Mar␣Su[-1]␣-␣Oct␣Su[-1]-1␣days:␣Mo-Fr␣10:00-13:00,15:00-19:00;␣Sa␣10:00-15:00;␣Oct␣Su[-1]␣-␣Mar␣Su[-1]-1␣days:␣We-Fr␣15:00-18:00;␣Sa␣10:00-14:00

Die meldung ist: „Mar Su[-1] - <--- (Unexpected token: "-" This means that the syntax is not valid at that point.)“ doch genau dieser Teil stammt aus dem deutschen Wiki. Wie wäre es denn nun korrekt?

In der Original-Spezifikation gab es Offsets zu "n. Wochentag in Monat" überhaupt nicht. Die brauchte ich aber, um Sommerzeit/Winterzeit und Feiertage vor Weihnachten ausdrücken zu können.

Ich hab dazu die “±n days” Schreibweise eingeführt (ebenso wie ±hh:mm hours für den Offset zu Sonnenaufgang und Sonnenuntergang).

Ich nehme an, dass die neue Implementierung zu diesem Zwecke Klammern benutzt, Du also “Mar Su[-1] - (Oct Su[-1] - 1)” schreiben musst.

Gruß Wolf

Nahmd,

Thomas8122 wrote:

Die wertet keine Geschäfte aus, die als Flächen gemappt sind (bei Supermärkten sehr häufig).

Ways und Relationen haben per se keine Koordinaten. Du musst also auch die Komponenten bestellen und dann rechnen.

Vielleicht bittet mal jemand den Roland Olbricht, zusätzlich zu node, way und relation auch nennen wir es mal "feature" anzubieten, was dann alle drei Objektklassen liefert und zu Ways und Relationen den Schwerpunkt/Mittelpunkt/younameit als Koordinate (”all-to-node”).

Das würde ganz allgemein die Erstellung von POI-Themenkarten vereinfachen.

Gruß Wolf

Also auf der englischen Wiki-Seite gibt es kein Konstrukt, mit welchem man Sommer/Winterzeit abbilden kann und auch im Quellcode finde ich nichts, da keine Ranges Month Day[-1] - Month Day[-1] erlaubt sind. Weiterhin wird 18:00-22:00+ angemeckert, obwohl laut Wiki richtig. Bin ein wenig enttäüscht :-\

phobie wrote:

Es gibt jetzt eine neue Öffnungszeitenkarte:
normaler Modus
Qualitätssicherung Modus

Ok, zumindest gibt es eine. Aber mal abgesehen von Bugs und weniger Funktionalität scheint mir, dass Netzwolfs Karte schon bei niedrigeren Zoomstufen was angezeigt hat, oder? Ich erinnere mich, da relativ großflächig nach Fehlern gesucht zu haben, das geht auf Zoomstufe 14 kaum. Auch von der Farbgebung bin ich nicht ganz überzeugt. Netzwolf hatte AFAIR rot für Fehler und grau für geschlossen, oder? Scheint mir sinnvoller, weil man Fehler besser findet und gerade geschlossene Einrichtungen eher uninteressant sind.

Hi!

bei der Frage nach dem Feature aus Nr. 23 von Wolf stehe ich bei Roland alle paar Woche auf der Matte. Aber erst hat wohl auch das Problem ZEIT.

Gruß Jan

Guten Abend,

ich wollte nun auch mal meinen Senf dazu geben. Ich bin der Entwickler von opening_hours.js, dass hier ja recht kontrovers Diskutiert wird. Eins noch vorweg. Ich bin nicht der ursprüngliche Autor von der Bibliothek, dass haben wir AMDmi3 zu verdanken. Ich hab nur das Potential von dieser Implementierung erkannt und habe das ganze Salonfähig gemacht, beziehungsweise bin noch dabei. Jede Umstellung ist mit Komplikationen verbunden, aber ohne Veränderung kein Fortschritt.

Mit dem fehlen einer Online Karte wurde ich auch etwas überrascht. Als ich das Kontrollwerkzeug fertig hatte, wurden alle Informationen und Werkzeuge von Netzwolf offline genommen (mit dem ich mich über die Projektphase des öfteren ausgetauscht habe). Sein Argument hierfür ist für mich durchaus nachvollziehbar, allerdings hatte ich zu der Zeit noch keine funktionierende Karte am laufen. Deshalb hab ich in den letzten Tagen eine solche auf Basis von Netzwolfs Karte aufgebaut. Diese hat noch ein Problem, was sich hoffentlich mit Hilfe von Roland noch lösen lässt.

geri-oc wrote:

Es wird auf eine Seite verwiesen, die ich nicht verstehe (will und kann). Ich hoffe nur das die derzeitigen Angaben im WIKI erhalten bleiben. Oder soll alles "umgestrickt" werden?

Tut mir Leid, wenn sich die Seite deines Verständnisses entzieht, aber ich und AMDmi3 hielten es für die beste Lösung um das Projekt den Meisten zugänglich zu machen. Diese Seite ist allerdings mehr für Programmierer Interessant, als mapper bracht man die Seite nicht direkt zu verstehen beziehungsweise gibt es hier das Wiki.

Das Wiki hat weiterhin Gültigkeit. Das Thema Öffnungszeiten wurde/wird nur im Hinblick auf die Implementierung umgestrickt.

SunCobalt wrote:

Aber um mal zum Thema zurück zu kommen. Ich finde es auch schade und kann das Argument "Ich halte die Existenz mehrerer inkompatibler Implementierungen für gefährlich" nicht verstehen. Wenn es nur eine Implementierung gibt, macht man sich von dieser abhängig und im Zweifel kann diese dann das Schema diktieren.

Ich kann Netzwolf hier durchaus verstehen. Zwei „inkompatible“ Implementierungen für eine Sache sind nicht zielführend. Das Argument, dass man sich von einer Implementierung abhängig macht, ist nicht ganz von der Hand zu weisen. Allerdings war das ja quasi auch vor dem aufkommen von opening_hours.js der Fall. Jetzt gibt es wieder eine Implementierung (wenn man von Implementierungen in anderen Sprachen, die nicht diese Komplexität erreicht haben wie opening_hours.js und time_domain.js (von Netzwolf) absieht) mit der getestet werden kann und die einen gewissen Standard durchsetzt. Der unterschied ist allerdings, dass die Entwicklung in einem öffentlichen Repository abläuft, und jeder herzlich dazu eingeladen ist seine Verbesserungswünsche im Idealfall in Form eines „Pull requests“ an mich heranzutragen. Das Projekt wurde im wesentlichen von AMDmi3 und in den letzten Monaten von mir vorangetrieben. Falls jemand etwas stört bitte einen Fehlerreport schreiben oder direkt mit wirken. Allerdings wäre es gut, wenn wir keine redundante Syntax aufnehmen (zwei Schreibweisen um eine Sache auszudrücken), wie auch schon Netzwolf meinte. Ansonsten, wenn noch Dinge fehlen, die Sinn machen kann darüber Diskutiert werden.

Netzwolf wrote:

Die neue Implementation ist technisch *deutlich* besser als meine, damit spricht alles für eine Umstellung auf diese. Jedoch akzeptiert sie eine weiter gefasste Sprache, was im Widerspruch steht zu meinem Ziel, die Definition so eng wie möglich zu halten. Ich habe versucht, eine Änderung zu erreichen – erfolglos.

Wie vorher schon gesagt, macht eine Umstellung aus technischer Sicht absolut Sinn. Zu diesem Schluss wird wohl jeder kommen, dir sich beide Implementierungen anschaut. Netzwolfs Implementierung war nicht schlecht, sie hat sehr gute Dienste geleistet. Allerdings war der Code, zumindest für meinen Geschmack nicht so einfach Verständlich. Das Design von opening_hours.js ist um einiges Mächtiger und bietet eine reichhaltige API, die es Entwicklern (wie http://oeffnungszeiten.ulmapi.de/) erlaubt, Öffnungszeiten auszuwerten ohne sich um das Verarbeiten von opening_hours zu viele Gedanken zu machen. Dies kann sowohl im Browser als auch Server seitig mit node.js erfolgen. Aufgrund des Aufbaus ist diese JavaScript Bibliothek auch Ideal als Referenz Implementierung geeignet.

Zur weiter gefassten Sprache ist zu sagen, dass hier die Grundsteine von AMDmi3 gelegt wurden, der auf den Doppelpunkt komplett verzichtet hat, ihn sogar als Fehler angesehen hat. Ich habe die Auswertung so kompatibel zu Netzwolfs Spezifikation gemacht, wie möglich, allerdings bin ich in wenigen Punkten davon abgewichen.

Der Punkt auf den sich Netzwolf hier bezieht ist wohl das nicht prüfen ob der Doppelpunkt korrekt benutzt wurde. Der Grund hierfür ist, dass AMDmi3 diese für überflüssig hält und ich verstehe seine Ansicht. Allerdings benutze ich diese selbst und finde sie auch nicht verkehrt. Hier gibt es also zwei Herangehensweisen, was allerdings nicht schlimm ist, da der Doppelpunkt für die Auswertung nicht gebraucht wird, allerdings als stilistisches Mittel eingesetzt werden kann um den Überblick zu erhöhen. Falls irgendwann mal Klarheit herrscht ob dieser Angebracht ist oder nicht lässt sich mit opening_hours.js und der Funktion oh.prettifyValue sicher eine automatische Umstellung aller Werte erreichen (was ich zum jetzigen Zeitpunkt allerdings für nicht Notwendig erachte).

Eine zweite Abweichung ist noch die Berechnung von Zeiten basierend auf variablen Zeiten. Also um auszudrücken, dass irgendetwas eine halbe Stunde nach Sonnenaufgang öffnet. Netzwolf hat hier sunrise+00:30 hours vorgeschlagen und implementiert. Diese wurde allerdings nur 2 mal benutzt. "(sunrise+00:30)" wurde hingegen um die 14 mal benutzt. Ich halte diese Variante für übersichtlicher und die meisten Mapper scheinen mir zuzustimmen. Netzwolf wollte auf Klammern verzichten wegen Conditional restrictions zugleich hat er allerdings in Kommentaren keine Klammern in seiner Dokumentation verboten (wurden auch schon mehrmals verwendet). Ein Parser für Conditional restrictions muss damit rechnen verschachtelte Klammern zu finde.

Ansonsten ist die Syntax weitgehend Identisch. Es wurden noch einige Erweiterungen von mir Umgesetzt, welche in OSM benutzt wurden und meiner Ansicht nach Sinn machen und die nicht mit bisherigen Mitteln beschrieben werden konnten.

Netzwolf wrote:

Gegen das Argument “kommt aber n mal in den Daten vor” stehe ich mit meinem “dann muss das halt n mal repariert werden” schlecht da; ohnehin ist das Bestehen auf fixen Spezifikationen zur Erleichterung der Auswertung in der OSM-Welt eher ungerne gesehen.

Das Funktioniert allerdings nicht für Dinge, die sich mit dem vorhandenen Vokabular nicht ausdrücken lassen …
Falls es sich mit vorhandenen Mittel ausdrücken lässt sollte das getan werden, da stimme ich dir absolut zu. Aber beispielsweise ein Tag vor einem Feiertag konnte nicht ausgedrückt werden oder Feiertags aber nur wenn der Feiertag ein Montag ist. All das kann jetzt formuliert werden.

Ich werde keine Dinge implementieren, die sich bereits ausdrücken lassen.

Netzwolf wrote:

Die Online-Auswertung und die Karten werden basierend auf der neuen Version sicher wiederkommen. Ich bitte darum, ypid bei der Erstellung der Seiten, speziell bei der Erstellung eines Vector-Overlays mit Popupboxen aus Overpass-Daten zu unterstützen.

Unterstützung ist immer noch gerne gesehen: https://github.com/ypid/opening_hours_map

Nadjita wrote:

Ich bin der Meinung, dass die offizielle Implementierung so liberal wie möglich Regeln verstehen sollte, eine Prüfung in JOSM oder eben eines Prüfungstools hingegen sollte immer darauf getrimmt sein, dass man sich exakt an die Specs hält. Postels Law halt.
Oder in anderen Worten: „Also eine Consumer-Edition und eine QA-Edition“ ;o)

Ich stimme dir absolut zu und auch Netzwolf hat Öffnungszeiten ausgewertet, die nicht dem Standard entsprachen. Er hat nur eine Warnung ausgegeben. Das gleiche tue ich auch. Ich versuche auch Regeln durchzusetzen, allerdings möchte ich den Mapper auch unterstützen und ihm sagen, was er Falsch gemacht hat. Ich gehe sogar noch einen Schritt weiter als Netzwolf und generiere einen korrekten opening_hours Wert aus einem nicht korrekten, vorausgesetzt natürlich, meine Fehlertoleranz (basiert auf der von Netzwolf) erkennt, was gemeint ist. Was meiner Ansicht nach schon recht brauchbar ist.

geri-oc wrote:

Sag das mal dem Übersetzer(programm) - englisch hatte ich nie.

Übersetzungen in andere Sprachen von den neuen Möglichkeiten werden folgen. Ich kann nicht parallel in mehreren Sprachen eine Dokumentation schreiben. Ist immer hin ein Hobby. Falls du mir in der Hinsicht ein Stellenangebot zukommen lassen kannst … 😄 Englisch hatte/hat Priorität.

Zugleich hallte ich es für Sinnvoll die Spezifikationen von Netzwolf (die ich auch sehr zu schätzen wusste) ins Wiki zu übernehmen und auf die aktuellen Gegebenheiten anzupassen.

streckenkundler wrote:

Beim mehrmaligen herüberfahren mit der Maus über den Marker wird der Tag hochgezählt. Da scheint irgendwo ein Bug zu sein.
Die Fenster können auch kleiner... 🙂

Ist mir auch aufgefallen und hab es mittlerweile korrigiert.

Nadjita wrote:

Kleine Frage am Rande: Der Validator von Netzwolf hat mir folgenden String nicht angekreidet, der neue schon:

opening_hours=Mar␣Su[-1]␣-␣Oct␣Su[-1]-1␣days:␣Mo-Fr␣10:00-13:00,15:00-19:00;␣Sa␣10:00-15:00;␣Oct␣Su[-1]␣-␣Mar␣Su[-1]-1␣days:␣We-Fr␣15:00-18:00;␣Sa␣10:00-14:00

Die meldung ist: „Mar Su[-1] - <--- (Unexpected token: "-" This means that the syntax is not valid at that point.)“ doch genau dieser Teil stammt aus dem deutschen Wiki. Wie wäre es denn nun korrekt?

ps. Das ist ein Fahrradladen, die haben wirklich so komische Öffnungszeiten ;o)

Ist mir bewußt. Ich hab solche Öffnungszeiten auch schon in OSM gesehen. Werde ich noch implementieren.

Netzwolf wrote:

Nadjita wrote:

opening_hours=Mar␣Su[-1]␣-␣Oct␣Su[-1]-1␣days:␣Mo-Fr␣10:00-13:00,15:00-19:00;␣Sa␣10:00-15:00;␣Oct␣Su[-1]␣-␣Mar␣Su[-1]-1␣days:␣We-Fr␣15:00-18:00;␣Sa␣10:00-14:00

Die meldung ist: „Mar Su[-1] - <--- (Unexpected token: "-" This means that the syntax is not valid at that point.)“ doch genau dieser Teil stammt aus dem deutschen Wiki. Wie wäre es denn nun korrekt?

In der Original-Spezifikation gab es Offsets zu "n. Wochentag in Monat" überhaupt nicht. Die brauchte ich aber, um Sommerzeit/Winterzeit und Feiertage vor Weihnachten ausdrücken zu können.

Ich hab dazu die “±n days” Schreibweise eingeführt (ebenso wie ±hh:mm hours für den Offset zu Sonnenaufgang und Sonnenuntergang).

Ich nehme an, dass die neue Implementierung zu diesem Zwecke Klammern benutzt, Du also “Mar Su[-1] - (Oct Su[-1] - 1)” schreiben musst.

Gruß Wolf

Nein.

opening_hours=Mar␣Su[-1]␣-␣Oct␣Su[-1]-1␣days:␣Mo-Fr␣10:00-13:00,15:00-19:00;␣Sa␣10:00-15:00;␣Oct␣Su[-1]␣-␣Mar␣Su[-1]-1␣days:␣We-Fr␣15:00-18:00;␣Sa␣10:00-14:00

Sieht so wie es ist gut aus und wird noch rein kommen. Falls das jemand beschleunigen will, ist immer gerne gesehen.
Noch ein Hinweis zu diesen Öffnungszeiten: "; Sa 10:00-15:00;" wird zu keiner Zeit zutreffen, da es immer von "Sa 10:00-14:00" überschrieben wird. Dieser Wert müsste so umgeschrieben werden:

opening_hours=Mar␣Su[-1]␣-␣Oct␣Su[-1]-1␣days:␣Mo-Fr␣10:00-13:00,15:00-19:00;␣Mar␣Su[-1]␣-␣Oct␣Su[-1]-1␣days:␣Sa␣10:00-15:00;␣Oct␣Su[-1]␣-␣Mar␣Su[-1]-1␣days:␣We-Fr␣15:00-18:00;␣Oct␣Su[-1]␣-␣Mar␣Su[-1]-1␣days:␣Sa␣10:00-14:00

falls das so gemeint ist.

Nadjita wrote:

Also auf der englischen Wiki-Seite gibt es kein Konstrukt, mit welchem man Sommer/Winterzeit abbilden kann und auch im Quellcode finde ich nichts, da keine Ranges Month Day[-1] - Month Day[-1] erlaubt sind. Weiterhin wird 18:00-22:00+ angemeckert, obwohl laut Wiki richtig. Bin ein wenig enttäüscht :-\

"18:00-22:00+" ist mir aufgefallen, allerdings ist hier die Frage, ob man das nicht auch anders ausdrücken könnte. Dieses Konstrukt wird aktuell 55 mal benutzt.

-\s*\d{1,2}[:.]\d{2}\s*\+

errt wrote:

phobie wrote:

Es gibt jetzt eine neue Öffnungszeitenkarte:
normaler Modus
Qualitätssicherung Modus

Ok, zumindest gibt es eine. Aber mal abgesehen von Bugs und weniger Funktionalität scheint mir, dass Netzwolfs Karte schon bei niedrigeren Zoomstufen was angezeigt hat, oder? Ich erinnere mich, da relativ großflächig nach Fehlern gesucht zu haben, das geht auf Zoomstufe 14 kaum. Auch von der Farbgebung bin ich nicht ganz überzeugt. Netzwolf hatte AFAIR rot für Fehler und grau für geschlossen, oder? Scheint mir sinnvoller, weil man Fehler besser findet und gerade geschlossene Einrichtungen eher uninteressant sind.

Bitte beachten, dass ich eine Karte so schnell wie möglich wieder Online bringen wollte, nachdem die von Netzwolf offline genommen wurde und hier sicher noch Optimierungen möglich sind. Wenn dir etwas nicht gefällt, du hast die Möglichkeit es zu ändern.

Lübeck wrote:

bei der Frage nach dem Feature aus Nr. 23 von Wolf stehe ich bei Roland alle paar Woche auf der Matte. Aber erst hat wohl auch das Problem ZEIT.

Try harder 😉 (versuche es weiter)
Es muss natürlich nicht alles von Roland geschrieben werden, falls jemand diese Möglichkeit vermisst, bitte implementieren.

Sollte fürs erste Reichen, sorry für die Länge, aber wie Netzwolf schon meinte, das Thema ist sehr Komplex.

Vielen Dank fuer die ausfuehriche Stellungname. Das Einzige, was man dazu noch anmerken koennte waere: das alles waere besser gelaufen, wenn es im Vorfeld mal oeffentlich vorgestellt worden waere. So, wie es gelaufen ist, wirkte es ein wenig wie eine Hauruck-Aktion und alle waren ein wenig sprachlos. Aber nun gut, ueber verschuettete Milch soll man nicht jammern sagt der Amerikaner und Recht hat er.

ypid wrote:

"18:00-22:00+" ist mir aufgefallen, allerdings ist hier die Frage, ob man das nicht auch anders ausdrücken könnte. Dieses Konstrukt wird aktuell 55 mal benutzt.

Fuer mich drueckt 18:00+ nur aus: Ab 18:00 bis open end, aber keine Mindestoeffnungzeit garantiert. Man koennte das vielleicht als 18:00-22:00,22:00+ ausdruecken, aber so lange die Spec im Wiki 18:00-22:00+ erlaubt, sollte sich die neue "Referenzimplementierung" auch daran halten meine ich.

Nadjita wrote:

Vielen Dank fuer die ausfuehriche Stellungname. Das Einzige, was man dazu noch anmerken koennte waere: das alles waere besser gelaufen, wenn es im Vorfeld mal oeffentlich vorgestellt worden waere. So, wie es gelaufen ist, wirkte es ein wenig wie eine Hauruck-Aktion und alle waren ein wenig sprachlos. Aber nun gut, ueber verschuettete Milch soll man nicht jammern sagt der Amerikaner und Recht hat er.

In den vergangenen Wochen hatte das ganze eine ziemliche Dynamik entwickelt, ausgehend von meiner Auswerteseite und http://josm.openstreetmap.de/ticket/9157, und Netzwolfs Reaktion darauf.
Ich wollte erstmal vorlegen und beweisen, dass sich alles auch mit dieser komplexeren und mächtigeren Implementierung auswerten lässt.

Nadjita wrote:

ypid wrote:

"18:00-22:00+" ist mir aufgefallen, allerdings ist hier die Frage, ob man das nicht auch anders ausdrücken könnte. Dieses Konstrukt wird aktuell 55 mal benutzt.

Fuer mich drueckt 18:00+ nur aus: Ab 18:00 bis open end, aber keine Mindestoeffnungzeit garantiert. Man koennte das vielleicht als 18:00-22:00,22:00+ ausdruecken, aber so lange die Spec im Wiki 18:00-22:00+ erlaubt, sollte sich die neue "Referenzimplementierung" auch daran halten meine ich.

Das wurde gestern von Phobie rein geschrieben: Siehe Vergleich der Versionen (ist halt ein Wiki …)

Wenn ich das jetzt rein nehme tritt wohl der "Mircosoft-Effekt" auf, wie Netzwolf so schön meinte (wer das meiste akzeptiert, egal wie blödsinnig, der setzt sich durch). Was bei FOSS nicht das Ziel sein sollte. Eventuell sollten wir eine Abstimmung machen.

Moin

Wenn ich bei der neuen Öffnungszeitenkarte neben den 3 Editorlinks auf Details klicke kommt ein Fehlermeldung wie diese. Ich bild mir aber ein ,dass das schon mal funktionierte.

Gruß Thomas

Guten Tag,

Thomas8122 wrote:

Moin

Wenn ich bei der neuen Öffnungszeitenkarte neben den 3 Editorlinks auf Details klicke kommt ein Fehlermeldung wie diese. Ich bild mir aber ein ,dass das schon mal funktionierte.

Gruß Thomas

Der Link sollte so lauten: http://www.openstreetmap.org/browse/node/617408650

Grüße Steffen

Moin, das Beispiel im Wiki geht ohne Doppelpunkt hinter dem SH.

phobie wrote:

Qualitätssicherung Modus

In der Karte wird opening_hours=sunrise-sunset als Fehler bemängelt. Sicher ist das etwas ungenau. In der engl. Wiki steht das aber so. Wie sollte es denn besser heißen?

chris66 wrote:

Moin, das Beispiel im Wiki geht ohne Doppelpunkt hinter dem SH.

In der Karte kommt als Fehlertext: Holidays SH are not defined for country de and state Sachsen. Please add them. Wo kann ich die den hinzufügen. Doch bestimmt nicht am Objekt, oder?

Thomas8122 wrote:

In der Karte kommt als Fehlertext: Holidays SH are not defined for country de and state Sachsen. Please add them. Wo kann ich die den hinzufügen. Doch bestimmt nicht am Objekt, oder?

Hab das am Beispiel Frankreichs erstellt: http://www.openstreetmap.org/browse/relation/3263835 Sind natürlich erstmal bloß die nächsten Ferien zum testen.

Thomas8122 wrote:

chris66 wrote:

Moin, das Beispiel im Wiki geht ohne Doppelpunkt hinter dem SH.

In der Karte kommt als Fehlertext: Holidays SH are not defined for country de and state Sachsen. Please add them. Wo kann ich die den hinzufügen. Doch bestimmt nicht am Objekt, oder?

Eher nicht. Das muss wohl explizit in die Javascript Bibliothek aufgenommen werden, OSM Relationen spielen da keine Rolle.

https://github.com/ypid/opening_hours.js wrote:

Support for school holidays (SH 10:00-14:00).

• Currently only Germany can easily be supported (based on ical files from schulferien.org).
• To update the school holiday definition or add definitions for other countries (probably includes a little bit of adjustment of the script) the script convert_ical_to_json can be used to generate JSON definition based on ical calendar files, which can then be added to the library.

Na dann kann ich das ja wieder löschen.

Thomas8122 wrote:

Wenn ich bei der neuen Öffnungszeitenkarte neben den 3 Editorlinks auf Details klicke kommt ein Fehlermeldung wie diese. Ich bild mir aber ein ,dass das schon mal funktionierte.

geozeisig wrote:

phobie wrote:

Qualitätssicherung Modus

In der Karte wird opening_hours=sunrise-sunset als Fehler bemängelt. Sicher ist das etwas ungenau. In der engl. Wiki steht das aber so. Wie sollte es denn besser heißen?

Passt so.

Danke für die Hinweise. Ist korrigiert.

opening_hours␣=␣Mo-Th␣07:00-19:00;␣Fr␣07:00-16:00;␣SH:␣Mo-Fr␣08:30-15:00

"SH: Mo-Fr 08:30-15:00": Das trifft nur an Wochentagen (Mo-Fr) zu wenn Schulferien sind. Ich finde den Doppelpunkt gar nicht so schlecht. Parktisch funktioniert beides. Wie bereits gesagt, ignoriere ich den Doppelpunkt sowieso und wenn er beim Schreiben der Öffnungszeiten hilft stört es mich nicht.

couchmapper wrote:

Thomas8122 wrote:

chris66 wrote:

Moin, das Beispiel im Wiki geht ohne Doppelpunkt hinter dem SH.

In der Karte kommt als Fehlertext: Holidays SH are not defined for country de and state Sachsen. Please add them. Wo kann ich die den hinzufügen. Doch bestimmt nicht am Objekt, oder?

Eher nicht. Das muss wohl explizit in die Javascript Bibliothek aufgenommen werden, OSM Relationen spielen da keine Rolle.

https://github.com/ypid/opening_hours.js wrote:

Support for school holidays (SH 10:00-14:00).

• Currently only Germany can easily be supported (based on ical files from schulferien.org).
• To update the school holiday definition or add definitions for other countries (probably includes a little bit of adjustment of the script) the script convert_ical_to_json can be used to generate JSON definition based on ical calendar files, which can then be added to the library.

Korrekt. Ich habe besagtes Skript geschrieben, was das Thema Schulferien für Deutschland komplett erschlägt 😄
Da ich immer noch am Entwickeln bin, habe ich vorerst nicht alle Schulferien mit in opening_hours.js gepackt. Siehe auch Problem 7. Werde ich jetzt aber mal angehen.

So wie es scheint wertet die neue Karte nur Knoten, keine Flächen aus. Kann das sein? Und warum können nicht auch Flächen ausgewertet werden?

Zanderschiff wrote:

So wie es scheint wertet die neue Karte nur Knoten, keine Flächen aus. Kann das sein? Und warum können nicht auch Flächen ausgewertet werden?

siehe posting #21 und #23 in diesem Thread.

Hier ist ein Node mit fehlerhaften Daten. Leider kann man hier nix klicken um dies zu bereinigen.

http://robin.de.marissa.hostorama.ch/os … ning_hours

Dies tritt meist bei Warnungen auf. Bei Error ist es mir noch nicht aufgefallen.

Josef73 wrote:

Leider kann man hier nix klicken um dies zu bereinigen.

hä? schau mal unten rechts genau hin.

Gruss
walter

wambacher wrote:

hä? schau mal unten rechts genau hin.

versteh ich jetzt nicht. Wenn ich mit der Maus über den roten Kreis mit dem blauen W fahre, kommt kein Popup-Fenster, in dem ich auf JOSM klicken und dies dann bereinigen kann. Ich muss erst im JOSM die entsprechende Gegend suchen und dann den entsprechenden Node suchen und kann dann erst bereinigen. Bei einem Error geht dies mit dem Popup-Fenster.

siehe hier: http://robin.de.marissa.hostorama.ch/os … ning_hours

Josef73 wrote:

wambacher wrote:

hä? schau mal unten rechts genau hin.

versteh ich jetzt nicht.

Ich verstehe es ebenfalls nicht. Das fehlende Aufploppfenster habe ich auch schon vermisst.

er hat "Hier ist ein Node mit fehlerhaften Daten. Leider kann man hier nix klicken um dies zu bereinigen." geschrieben - und da kommt nun mal die OSM-Seite.

Gruss
walter

wambacher wrote:

er hat "Hier ist ein Node mit fehlerhaften Daten. Leider kann man hier nix klicken um dies zu bereinigen." geschrieben - und da kommt nun mal die OSM-Seite.

Gruss
walter

Ich hoffe der Beitrag #43 erklärt mein Problem.

Die Fehlerkonsole wirft mir bei hover:

Fehler:␣TypeError:␣tokens[nblock]␣is␣undefined
Quelldatei:␣http://robin.de.marissa.hostorama.ch/osm/opening_hours_map/opening_hours.js/opening_hours.js
Zeile:␣3103

aus. Das passiert bei einem Kreis, wo das Popup funktioniert, nicht.

efred wrote:

Zanderschiff wrote:

So wie es scheint wertet die neue Karte nur Knoten, keine Flächen aus. Kann das sein? Und warum können nicht auch Flächen ausgewertet werden?

siehe posting #21 und #23 in diesem Thread.

Danke.

Wird sich da in nächster Zeit vielleicht was tun? Oder ist das eher utopisch?

Nahmd,

Zanderschiff wrote:

Wird sich da in nächster Zeit vielleicht was tun? Oder ist das eher utopisch?

Ein Forum ist zur Diskussion von gewünschten Software-Features und zum Melden von Fehlern völlig ungeeignet.

Sowohl die Entwicklung von opening_hours (Library und Seiten) als auch die der OverPass-API sind auf GitHub gehostet, einem großartigen Collaboration-Tool. Dort kann man sich kostenlos registrieren und danach sowohl Probleme und Wünsche melden als auch zur Beseitung von Issues und der Weiterentwicklung der Funktionalität beitragen.

OpenSource lebt vom Mitmachen.

Gruß Wolf

Tag,

MKnight wrote:

Die Fehlerkonsole wirft mir bei hover:

Fehler:␣TypeError:␣tokens[nblock]␣is␣undefined
Quelldatei:␣http://robin.de.marissa.hostorama.ch/osm/opening_hours_map/opening_hours.js/opening_hours.js
Zeile:␣3103

aus. Das passiert bei einem Kreis, wo das Popup funktioniert, nicht.

Problem ist behoben.

Netzwolf wrote:

Zanderschiff wrote:

Wird sich da in nächster Zeit vielleicht was tun? Oder ist das eher utopisch?

Ein Forum ist zur Diskussion von gewünschten Software-Features und zum Melden von Fehlern völlig ungeeignet.

Sowohl die Entwicklung von opening_hours (Library und Seiten) als auch die der OverPass-API sind auf GitHub gehostet, einem großartigen Collaboration-Tool. Dort kann man sich kostenlos registrieren und danach sowohl Probleme und Wünsche melden als auch zur Beseitung von Issues und der Weiterentwicklung der Funktionalität beitragen.

OpenSource lebt vom Mitmachen.

Ich stimme zu. Github ist hierfür sehr gut geeignet. Da AMDmi3 meine (zahlreichen) Änderungen noch nicht auf seinen Branch angewendet hat habe ich einen eigenen Bugtracker aufgemacht. Wenn Probleme vorliegen, einfach einen Problembericht reinschreiben, wenn etwas an der Grundfunktionalität nicht geht (also der Fehler auch mit der Demo Seite auftritt).

Falls etwas in der Karte nicht geht, gibt es schon seit bestehen der Karte einen entsprechenden Bugtracker.

ypid wrote:

Nadjita wrote:

ypid wrote:

"18:00-22:00+" ist mir aufgefallen, allerdings ist hier die Frage, ob man das nicht auch anders ausdrücken könnte. Dieses Konstrukt wird aktuell 55 mal benutzt.

Fuer mich drueckt 18:00+ nur aus: Ab 18:00 bis open end, aber keine Mindestoeffnungzeit garantiert. Man koennte das vielleicht als 18:00-22:00,22:00+ ausdruecken, aber so lange die Spec im Wiki 18:00-22:00+ erlaubt, sollte sich die neue "Referenzimplementierung" auch daran halten meine ich.

Das wurde gestern von Phobie rein geschrieben: Siehe Vergleich der Versionen (ist halt ein Wiki …)

Wenn ich das jetzt rein nehme tritt wohl der "Mircosoft-Effekt" auf, wie Netzwolf so schön meinte (wer das meiste akzeptiert, egal wie blödsinnig, der setzt sich durch). Was bei FOSS nicht das Ziel sein sollte. Eventuell sollten wir eine Abstimmung machen.

Ich habe eine Abstimmung im Wiki aufgemacht: http://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#Voting_addon_18:00-22:00.2B.

Falls eine Mehrheit zustimmt, werde ich es mit implementieren.

Ist mir ja ein wenig peinlich zu fragen, aber wie vote ich da? Direkt auf der Talk-Seite?

Nadjita wrote:

Ist mir ja ein wenig peinlich zu fragen, aber wie vote ich da? Direkt auf der Talk-Seite?

Im Wiki in dem betreff. Abschnitt auf Bearbeiten gehen (musst natürlich angemeldet/registriert sein) unter den Text {{vote|yes}} (oder no) , deine Signatur mit Zeitstempel und evtl. einen Kommentar hinterlassen, Vorschau gucken, wenn richtig dann speichern.

Gruß Thomas