opening hours form field

[ansis]

http://wiki.openstreetmap.org/wiki/Key:opening_hours

[tmcw]

Should we have a cutoff for how many instances of a k/v are present before we specialize for it?

[tmcw]

This is basically either 24/7 or a variety of convoluted different types of syntax. Nixing.

[iandees]

After seeing several new users adding their own business to OSM, I think it would be interesting to revisit this at some point by presenting a more complicated form that generated the correct opening_hours=* syntax. JOSM has a plugin that shows a timeline view (similar to GCal's "week" view) that lets you drag to select the times that you want to be open. GMM has a free-form text box for each day of the week.

[iandees]

JOSM shows a dialog to let you edit an existing tag or add a new one:

Then shows the calendar view:

Dragged areas can cross day boundaries:

[iandees]

... here's an example node that someone added for their own car wash and typed in what made sense to them for P2's opening hours field:

http://www.openstreetmap.org/browse/node/2232512015

opening_hours = Mon-Fri 7:30AM- 6:00 PM Sat 9:00 AM- 3:00 PM

[dkniffin]

I came up with a mockup of how this might look in iD:

So the idea is that you'd have a textbox at the top that people can enter whatever syntax they want into, and then the week calendar would update based on that. If the syntax doesn't match the rules of opening_hours, the javascript should autocorrect, and explain what was wrong (ie: if you put "Mon", it'll correct to "Mo", and give a message that says "Use two-letter weekday format".)

The problem with this UI design is it won't handle all features of the syntax. Here's some examples that it wont handle:
Mo-Fr,Sa[1] 08:00-12:00 (Monday until friday and additionally on first saturday in months from 8 to 12.)
Mo-Fr 08:00-12:00, PH off (Monday until friday from 8 to 12, except on public holidays.)
Mo-Fr 08:00-16:00, Sa 10:00-14:00, Sa 14:00-18:00 "if weather permits " (The public pool extends its opening hours on saturdays to 18:00, if the sun shines. (external influence))

Also, whoever develops this out should make sure that the syntax rules follow the ones detailed here: http://www.netzwolf.info/en/cartography/osm/time_domain/ That site is linked from the opening_hours wiki page, and provides a very detailed specification of the syntax. It is also where I pulled all the examples above.

[iandees]

I'm working on a parser that will work with the majority of data according to taginfo here. The goal is to cover most usecases but not destroy existing data. Based on this the form in iD would be a simple table with a 'day' column and 'open'/'close' columns.

[MarkBennett]

Hi all, just curious if opening times will be entered in the local timezone of the feature or in UTC? Depending, the editor may need to take the timezone in to account.

[iandees]

OSM uses local time for the opening_hours tag.

[ypid]

Maybe this library could be used to validate opening_hours and help the user to write a valid one.

[ypid]

To elaborate a little bit more on this. I think the first step would be to make sure that the opening_hours values which make it into the changeset are valid. opening_hours.js is already used by JOSM. Please consider also using it in iD.

[tmcw]

Would love to see a pull request for this feature - it's a bit of an undertaking to build a full-fledged calendar interface as a small feature of a map editor.

[ypid]

I don‘t think that someone who knows the iD code base would need more than 30 minutes to implement this. I would probably need longer …

[brainscript]

Yell.com has got a very good editor for opening hours.

Just use 7 sliders (one for every day) and add the labels for the times. I think the breaks are the more tricky part.

Week-planner looks good too.

[ghost]

Any progress here?
In the mean time maybe a link could be provided to simple instructions (a page like this) for the syntax. Many contributors just fill in something in natural language, which is useless to automated interpreters like OpenLinkMap and OsmAnd.

[bagage]

Also another great alternative not mentioned yet is YoHours.

Maybe iD could give an hint to use one of these solutions when starting writing opening hours manually?
It would not be a hard solution to implement right?

[tmcw]

It would not be a hard solution to implement right?

Please implement it, if you perceive it to be easy.

[bhousel]

Also another great alternative not mentioned yet is YoHours.

Maybe iD could give an hint to use one of these solutions when starting writing opening hours manually?

I just spent about 10 minutes playing around with it and it's unfortunately kind of buggy and hard to use. I do think it's probably a good starting effort though. If it were a bit more polished and could look nice in a lightboxed small dimension iframe, I'd consider it.

It would not be a hard solution to implement right?

I'm vetoing what @tmcw says above, this is too buggy to use currently and I wouldnt merge it. For now spend time improving the tool, but not on integrating it with iD.

[iandees]

Also, supporting all the complex features behind the opening_hours tag language is nice, but the interface on YoHours is way too complex for iD. Limit to full (or half maybe) hours, don't expose the seasonal options, and only allow one tab to start. If someone wants to build more complex OH strings then they could switch to some advanced mode or something.

[bagage]

@tmcw It was more of a question than an assumption, I would certainly not state on unknown technologies; my apologies if it looked like it.
I just wanted to bump the issue since I found YoHours a bit earlier and found it valuable to map a swimming pool with seasonal opening hours which would have take me half an hour to do manually.
I am not YoHours author at all, but considered it as easy enough to use in iD. It seems I was wrong :). At least it may help on what-to-do and what-not-to-do for iD widget.

[tyrasd]

//cc @PanierAvide: would you like to comment on the issues raised by @bhousel above (#974 (comment))?

[PanierAvide]

Of course, so I'm the author of this buggy interface :) For the while it's not meant to be included in something else, but I was thinking of providing a simple HTML page which could be embed in an iframe. What would be the requirements to include this iframe in iD (dimensions, functionalities, show text input or not, how to expose result value...) ?

[PanierAvide]

I made a first attempt of a minimal embeddable version of YoHours. Things can still be smaller, and the seasons dialog content should be optimized. Let me know if it has any interest.

[1ec5]

The problem here is that opening_hours is just a terribly complex grammar and iD needs to support most of it.

Here are the constraints for this feature as I see it:

• The opening_hours syntax is very complex.
• A UI for inputting the value needs to be intuitive without requiring too much form-filling (not too fiddly).
• The input UI also needs to fit within the feature editor, which is constrained horizontally.
• The output UI needs to be understandable at a glance – the mapper needs to be able to scan it quickly and know whether it’s the correct value.

Many calendaring applications have a compact, unfiddly UI for entering new event details: just a freeform textbox that the application parses when you hit OK. The best implementations treat the input as natural language instead of requiring the user to conform the input to a particular format. If this is a suitable input mechanism, then I think a prepopulated text field would also be a suitable output mechanism as well. Imagine seeing Weekdays from 9 AM to 5 PM, correcting it to Monday-Thursday from 9 AM to 5 PM, and having it autocorrect to Mondays through Thursdays from 9 AM to 5 PM with Mo-Fr 09:00-17:00 as the underlying tag value.

#3269 suggested using the open-source hoursparser.js library to implement simple opening-hours input. This library is limited to English and lacks any output formatting functionality.

Another library, rrule, specializes in working with the RRule recurring event rule format found in iCalendar events. This library supports converting both ways between RRule and natural language. This library is nominally internationalized, though it lacks translations and probably needs more work to handle languages that differ grammatically from English: jkbrzt/rrule#13.

I wonder if it would be feasible to convert between the opening_hours syntax and RRule in order to take advantage of the rrule library. Or maybe we could extract the NLP portions of rrule and adapt them to opening_hours.

Edit: This tool (repo) converts from German to opening_hours. It could also be a model for something in iD.

[iandees]

We shouldn't make this too complicated. We should copy the websites/apps that have already figured this out.

For example, Google's looks like this:

This covers the vast majority of simple cases and as mentioned earlier we could skip trying to parse more complicated cases.

[rugk]

Exactly, there are many websites/apps you could take inspiration from: Maps.me, StreetComplete, any calendar app, …

[skquinn]

At the very least, data for opening_hours, service_times, and the like needs to be validated by iD, even if there's no full-blown editor that can handle every edge case of the syntax. I've cleaned up a bunch of them over the past couple of days (including the entire states of Rhode Island, Wyoming, North Dakota, South Dakota, the majority of Kansas, and sizeable chunks of Texas) but without something telling the user "Hey, this syntax is wrong, please fix" they will keep slopping down more rubbish making the tag nearly useless.

[TheAdventurer64]

Any progress?

[quincylvania]

@TheAdventurer64 Any progress would be posted here.

[ghost]

Looks like it's been a few years since YOHours was mentioned in the thread, are the usability concerns still present? If the situation has improved, even something like the attached mockup (except adjusted for iD's style, I just faked it quickly in dev tools) would be an improvement / useful stopgap -- it seems many users don't concern themselves with the raw tags section, only the widgets area.

