Option to mark shops as "temporarily closed" or being on vacation until ...

[ewerybody]

Use case

As a SC user I love checking and adding opening hours. But now during summertime I often see signs saying sth like "we're on vacation, back in 2 weeks". This is valuable data! I'd love to be able to add this!!

Currently this situation makes me adding notes to these shops. Now several folks responded, telling me that this "does not need to be added". I'm baffled! I used to be frustrated with this contributing to Google Maps in the past and they finally have this!! It's utterly useful!! Now I don't care about google maps any more and I'm happy we have open mapping data.

And finally as an OSM user I don't want to look up a shop, go there during opening hours, finding it closed nonetheless.

Proposed Solution

• Under the Äh/Uh ... and ⁝ lets have an option to set something temporarily closed
• Pick a calendar date
• OK, Voilà

ehm.. Under the hood I see there is a 9y old proposal for a Temporary feature.

And here is a point in the Good practice wiki: Don't map temporary events and temporary features On the other hand there is the Keep the history point adding strongly to the notion of impermanence.

Ooof. Now I'm sorry making you read this but I'd be more sorry to throw it away now and interested if there is more discussion about this!? I'm rather new to the osm scene 🙈 <3

[matkoniecz]

currently there is no good way to mark it in OSM

https://wiki.openstreetmap.org/wiki/Proposal:Temporary_(conditional) never went beyond an idea

https://wiki.openstreetmap.org/wiki/Conditional_restrictions could be in general used for opening_hours:conditional but it is also unusual at best

for now I would advise to mark regular opening hours - even those are mostly missing

[westnordost]

Yeah, well, see @matkoniecz

I usually leave shops that are temporarily closed due to renovation or vacation alone, there are enough other things that should be corrected. But really, I only do this because there is currently no way to tag this.

So, maybe worth a wiki proposal or a discussion in the openstreetmap forum. If there is consensus on any one tag, it could be implemented in StreetComplete.

[Cj-Malone]

opening_hours=closed is somewhat used for temporally closed, but there isn't really a place to store the usual opening hours while they are temporally closed.

[ewerybody]

@Cj-Malone Hmm yeah that's pretty much what it says black on white there :D

But yeah like @westnordost wrote: If there is no consensus on osm side how to do this, there is no point here. I just don't know where to start! There are a lot of talks when searching for temporary. Is this the right place to search???

Here is an interesting talk about this museum which is quite surely not tagged properly.

After looking into the conditional and opening_hours syntax I can imagine that we might use conditional to do this?? Like:

opening_hours=Mo-Fr 18:00-01:00, Sa 17:00-01:00, Su 17:00-24:00
opening_hours=conditional=closed @ (2018 May 22-2018 Oct 07)

[Cj-Malone]

We'll never know start or end dates so I don't think we can do conditionals.

[matkoniecz]

start may be set as today/yesterday and return dates are commonly specified (so clients know when shop reopens)

[westnordost]

Hm, we could use opening_hours=closed, but StreetComplete will only ask users again about the opening hours of a place after 1 year, so if something is only very temporarily closed (vacation, a few months renovation), then I think it would be counter-productive.

On the other hand, StreetComplete could ask again for opening_hours=closed more often than after 1 year, e.g. every... few months??

[matkoniecz]

well, for short term closures like holidays data will be outdated before typical data consumers even update map data

and what worse, mapper may be visiting on holidays and then leaving, with no resurvey done for quite long time - I bet that it would make regular mappers unhappy! This problem is worsened by StreetComplete mapper on holidays (like me) being more likely to go on holidays in a holiday season

maybe put it opening_hours:conditional? And get closure date by asking mapper?

[matkoniecz]

(personally, I think that on shops opening_hours=closed is nearly always/always a bad idea, if it is long term closed then set it to disused:)

[HolgerJeromin]

This is valuable data! I'd love to be able to add this!! I used to be frustrated with this contributing to Google Maps in the past and they finally have this!!

Note that google maps is used mostly online while there are many osm applications where the data is updated every few month (osmand for example) or years (garmin devices).

