The basis of the validation is the excellent opening-hours-js library, which has very detailed interpretation of opening hours values with lots of error correction (see the evaluation tool). Mainly the report looks for values which either can’t be understood by that, or that can be understood but then ‘look’ different in some potentially meaningful way.
I have tried to balance what is shown so that only things which may be misinterpreted or which may not be understood by other opening hours parsers are shown as errors, but let me know if there’s a pattern of values that don’t need to be changed.
As with all validators, don’t blindly update values, there will be errors in the parsing (please report any that you find). Also, you could take the opportunity to check the website or the actual location for updated hours, especially if it hasn’t been edited in a long time.
Great tool! It really helped reduce the number of mistakes in the Netherlands, Aruba, Curaçao, and Sint Maarten. I wish the Germans good luck with fixing the 20k mistakes
The data updates once a day from planet extracts. At the moment the number of errors stays the same all day, but I should make it update for each person as they fix errors, or if it’s found that the fixes have already been done.
Some time ago I was doing kinda half manually adjustments in dashes, but that required some time of me and some members of the community were always complaining that it’s not OSM fault that OSM data is wrong and parsers can’t deal with our mistakes
I always wanted to improve and extend that, and after seeing your thing with the phone numbers, I thought of doing the same to OH. Gladly you were faster haha!
So, besides my support of it, are you dealing here with these dashes? Other room for improvement I see is at least some sort of fixing stuff like Monday-Friday to Mo-Fr, and even multilingual as Lunes-Viernes to Mo-Fr. I think those are kinda “risk-free” and would greatly improve coverage.
Also, are you planning to do a bot as well to fix those automatically in the future?
you may have collisions between languages where the same word/shortened form means different days of week than the same bunch of letters in a different language
Yeah, hence I was more thinking about extended only (not shortened). I don’t think there should be two pairs of language where “Lunedì” means Monday in Italian but Wednesday in another language.
I’ll have another look at the buttons, I hadn’t checked in all languages
For a bbox, theoretically yes, but it would mean a significant redesign. I have the regions hardcoded (and shared with the phone and names reports), if there are not many issues in each area then it’s a lot of clicking around to get from one region to the other.
Yes, and I even added more to opening-hours.js. If a non-standard dash is used then there should be a suggestion to fix it to a standard hyphen.
There are suggestions for these, but I am not planning a bot edit for any of this. Opening hours are complicated and I haven’t thought of a heuristic that would give a set of opening hours values that are invalid, and could be fixed, and would give enough hits to make it worth implementing.
In most cases suggestions would not be given if there are multiple long forms of a specific shortening, but there have been issues.
Once thing I’ve noticed is that quite a few of the errors in the “Invalid Hours” section are either missing semicolons between different day specs (e.g. “Mo-Fr 08:00-17:00 Sa 09:00-12:00”) or missing colons in the times (e.g. “Mo-Fr 0800-1700”). Might it be possible to suggest automatic fixes for these cases, and put them in the “Fixable Opening Hours” section?
I will look to see if I can add a fix for that. It is technically valid for the opening_hours spec, but I can’t think of a situation where it would be correct to have something like that, without a comma or semicolon.
That’s more of an upstream issue, I will report it there. There’s also the case of using “h” as an hours separator, e.g. “08h00-17h00” which is common in some parts of the world.
You may select your preferred editors using the cog menu in the top right:
As far as I am aware, it is not possible to autoload the fix into iD, so you would have to make the edit yourself manually.
That should only show up for service_times as I found many cases where it was just e.g. 10:00 because it was ‘obvious’ which day of the week the service was on. I see that service_times has been used on some bus stops, which is unusual and probably not the best way to tag whatever is meant.
Well you could check the possible values of the 7 days names in any language (short or long form), Monday - Wikidata for Monday. And if the values to be corrected are unique to a language, or the conversion is the same (*), especially if it belongs the official languages of the state/country, then the correct values can be guessed.
(*) Lu can be the short name in French or Italian, would be translated into Mo anyway.
I would love a sorting for last change. With changes longer than x months or years it might be benificial to leave them and check them more properly. If someone would change an older one, it might suggest someone checked the POI and it might lead someone to believe the whole POI was checked.
Just a thought. I would be more comfortable to simply click if i could sort for last date of change. Oh and also no moving buttons would be quite awesome :D
I tried to login, but there is a TypeError: Failed to fetch problem on my end.
In the Dev Console it says:
Access to fetch at https://www.openstreetmap.org/oauth2/token?grant_type=authorization_code&code=XXX&redirect_uri=https%3A%2F%2Fopening-hours.pages.dev%2Fland.html&client_id=XXX&code_verifier=XXX from origin https://opening-hours.pages.dev has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
AFAIK you have to release the domain on your server settings?
, but when I’ve just tried to fix them, it came back as no changes made as somebody else may have already done so?