[rmikke]

Someone has alredy coded part of JOSM-like opening hours box:
https://github.com/Deuxis/timesetter

[tordans]

Someone has already coded part of JOSM-like opening hours box…

There is also a working version in MapComplete.

• Example: https://pietervdvn.github.io/mc/develop/cyclofix.html?z=17&lat=52.4752&lon=13.4441&language=en#node/1954982655
• Docs for how to add it to a theme https://github.com/pietervdvn/MapComplete/blob/8ea6f494bf26953945b38fddf2fc60f7d98aaa2a/Docs/SpecialRenderings.md#opening_hours_table
• Code https://github.com/pietervdvn/MapComplete/blob/master/UI/OpeningHours/OpeningHoursVisualization.ts#L15

This might be an interface component, that multiple JS based OSM editors can use; so building this as a separate component sounds like an interesting idea.

[Mashin6]

It would be really helpful if there was some movement on this issue. There are lot of people adding opening hours to restaurants around them and it takes time to fix it after them.

What about adding support for very simple cases. Like for example the time picker would show only if the opening_hours field is empty or parsable without error (to avoid problems with sunset-sunrise etc.) and it would be only for one time slot per day. No months, no holidays.

It could be as simple as 7 sliders that could be rolled out as a drop down menu.

[iandees]

