Access restrictions based on religious dates?

General talk
1

Hi. Some conditional restrictions are based on religious dates such as Holy Week or Easter Sunday, which occur on different dates each year.

I couldn’t find a way to write that in opening hours specification. Can these religious dates be written in that specification?

If not, it would be ok in OSM to tag that restrictions calculating the exact dates for a few years, e.g. from 2026 to 2030, generating a long string for the conditional restriction?

2

Yes! As an example, this train station opens for passengers only on the third Sunday of Lent (so 28 days before Easter)

¡Sí! Por ejemplo, esta estación abre para pasajeros únicamente en el tercer domingo de Cuaresma (esto es 28 días antes del domingo de Pascua)

1 Like
3

I can talk about “Easter” only. If you find a way to specify this in “opening_hours”, you can calculate all other variable Christian holydays from that: Easter-2, Easter+1, …, Easter+40, …

2 Likes
4

There is also this handy opening_hours editor, which understands the Easter dates (and even has a couple of examples about it)

2 Likes
5

Gracias. No habia encontrado esa capacidad en la documentación!

Lo etiqueté en un par de vias, veremos que pasa llegada esa semana y que ruteadores son capaces de usar este detalle. Al parecer solo GraphHopper podría usarla hoy por hoy, pero no esta mal etiquetarlo, asi cortamos el problema del huevo y la gallina.

1 Like
6

Well, now I’m curious. At Key:opening_hours - OpenStreetMap Wiki page I see a reference to “easter” as follows:

yearly_fest: easter

For now, the only variable yearly fest day specified is Easter (assuming the Christian Gregorian calendar).

Have any OSM communities ever required/used a different religious date, even a different Easter? Eg: Eastern Christian Easter is typically (not always) on a different date from the Western one.

Bueno, ahora me pica la curiosidad. En ES:Key:opening_hours - OpenStreetMap Wiki veo lo siguiente:

fiesta_anual: easter (Pascua)

Por el momento, la única fiesta variable anualmente específica es Easter (asumiendo el calendario Gregoriano cristiano).

¿Ha habido alguna vez alguna comunidad OSM que haya necesitado/usado una fecha religiosa diferente, incluso una Pascua diferente? Por ejemplo: en la tradición cristiana oriental, la Pascua cae normalmente (no siempre) en una fecha distinta a la occidental.

2 Likes
7

Currently easter is the only “pre-defined” religious date in the OH specification, however this is one (if not the only one) area for which I believe there could be support for extending the spec, as these are unlikely to conflict with anything else. This has been proposed in the past, iirc for Ramadan, but nothing ever came of it.

2 Likes
8

Isn’t Easter eaqually defined as the first Sunday after the first full-moon after start of spring (March 21), equal for all Christians?

9

I believe the difference is the definition of “March 21”, with Eastern churches going by the Julian calendar on liturgical matters.

3 Likes
10

It’s a difference of the calendar used, see List of dates for Easter - Wikipedia for the dates of the current period.

2 Likes
11

Probably, this thread can be a starting point for the opening_hours syntax to be inclusive of different calendars and festivities. I would definitely support that!

4 Likes
12

I was referring to the sun eclipse equinox, start of astronomical spring in the northern hemisphere. This is on March 21 in my hemisphere, might fall on different dates in other types of calendars.

1 Like
13

Not realistic, the specification is already far too complicated (see previous discussions).

As said above this is easy.

14

Not realistic, the specification is already far too complicated (see previous discussions).

Could you point to any of those discussions? I cannot find them.

I can imagine two ways it could be done:

  • Integrating the opening_hours syntax by using prefixes (would allow mixing of different calendars)
    • opening_hours=isl:Ram 3 - isl:Shw 2 (open from the 3rd of Ramadan to the 2nd of Shawwal, months in the Islamic calendar)
    • opening_hours=heb:Ris - heb:She (open from Yom Rishon to Yom Sheni, days of the week in the Hebrew calendar)
  • Creating opening_hours:<subkey> for any given calendar (there is a question of what would happen if multiple ones are defined on the same OSM element)
    • opening_hours:isl=Ram 3 - Shw 2 (open from the 3rd of Ramadan to the 2nd of Shawwal, months in the Islamic calendar)
    • opening_hours:heb=Ris - She (open from Yom Rishon to Yom Sheni, days of the week in the Hebrew calendar)

As said above this is easy.

I see easter is the only <variable_date> in the specification so far.

There is a list of movable dates in Wikipedia that we can start off from: List of multinational festivals and holidays - Wikipedia

15

For example [Tagging] Expand the key:opening_hours

16

“:” Is already in use in the OH grammar (a lot, including for comments).

17

Easter is in there because the computus is such a famously difficult problem in Western calendaring, despite the otherwise solar Gregorian or Julian calendar. To fully accommodate observances from some other cultures, we’d probably need to more generally consider lunar/lunisolar calendars, as you’ve discovered in your examples.

I’d seek out prior art before devising another ad hoc syntax that we gradually discover to be underspecified. RFC 7529 and Wikipedia’s calendar date template system could be useful for understanding the scope of such a project. There’s probably some precedent in the library science community for representing non-Gregorian calendar dates in a compact syntax, as there is for uncertain dates with the EDTF standard (compare to OSM).

All of this of course recognizing that any non-Gregorian dates would be wholly incompatible with the existing ecosystem of opening_date=* parsers. But as long as any changes are additive and clearly identifiable, at least that would be no worse than the current situation for any opening dates that really do depend on these calendars.

4 Likes