aixbrick
August 12, 2026, 8:07am
1
Hallo zusammen,
nutzt hier jemand CoMaps? In Changeset: 187296521 | OpenStreetMap hat ein User die Öffnungszeiten mit CoMaps geprüft. Dabei wurde der Wert von opening_hours verkürzt und u.a. die Angabe für PH gelöscht. Bevor ich den User frage bzw. darauf hinweise: Hat jemand, der die App nutzt, das auch schonmal bemerkt? Ist das eine Fehlbedienung oder möglicherweise ein Bug, den der User nicht bemerkt?
Gruß
Negreheb
August 12, 2026, 8:32am
2
Ich hab den User über dessen CS hier geredet wird mal eingeladen :) Changeset: 187296521 | OpenStreetMap
aixbrick
August 12, 2026, 9:02am
3
Danke, hätte ich auch noch gemacht, wollte aber erstmal eine Einschätzung haben.
225059
August 12, 2026, 10:49am
4
Hallo,
ich habe mir das mal in CoMaps (iOS, Version 2026.07.25 (1)) angesehen und denke die Ursache liegt dort.
Bei „rs Möbel“ wird aus den Werten „Tu-Fr 10:00-19:00; Sa 10:00-18:00; Su, Mo, PH off“ das hier:
Wenn man den Eintrag bearbeiten möchte sieht das so aus:
Es lässt sich nicht eintragen, dass Mo und So geschlossen ist. Man kann nur Schließzeiten im Rahmen der Öffnungszeiten eintragen, also z.B. wenn ein Laden mittags geschlossen hat.
Im erweiterten Modus kann der Eintrag auch als Text frei vorgenommen werden, sieht dann wie auf dem nächsten Screenshot aus.
Unter den Beispielwerten wird außerdem beschrieben, dass man hier eintragen solle, wann geöffnet sei. Weiter unten (auf dem Screenshot leider nicht sichtbar) gibt es auch ein Beispiel mit geschlossenen Zeitpunkten:
„Mo-Su 10:00-19:00; Jun off; Dec 25 off
Ich denke das sollte bei CoMaps mal überarbeitet werden.
9_tab
August 12, 2026, 11:12am
5
I wonder if organicmaps has a similar problem. Would explain Changeset: 187171761 | OpenStreetMap
Dieser Thread wurde in der CoMaps Signal gruppe gemeldet und es gibt nun ein issue bei Codeberg
aixbrick
August 12, 2026, 11:54am
7
k4pl4n
August 15, 2026, 5:36am
8
Organic Maps hat jetzt den opening hours parser komplett ersetzt mit einem deutlich umfassenderen. Damit ist dort das Problem wahrscheinlich mit der nächsten Version behoben.
master ← ab/opening_hours
opened 08:15AM - 04 Jul 26 UTC
## What
Replaces the Maps.Me-era `opening_hours` parser and evaluator (a
`boost… ::spirit::qi` grammar plus an ad-hoc `rules_evaluation`) with a
self-contained, dependency-free **C++23 port of
[opening-hours-rs](https://github.com/remi-dupre/opening-hours-rs)**
(`libs/opening_hours/oh/parser.hpp` + `oh/eval.hpp`).
The port stays behind the existing `osmoh::OpeningHours` facade. A
`port ↔ osmoh` AST converter (`oh/convert.*`) keeps `GetRule()` intact,
so the **routing serialization format, the editor round-trip and transit
are unchanged** — no mwm format bump.
## Structure — how to review
Four commits, each with a self-contained message:
1. `[opening_hours] Remove the old boost::spirit parser` — pure deletion.
2. `[opening_hours] Port opening-hours-rs to C++23` — the port, the facade
move to `libs/opening_hours/`, its test suites and the 156k-value
real-world corpus (the corpus dominates the raw line counts; the code
to review is `oh/parser.hpp`, `oh/eval.hpp`, `oh/convert.*` and the
facade).
3. `[routing][generator] Adapt opening-hours wire code to the ported
evaluator` — the minimal wire-level adaptation (details below).
4. `[editor][android][ios] Adapt the editor and place pages to the ported
evaluator` — empty-string guards and include moves.
The remove/add split means intermediate commits intentionally do not
build standalone — squash-merge as one change, as agreed earlier.
## Why — bugs fixed
The old parser mis-parsed common real-world values and its evaluator had
several gaps. This fixes:
- **`Su,PH off` closes Sunday** instead of showing it open 24h.
Fixes #1575, #8365, #5078, #8218. Partially addresses #11509: Sunday is
fixed, but showing the public-holiday hours themselves needs the holiday
dates from #3883 (the evaluation context currently has an empty holiday
set, so `PH` never matches).
- **Spaced-comma time & selector lists** (`Tu-Fr 11:45-14:30, 19:00-21:45`,
`Su, Sa`), **spaced range dashes** (`Apr - May`) and **full/localized day
names** (`Mon-Fri`) now parse. Fixes #3888, #8198.
- **Additive rules** and **extended hours past midnight** now evaluate
correctly. Fixes #7523.
- **`closed`/`off`/`24/7 closed` no longer report as 24/7.**
Fixes #1274, #12876.
- **Year selectors** (`2016 Mo-Fr …`) now parse. Helps #2379, #219.
The port itself was hardened against real-world input along the way: an
out-of-bounds write on partial AST conversion (the Linux CI segfault),
a division by zero on oversized selector steps, a ~4-billion-iteration
hang on day-less month endpoints, and several dedup/printer bugs where
`GetRule()` printed a value that re-parses to a different schedule. All
port fixes are documented in the second commit's message and will be
offered upstream to opening-hours-rs.
## Routing/generator adaptation (commit 3)
- The wire decomposes one source rule into single-selector rules and the
port evaluates the spec's `;` override between rules, so `Deserialize`
now marks the decomposed parts with the additive `,` separator — a
multi-window conditional (`no @ (Mo-Fr 07:00-09:00,16:00-18:00)`) would
otherwise keep only its last window on existing maps.
- A latent bug is fixed: `DecomposeOh` overlaid a holiday onto the weekday
rule, so conditional access such as `Su,PH …` dropped the weekday part
entirely under `ForRouting()`; weekday ranges and holidays are now
serialized as a union of separate rules. The per-rule encoding is
unchanged.
- Open-ended year selectors (`2020+`), which the port materializes as end
year 9999, refuse gracefully instead of aborting map generation on the
`checked_cast` to the wire's 8-bit field (the old parser refused them
via its empty-end-year path).
The broader serialization hardening discussed in earlier review rounds
(refusing whole values the wire cannot represent losslessly) is
deliberately **not** in this PR anymore — it was split out to keep this
change reviewable. This PR only adapts the wire code to the port's
semantics.
## How tested (desktop)
- Library + all consumers build (editor, routing, search, transit,
generator); `opening_hours_tests`, `routing_tests`, `editor_tests` and
`generator_tests` pass.
- The port's own golden vectors (transcribed from the Rust suite) pass,
plus the restored pre-port `osmoh` facade regression suite.
- New regression tests: multi-window conditional evaluation after
deserialization, `Su,PH` decomposition under both serdes modes, and the
open-ended-year refusal.
- Parse coverage over the real-world corpus (`opening-count.lst`, an
extract of `opening_hours` values from the OSM planet, 156k patterns)
is 95% weighted; the remainder is genuinely invalid input.
- ASan-clean on the full `opening_hours_tests` + `routing_tests` suites.
- Android `assembleGoogleDebug` (arm64) and the iOS simulator archive
build green.
## Not in this PR (follow-ups on top of this branch)
- Gating schedules the simple editor cannot represent (sun events,
open-ended spans, holidays, nth weekdays) into the advanced editor —
ready as a small follow-up PR.
- The routing serialization hardening mentioned above.
- Wiring the evaluation context inputs the port already supports:
per-POI timezone (#1642), public-holiday dates (#3883) and coordinates
for real sunrise/sunset (#4186, #3457).
- Upstreaming the port fixes to opening-hours-rs.
Guten Abend,
…wenn ich es mir so richtig betrachte: dann produziert die Erweiterung OpeningHoursEditor für JOSM auch unvollständige Daten:
Ich kann hier zwar festlegen, wann eine Einrichtung geöffnet hat, nicht aber den Rest…
Bei meinem Beispiel: ist Mittwoch, Samstag, Sonntag und Feiertag geschlossen, kann ich aber nicht setzen, erscheint folglich also auch nicht in den Tags!
Das ist übrigens das DAK-Büro hier in Lübben…
Sven
streckenkundler:
nicht aber den Rest…
“off” muss man ja auch nicht unbedingt taggen da es sich automatisch ergibt. Oder meinst Du jetzt Freitext Angaben?
BrummsLee
August 16, 2026, 9:38pm
12
Vollkommen richtig @chris66 …
Negreheb
August 17, 2026, 3:59pm
13
Naja, so einfache Checkboxen darunter könnten hier doch sinnvoll sein, oder? Aber ich habs sonst auch oben manuell erweitert.
Lübeck
August 19, 2026, 4:13pm
14
es soll schon ein Ticket bei CoMaps zu dem Problem geben.
Jan
Ja, das wurde bereits in Post 7 hier verlinkt.