There's been a lot of really great screenshots of others doing this. Someone just has to spend the time to make the change to iD 😄

[lefuturiste]

Hello, just saying that I'm currently working on a PR to improve iD support of opening hours.
I think that the first step would be to validate the opening_hours, collection_times and service_times fields using opening_hours.js. The next step is to have a basic editor that cover basic needs.

[1ec5]

Looks like it's been a few years since YOHours was mentioned in the thread, are the usability concerns still present? If the situation has improved, even something like the attached mockup (except adjusted for iD's style, I just faked it quickly in dev tools) would be an improvement / useful stopgap -- it seems many users don't concern themselves with the raw tags section, only the widgets area.

The earlier concerns about YoHours didn’t come with specific details or acceptance criteria, so I’m also willing to assume that improved access to the tool would be a net positive for most users. #9678 implements something similar to the mockup in #974 (comment) as a stopgap.

I think that the first step would be to validate the opening_hours, collection_times and service_times fields using opening_hours.js. The next step is to have a basic editor that cover basic needs.

Once we have at least a minimal UI like the one in #9678, validation would be a sensible next step, but not before then. It wouldn’t be fair to warn users about broken syntax without offering a solution. opening_hours.js does have validation functionality we could use, though it might be overkill compared to generating a tokenizer just for the purpose of validation. For example, I whipped up a formal definition of the opening_hours syntax for Peggy; though it definitely has some kinks to work out, it would get the job done without needing to analyze the value for actual date ranges.

Beyond that, I would reiterate the point in #974 (comment) that all the calendar mockups so far probably fall short of what iD’s inspector needs. A calendar interface is undoubtedly useful for editing, but it takes up far too much space to appear by default in every preset, including when the user merely hovers over a feature to preview its tags. We wouldn’t be able to hide the raw syntax, which is kind of how this all started. There needs to be a more compact representation, similar to the one opening_hours.js’s prettifyValue() function returns, but localized. Map applications typically display a similar value as a subtitle in a POI detail view.

[wcedmisten]

Hello! There's been a lot of discussion on this over the last 10 years. My thoughts are that @Mashin6's suggestions of using sliders may one of the easier approaches for a MVP supporting the simplest/most common subset of opening_hours syntax.

I took a first stab at implementing this, although it's very far from being usable and the CSS is still quite ugly, I'd like to get feedback on it before going further in this direction.

This comment makes me think the maintainers would prefer a more comprehensive solution, rather than merge in something that only supports of a subset of opening_hours.

My personal opinion is that we should provide a good UI for the simpler syntax and just suggest manual editing of tags for the complex syntax. Linking to another tool like #9678 to support the complex syntax also seems like a viable workaround.

Would any of the maintainers care to weigh in with their present opinions on this to inform my future work? Thanks in advance!

[1ec5]

Thanks for taking the time to make this mockup. I’m not the official maintainer, but perhaps I could elaborate on my contrarian comments so far.

Many of the mockups so far are optimized for the simple kind of opening hours that has a single timespan each day of the week, consistent across all weeks of all years. I agree that this is one of the most important cases to address (with varying levels of importance depending on the POI type and region). It’s fair to start with the most important cases and figure out how to shoehorn edge cases into the UI later. Your proposal would actually make #9678 completely unnecessary, because it covers the same exact cases.

However, I think most users who need to use this field are copying opening hours from a sign or website or maybe from memory. These opening hours are always expressed as literal times, so that’s what the user would be able to enter most readily. Any UI that requires dragging, whether on a calendar or a slider, introduces a degree of imprecision. Now you have to watch the time indicator while you drag the slider around. If the shop opens at a quarter past the hour, you’ll need good hand-eye coordination. Where I come from, many schools open or close at five or eight minutes past the hour for some reason.

Pairing each double-knobbed slider with two editable text fields would allow the user to adjust the value to match the sign. But at that point, I wonder if the slider is providing any value compared to just the two text fields (perhaps with dropdown menus or increment/decrement buttons). #974 (comment) has an example of what a text field–based design could look like.

There’s still the issue of minimizing the field’s vertical space. Maybe the field could start out in its current form, as a single unstructured text field, but when you focus the field, a more structured form could slide out below. This wouldn’t quite prevent the user from ever seeing the raw opening hours syntax, but at least it would get the main editing case out of the way so we can focus on a more comprehensive solution.

[wcedmisten]

Yeah that makes sense, now that I think about it, the sliders seem a bit fiddly for entering hours, even if limited to 1-hour intervals.

With #974 (comment), does "add hours" open a separate block to enter other days? Otherwise, how would the user enter e.g. separate weekend hours with that interface?

Or is that not supported in that UI?

[1ec5]

I assume that screenshot was from the Google Maps UI for suggesting changes. These days, the UI takes up a lot more space; it’s more like a wizard than an inspector now. Clicking “Add hours” lets you add another time span for the selected day or days.