[westnordost]

Hm, well, then I'll close this again...

[matkoniecz]

opening_hours:conditional allows to tag it (and in theory make it available) without breaking such data consumers

[mnalis]

TL;DR: Well, I think it makes sense to allow users to specify that. And it is not hard (see suggestion below). And popular data consumers like OsmAnd can update their offline databases on daily (or even hourly basis), so it is quite useful for them. Of course some data consumers are worse, but hey, let it be an incentive for them to become better.

---

opening_hours=Mo-Fr 18:00-01:00, Sa 17:00-01:00, Su 17:00-24:00 opening_hours:conditional=closed @ (2018 May 22-2018 Oct 07)

Note that you don't even need opening_hours:conditional for that; opening_hours itself has support for that.

e.g. opening_hours=Mo-Fr 18:00-01:00, Sa 17:00-01:00, Su 17:00-24:00; 2018 May 22-2018 Oct 07 off (that ; instead of , is important; as it means "override" instead of "add to")

it even supports adding comments, e.g. opening_hours=Mo-Fr 18:00-01:00, Sa 17:00-01:00, Su 17:00-24:00; 2018 May 22-2018 Oct 10 off "due to renovation" and apps like OsmAnd know how to display that comment.

Note that google maps is used mostly online while there are many osm applications where the data is updated every few month (osmand for example)

