That is already done in the opening hours library using the JavaScript Intl API.
It’s there for the truly invalid, I’ll replace either “Suggested fix” or “Invalid hours” sort with a date sort for the fixable ones.
I haven’t added all countries yet, happy to have more added though. (It’s built on github servers which don’t have space for the whole planet at once, so it’s using country extracts and each one needs some configuring).
Hmm, I guess that couldn’t really mean anything else, I could add a special case for that.
Well there’s my user page or the github repo, but I’ll think about a start page now that I have a few different tools
This is excellent. Any chance you could extend it to also provide an “Edit in iD Editor” button?
The URL format is https://www.openstreetmap.org/edit?node=<id> or https://www.openstreetmap.org/edit?way=<id>. (I see that clicking the icon will already take you to the entity on openstreetmap.org, so it’s already just two clicks.)
That isn’t strictly valid per the opening_hours spec though. Quotes indicates a comment (which should be placed after the times). summer and winter are not valid date ranges since they are too ambiguous. If specific dates can’t be used then some comment or fallback rule should be used here I think
assuming this has been directly copied, the evaluation tool says"
“ <— (Please use notation “”" for ““”. Although using ““” is typographical correct, it is not defined in the opening_hours syntax. Correct typography should be done on application level …)
After changing that the tool is still not satisfied:
“summer”: <— (You have used the optional symbol in the wrong place. Please check the syntax specification to see where it could be used or remove it.)
This is really great, thank you for the time you’ve spent to put it together and share it!
Also, if you were curious to see the edits people make from the tool using the iD link, you could add a hashtag to the URL, e.g. https://www.openstreetmap.org/edit?editor=id&way=822359512#map=19/44.0481767/-77.581523#hashtags=osmphonereport
For those which are not able to fixed (semi-)automatically, i.e. “Invalid Numbers”, would it be possible to also have an option “Comment in Changeset” in addition to existing “Open Note”?
(it is of course somewhat more work to find a changeset which added that broken phone=* tag, but it would be much more useful as I’d be contacting responsible party directly, and they’re most likely to know what is correct value or what they did wrongly; especially if that is relatively recent change)
I can see that would be good, but that means working with history extracts, which are harder to come by, or hitting the API a lot. There’s a link to the changeset of the object’s most recent edit, which I know is not always the changeset responsible for the issue.
But you can use the /history endpoint to get the history, and it’s only when no correction makes sense. You don’t need to use a history extract of the whole database.
As far as I am aware, you can only get the history of one element at a time, so it would mean thousands of requests, which would at least take a lot of time, even if that’s considered acceptable use of the API (and I’m unsure about suitable limits there)
You don’t need more than the history of a single object at a time.
For those which are not able to fixed (semi-)automatically, i.e. “Invalid Numbers”, would it be possible to also have an option “Comment in Changeset” in addition to existing “Open Note”?
Ah ok, I was thinking of working that out at compile time, when all the numbers are processed, but yes it could be done when the button is clicked on the client side.
And another thing that would be very useful in the similar vein:
When using Apply fix to automatically apply suggested formatting fix for opening_hours, would it be possible for OSM Phone Number Validation Reports to not only update opening_hours=* tag, but also add check_date:opening_hours=* tag, set to the last time when the opening_hours was modified (also perusing looking at object history at time of the click).
However, that node was last modified more then decade ago. It is quite likely that the opening hours have changed since then.
If only the opening_hours was changed (and an OSM element timestamp on update was thus set to today), many a data consumer will assume that this opening_hours was recently updated and is thus valid.
Common way to override that assumption[1] is by explicitly setting check_date:opening_hours which explicitly indicates when opening_hours were last verified.
It is especially useful for that particular tag, as opening hours changes often and are decisive factor for choosing where to go[2], and is used by editors and data consumers (e.g. CoMaps, StreetComplete) to give feedback to the user about recentness (and thus, trustworthiness) of the opening_hours.
So, for this particular example, I would suggest when Apply fix is clicked, the webapp would make API call to retrieve history of that node 356919117, find out that while last modification was just 11 years ago, opening_hours=* was last changed 16 years ago at 2010-04-20T08:40:46Z and thus add check_date:opening_hours=2010-04-20 in addition to fixed opening_hours=* tag.
I would find it very useful, as otherwise I’m wary of fixing the opening_hours tag (especially such minor deviations from specs) via that nice Apply fix button, unless the error was introduced relatively recently – as it would otherwise IMHO do more damage then help.
which is just a wild guess, flawed by variety or reasons, e.g. changing unrelated tags, or even mass-aligning without any tag changes etc ↩︎
you don’t want to go to a shop which is closed at the time you arrive there! You might rather go to farther shop, but which is known to be working at that time ↩︎
