Id: 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 (https://github.com/openstreetmap/iD/issues/974#issuecomment-133526716)?

[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.

[d1g]

@PanierAvide I will be happy to see yohours in iD.

Normally we want time table and columns with 24/7 and ("Monday"...) headers, Other settings are less popular and should be displayed as small tabs.

We may want to add more _hover_ explanations to table in user language about how advanced features of opening_hours work. yohours contain no context-sensitive help or hover captions.

[PanierAvide]

Is there any hover caption system specific to iD, or something as simple as <a title="..."> can be used ?

[d1g]

@PanierAvide I think it is ID-specific, You can test it with way tagged as highway=track. CSS class is "form-field-tracktype". Unlike html select it will:

1. display shorter/trimmed title
2. provide user with translated string when select box is opened

We will need hovers like this, but for calendar controls (sliders) or text fields (hover on opening_hours=24/7 will show "Open 24/7" in user language)

PS. We can annotate most OH strings in natural language, but it will be more demanding task.

[rugk]

Any progress here? I think opening_hours is one of the most difficult days a Newbie encounter.

So iD should:

1. Maybe at least validate the entered value, to prevent bad values
2. (Later) offer a nice UI for editing it

Note that also Maps.me has a simple opening_hours editor, which works great for most cases.

[boothym]

Any progress here? I think opening_hours is one of the most difficult days a Newbie encounter.

Indeed and as a newbie you probably aren't going to look into the wiki and see exactly how it's done. One I saw today from a new user was "Mon-Fri 0800 - 18.30, Sat 0800-1700, Sun 0800-1400" - a shame it was so close but not correct. I wonder if iD could do some basic validation, like checking for two letter days and time separator?

@bhousel here's a couple of examples:

google mapmaker desktop

Clicking on Mon-Sat gives you a dropdown which can be ticked, the hours also give a dropdown with half hourly times.

maps.me android

The advanced mode gives the normal alphanumeric field and some examples of the opening_hours format.

[bhousel]

To everyone commenting on this ticket. I don't need inspiration on how to design a date picker. The reason this field has not been built yet is not because I don't know what a date picker is, or know where to find one.

The problem here is that opening_hours is just a terribly complex grammar and iD needs to support most of it. For example, sunrise-sunset is currently the 8th most common value for opening_hours. If somebody edits a business already tagged with opening_hours=sunrise-sunset, what should this field show? We try very hard not to break existing data.

I do want to support this, but it's not as simple as dropping in a date picker.

[iandees]

What if a day/time picker is only shown when the value of an existing object's opening_hours tag matched a regex that covers the "simple case"? e.g. Mo-Fr 09:00-17:00; Sa-Su 10:00-13:00. If it doesn't match such a regex, it shows the standard text box?

[boothym]

Sorry, didn't realise where you were at with this issue :P

In addition to finding the simple case, you could also find the "complex" cases and only show the text box. For example, if it contains dawn | sunrise | sunset | dusk | unknown | open | closed | off, anything with "", etc.

[rugk]

I agree to @iandees: Just try to parse the existing field, if it fails fall back to the regular input box (and probably offer a button: "switch to easy input mode")

This would be very similar as in Maps.me, which also has a really basic input date/time picker: At the bottom of the screen you can see "advanced mode", which offers the traditional input box. However the time can be overwritten by the visual time picker.

[boothym]

@bhousel any progress with this issue? Reason I ask is I've seen a number of new users add things like "11am to Midnight", "10:30am - 9:30pm" or spelling out the days of the week.

Even if it's not a day/time picker at the moment, there should be something to help new mappers add opening hours in the correct format, especially in a blank text box. How about a placeholder with "Mo-Fr 09:00-17:00; Sa 10:00-14:00" or similar?

[bhousel]

For now, I could make the field a dropdown, then users would at least get some valid things suggested to them.

[rugk]

Yeah, offering the "most common" values or so could be a good start.

[bhousel]

For now, I could make the field a dropdown, then users would at least get some valid things suggested to them.

Ok this was done. CCing @joto because opening_hours is one of those fields with a lot of values (see #3955), but not as bad as name or ref. So we should watch that it doesn't affect taginfo performance too negatively.

[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 internationalized, though it lacks translations and probably needs more work to handle languages that differ grammatically from English.

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 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.