Well, OsmAnd updates for me (and every other mapper[^1] who enables the Live updates feature) automatically every hour (and with manual clicking you can get it down to about every 15 minutes if you're in a crunch. Or increase it to once daily, or once weekly). I'd highly suggest enabling that 😸

or years (garmin devices).

Well, if your devices updates only on "every few years" basis, any opening_hours data you have is more likely invalid then correct in my experience (in fact, worrying number of POIs themselves are likely to be something else by then, especially in today's economy). You better not rely on such map for much more than just roads, (most) fuel stations and city names themselves...

On the other hand, StreetComplete could ask again for opening_hours=closed more often than after 1 year, e.g. every... few months??

That would be useful for those ~8k opening_hours=closed and opening_hours=off to recover them more quickly, yes... But is somewhat orthogonal to this problem (how StreetComplete should mark temporary hours).

---

My suggestion what SC could offer, is to have Uh... / It's closed until... and ask for date until when is it closed, and then:

• remove any absolute time period that is expired (e.g. if it has ; 2018 May 22-2018 Oct 07 off remove that)
• add a new absolute time period from today[^2] to given date (e.g. ; 2025 Aug 20 - 2025 Sep 30 off)

Advantage is that it will correctly mark it as closed for known time periods, and there is no damage if nobody updates the opening_hours later[^3]. Data consumers which update often will benefit, and those which update very rarely will be no worse.

Of course, it if is closed for unknown reasons for unknown periods, it is probably best to leave a note (or mark as disused:shop if it looks very unlikely that it will open again; e.g. one can see everything removed/boxed through the window etc.)

[^1]: if you map at least few edits a month or something you get a feature for free... And AFAIK even non-mappers can enable that, but need to get a paid OsmAnd version instead of gratis one. [^2]: because, it is simpler to just use today's date and we don't care if it was closed in the past too - nobody will travel back in time [^3]: as non-matching time ranges don't matter

[Helium314]

Is opening_hours:conditional supported by any consumer? It's very rare to be used for something else than closed in winter or if bad weather. The one place I found with different opening hours in summer (with exact dates) didn't show the conditional hours in organic maps. (asking because conditional opening hours could be something for SCEE)

[matkoniecz]

With 35 uses worldwide, I would expect that for now it is not having significant (or any) support - but it may change if it would be used more

https://taginfo.openstreetmap.org/keys/opening_hours%3Aconditional

[ewerybody]

Thanks @mnalis for the detailed input!

After all it's about the data and about THE open, public repository for these things. If we want this data to be a real alternative to the corpo stuff thinking about some consumer that might just update every leap year is holding back progress. The trend is definitely towards more frequent updates. If we can make this work without breaking oldschool consumers like proposed: even better!

but I guess we need to talk to the big apps about this anyway :) cheers

[mnalis]

The trend is definitely towards more frequent updates

Yes, I agree. As I noted, one can use OsmAnd with hourly updates, or even https://osm.org/ webpage on the phone with freshness better then a minute.

As a SC user I love checking and adding opening hours. But now during summertime I often see signs saying sth like "we're on vacation, back in 2 weeks". This is valuable data! I'd love to be able to add this!!

StreetComplete (for all its greatness) is currently not a good choice for on-demand editing of existing features: it's Quest model is build on different principles. I.e. for existing features (like e.g. shops), it only asks about missing attributes (like opening hours) or about ones which likely might be stale (e.g. if several years have passed since they were last updated).

But for example if shop was added to the OSM map just a month ago, and today you see they just announced new opening hours (e.g. they're going on vacation and will be closed for a month), StreetComplete can't help you. So, for the time being, I'd suggest non-experts to use Every Door app for such on-demand POI editing, like e.g. indicating that some store is "closed from 15. Aug 2025 to 9. Sep 2025".

But I do feel that StreetComplete (or at least SCEE - StreetComplete "Expert edition" fork) should add code for that as I've mentioned above, i.e.:

My suggestion what SC could offer, is to have Uh... / It's closed until... and ask for date until when is it closed, [...]

preferably both in Quest Uh... menu as well as in Places Overlay ⋮ (so changing of opening_hours can be triggered on demand, either it specifically, or even more useful, for all the quests for that element - e.g. https://github.com/streetcomplete/StreetComplete/issues/6459)

[westnordost]

@mnalis suggestion makes sense and is doable. Although, somewhat increases the complexity of parsing opening hours.

However, what should we do if appending such "closed until ..." string will make the opening_hours string exceed the maximum number of characters (255)?

Also, this only solves one use case - the use case that the (exact) new opening date is known. The more common case that it is temporarily closed "due to renovation", "due to water main break", "due to shortage of staff" or no reason given at all is not covered by this solution

[mnalis]

However, what should we do if appending such "closed until ..." string will make the opening_hours string exceed the maximum number of characters (255)?

Well, what do we do currently if editing (or adding) opening hours exceeds the limit (e.g. if one attempts to add too many months/days/hours then fits in 255 chars, or user types very long explanation for "Uh..." / "No regular opening hours")?

Ideally, we would not allow user to accept the changed value if it becomes too long (displaying a toast about technical limit when try to submit?), but failing with error if it becomes too long is another possibility. (Silently dropping the change at upload time is also an option, but is not nice, and it might confuse the users more then the error while updating the object).

Update: Quick scan of the code seems to indicate we create a Note indicating a problem? That seems fine too, someone else can pick it up and fix such (hopefully quite rare) cases in a most appropriate way.

Also, this only solves one use case - the use case that the (exact) new opening date is known. The more common case that it is temporarily closed "due to renovation", "due to water main break", "due to shortage of staff" or no reason given at all is not covered by this solution

If Uh... / It's closed until... is implemented, I see several ways it might be handled:

• the user can of course still leave a Note stating the reason why is it closed until further notice (but, as you note, that is suboptimal if those cases are generally commons, as they likely are)
• the user may decide to estimate and just wing it with new "It's closed until..." option (e.g. "it's closed due to renovation, estimated until December 2025")
• we could also add yet another option "It's closed for unspecified amount of time" which would just replace[^1] tag with user message; e.g. opening_hours = closed "due to shortage of stuff" (and we can re-survey such opening_hours starting with text closed significantly more often). This option is probably ideal for user being able to update to the OSM directly in clearest fashion, but is also most work... 🤷‍♂️

[^1]: we could also append to current value, e.g. "opening_hours = Mo-Fr 08:00-19:00; closed "currently closed due to shortage of stuff since 18 Sep 2025" means it is closed all the time for the specified reason even if it preserves original opening hours; but advantages of doing that for unbounded temporary closures are rare and need even more work to actually take advantage of them.