I’ve added an update so that when you go to a region page it does a quick check to see if any of the items have been changed by someone else, then updates the page if it’s found them. So far just for the fixable ones, but I may do the same for the invalid ones later.
This should help you to avoid clashes with other mappers, especially helpful as the US community is doing a big job working through their fixes (although still number 1 for most errors).
Would be possible to exclude trivial ones, adding spaces or leading zeros?
These, if worth doing at all, should be probably done with bot edit rather than wasting human attention on them
EDIT: I agree with counterexample below
None of the suggestions should be purely adding or removing spaces, but spaces may change when some other edit is being done.
The issues of leading zeros led me to create this issue where Tu-Sa 9:00-6:00, Su-Mo 11:00-6:00 was being interpreted as Tu-Sa 09:00-06:00, Su-Mo 11:00-06:00. The fix seems good and now I think that similar such cases are being detected and not offered as suggestions. But I guess I’m not confident enough that all ambiguous cases are definitely excluded that a bot edit could proceed or that all suggested fixes of a missing zero are correct.
Thanks for looking into the above. Here a few additional points:
(a) In view of the deployment of the fix for Easter, I updated the value at Node: Museum Bruder Klaus (4600870435) | OpenStreetMap . I assume it will eventually disappear from OSM Opening Hours Validation Report - Obwalden
There is a similar one at Node: Musée du fer et du chemin de fer (1437661704) | OpenStreetMap . That one seems to struggle with “Oct” (instead of “Oct 31”) as well.
(b) Checking a subset of opening_hours, I found that that a quoted text included in the value or a text in description= sometimes should be in the syntax as well. Maybe there is a way to detect this. All samples are from defibrillators, but I’d assume it isn’t limited to these.
(c) Sometimes the entire value is in quotes:
(d) Is there a way to improve editing opening_hours in iD-editor? In my browser, the one-line field is just too small and the suggestions (from other values) tend to mess up my edits. I don’t think they help at all.
(e) Some French strings that get mistaken:
(e1) “Ma” to “Mo” (instead of “Tu”) at Node: Visage Coiffure (927270550) | OpenStreetMap
:Ma 09:00-18:30; Me-Ve 08:00-18:30; Sa 08:00-16:00
:Mo 09:00-18:30; We-Fr 08:00-18:30; Sa 08:00-16:00
Also for Node: La Boîte à Musique (2667902422) | OpenStreetMap
(e2) “Di” to “Tu” (instead of “Su”) at Node: La Balance'L (2009361766) | OpenStreetMap
:Sa,Di,Lu,Me,Je 09:00-17:00; Ve 09:00-23:00
:Sa,Tu,Mo,We,Th 09:00-17:00; Fr 09:00-23:00
Also for Node: City Kebab & Pizza (2389027998) | OpenStreetMap and Node: Le Ver Vert (6265306479) | OpenStreetMap
(f) Sur rendez-vous needs quotes at Node: Musée du Vieux Baulmes (3246854013) | OpenStreetMap . The tool could suggest a fix for that.
(g) The GUI of the tool uses two meanings of “Invalid Hours”. I found that confusing.
Yes, after the next release of opening_hours it should no longer be shown
I agree, using “Oct 31” is required, I believe
That sounds like a localised issue, specifically with the defikarte user/app.
As above, and the entire opening_hours being a comment is valid syntax, e.g. "by appointment" Unless it’s fairly common I can’t see it’s worth adding an extra check for this
An issue could be raised against iD, unless one already exists. I’ve had a suggestion to be able to edit the values directly on the site, via a textbox, which I may get round to implementing soon.
These should be better after some updates I’ve just been doing, which will be seen from tomorrow’s run.
Good point, I’ll suggest that upstream at the main parsing library
I assume you mean the difference between invalid in the sense of not fully correct and invalid in the section of so invalid that there’s no fix. Do you have a suggestion of better wording?
Thank you for making it check the autofix-suggested flags! That is an an amazing and very helpful feature, nice work. As another datapoint here, I think that it would be helpful to check the invalid ones as well. In some cases I pull up the POI’s website and open the evaluator tool to start reworking the invalid hours, only to finally load the POI in an editor and realize that it’s already been fixed.
I feel almost like language-based corrections should just be disabled. In my experience, they do more harm than good by making misleading suggestions. It would probably perform better if the language suggestions were localized to the region in which the POI is located (i.e. only apply French-language fixes in French-speaking areas) but that sounds like lots of effort.[1] Whenever I get a language-based correction suggested, I check it against this great Wikipedia page to make sure the correction is plausible—often it’s not, and it concerns me because I’m sure some users of the tool aren’t paying as much attention to these cases.
Maybe this is a more general shortcoming of the tool, but even if 99 people see an auto-fix, say “that’s suspicious, I won’t apply that fix,” and skip it, then 1 person can come along, and with just a single click, add the incorrect data. I think in an ideal world there would be an Osmose-style “False positive” button–but then we’re back to needing a database…
Or maybe not, because my vague impression of opening_hours.js is that it already might have some localization for SH and PH as shown on the evaluator tool? ↩︎
or listed separately?
or maybe have some known bad suggestion mixed in that if, accepted, would zero already accepted ones and remind user that blind clicking is unwelcome and harmful?
In my experience these language-based corrections were sole ones where I felt that I am actually improving data.
Yeah, I don’t know what a better workflow would be, but I just think that the way the language (in)corrections are currently displayed is pretty misleading. A separate list might be nice, or even some way to summon a relevant table of languages a la…
| en | pl |
|---|---|
| Sunday | Niedziela |
| Monday | Poniedziałek |
| Tuesday | Wtorek |
| Wednesday | Środa |
| Thursday | Czwartek |
| Friday | Piątek |
| Saturday | Sobota |
which I used while working on Poland. Because I love to feel
but I want to make sure that I’m getting the translations exactly correct.
I definitely would not confirm correctness of such edit if it would be in language not known to me at native speaker level
It is now also checking the invalid ones. In both cases it does a small sample to see if anything has changed before fetching all of them if anything is different. There’s a suggestion to add a button to force a refresh, in case the sample misses it, which I need to work out where to put and will then do.
This should now have been improved in the last couple of days after updating to the version that includes this
But I will still look at listing them separately.
Best case of 100 people looking at incorrect suggestion is that someone makes the correct edit…
(A) I was going to add a suggestion, but couldn’t think of an obvious one. Maybe as follows:
(B) Without fixing them, I don’t see how they could reasonably be parsed.
(C) Looking at Colombia (as it topped percentage-wise), it seemed Spanish matching isn’t ideal either, but then I don’t really understand some of the text values.
(D) In CH, they tend to be mixed between German and French, sometimes not consistent with the location. Possibly due to copies from the same language version of a country-wide website. Many fixes for German are correct, some for French too.
(E) I had to go back and check if hadn’t mis- clicked on some of the French ones ;) Maybe I should try to come up with some checks for syntactically correct, but unlikely combinations.
(F) Values “winter”, “summer”, etc: I understand why this is on the report, but sometimes that’s all that is known.
(G) Public holidays
A PH in the canton of Geneva (CH-GE) is “Jeûne genevois” on the “Thursday after first Sunday in September”. This seems to be missing in opening_hours.js/src/holidays/ch.yaml at main · opening-hours/opening_hours.js · GitHub It’s present in date-holidays/data/countries/CH.yaml at master · commenthol/date-holidays · GitHub mentioned as source there. For definition and dates in the next years: Jours fériés officiels | ge.ch Presumably this is something that should have been reported in github directly.
(H) “UH” in addition to “SH”?
For university related things, maybe this could be a solution.
Fair enough, I’ll have a think
Many of the fixes/parses are actually correct, but some are indeed wrong. I think they could be separated from the other fixes
Likewise, and I think the purpose of the parser isn’t necessarily to parse any free text value, but rather to correct errors where it is ‘almost’ correct syntax, to some definition of “almost”.
If it was literally like that, as a comment then that is valid syntax. If someone wants to denote certain “winter” hours and other “summer” hours then that’s a little challenging, but probably a fallback rule (||) would work.
Indeed
That would need to be proposed as an extension to the syntax, which only includes school and public holidays. The challenge with it would include the fact that university holidays are not likely to be as standardised as school holidays (although that could well be country dependent).
Another thing with Uni holidays is holidays for who - students or staff? Yes, students are away for ~4 months each year, but the staff are still at work, & most facilities (coffee shops, food places etc) are still operating.
Given that this is third party data anyway, just use the OSM object in your lookup to only return holidays that typically effect the facility (I would note that this is an evaluation not an validation issue and not quite sure why this is even being discussed here).
If they are a stand alone value Key:seasonal - OpenStreetMap Wiki is usually the right one for these, not opening_hours. Flagging these is OK, but the fix is not in changing opening_hours (if there is no better value to be found) it is in using the right key.
Some easy cases that could savely be shown as fixable are things like “permanently closed”, “fermé définitivement”, “dauerhaft geschlossen” and similar wordings in other languages.
I don’t know of course if it’s possible/feasable to integrate such checks.
I don’t believe those should be in opening hours. That POI should probably de removed or at least get a lifecycle prefix (and opening_hours removed).