Expand the key:opening_hours

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Expand the key:opening_hours

Phake Nick
I found that the current way of mapping opening time of features in
OSM map are too limiting, and the opening time of some features cannot
be properly represented with only the current syntax, therefore I have
written a brief idea about how the syntax in key opening_hours could
have been expanded to match more different needs at the article's talk
page. See https://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#Proposed_extension_to_supported_syntax_in_the_page.
. It would be nice if these features can be added into the scheme so
that relevant featurs opening days and time can be represented by the
scheme directly instead of via text description and external link.

The most significant part of what I would like to see are support for
solar term(節氣/节气/節気/절기/Tiết khí) and (East Asia) lunar (lunisolar)
calendar(舊曆/旧历/旧暦/음력/Nông lịch). And because the calculation of both
are dependent on timezone and then when some countries celebrate these
festivals they use the calendar that is not based on their own
country's time but use the Chinese time (or time of other countries
for overseas diaspora of them) so I have also added a proposal to
support timezone specification in the scheme which is also desired by
some other users on the talk page. Note that the scheme I proposed to
express solar term and lunar month representation wasn't actually that
much intuitive but I believe it have an advantage that it's more
internationalized and thus providing a common way of tagging features
across different regions that use the calendar.

Additionally, I have also written in the proposal that I would like to
see additional supported values for bank holidays, offset in term of
number of weeks, and also support for timestamp beyond 24 hours in the
scheme. Expressing time beyond 24 hours can be especially meaningful
when the operator of those features decided to release their time this
way and it can reduce error when inputing or transporting data into
OSM as it is not uncommon for people to forget properly converting
dates when they are asked to change the time format back to 00-23h
format.

And while it seems like the de facto standard, I would also like to
see the formalization of the handling of time range representation
like Su 23:00-07:00 that in such syntax the 07:00 is referring to
07:00 on the next day.

Any thought on the proposal?

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Expand the key:opening_hours

SimonPoole
The basic problem with proposing an extension to the current OH grammar
is that it is already far too complicated and full of ambiguities, there
are afaik currently only two parsers that handle > 90% of the grammar
and most of the other ones are rather broken, adding more stuff is
definitely not going to improve things.

That said, there are one or two places where extensions would be low
impact (extra holiday and variable_date  values for example). However in
any case I would suggest you familiarize yourself with the actual
grammar
https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification
first , in particular your proposal begins with a couple of non-starters
that conflict directly with the existing specification.

Simon

Am 13.03.2019 um 19:52 schrieb Phake Nick:

> I found that the current way of mapping opening time of features in
> OSM map are too limiting, and the opening time of some features cannot
> be properly represented with only the current syntax, therefore I have
> written a brief idea about how the syntax in key opening_hours could
> have been expanded to match more different needs at the article's talk
> page. See https://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#Proposed_extension_to_supported_syntax_in_the_page.
> . It would be nice if these features can be added into the scheme so
> that relevant featurs opening days and time can be represented by the
> scheme directly instead of via text description and external link.
>
> The most significant part of what I would like to see are support for
> solar term(節氣/节气/節気/절기/Tiết khí) and (East Asia) lunar (lunisolar)
> calendar(舊曆/旧历/旧暦/음력/Nông lịch). And because the calculation of both
> are dependent on timezone and then when some countries celebrate these
> festivals they use the calendar that is not based on their own
> country's time but use the Chinese time (or time of other countries
> for overseas diaspora of them) so I have also added a proposal to
> support timezone specification in the scheme which is also desired by
> some other users on the talk page. Note that the scheme I proposed to
> express solar term and lunar month representation wasn't actually that
> much intuitive but I believe it have an advantage that it's more
> internationalized and thus providing a common way of tagging features
> across different regions that use the calendar.
>
> Additionally, I have also written in the proposal that I would like to
> see additional supported values for bank holidays, offset in term of
> number of weeks, and also support for timestamp beyond 24 hours in the
> scheme. Expressing time beyond 24 hours can be especially meaningful
> when the operator of those features decided to release their time this
> way and it can reduce error when inputing or transporting data into
> OSM as it is not uncommon for people to forget properly converting
> dates when they are asked to change the time format back to 00-23h
> format.
>
> And while it seems like the de facto standard, I would also like to
> see the formalization of the handling of time range representation
> like Su 23:00-07:00 that in such syntax the 07:00 is referring to
> 07:00 on the next day.
>
> Any thought on the proposal?
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Expand the key:opening_hours

SimonPoole

Just a PS: any grammar extension need to be compatible with the use of OH strings in conditional restrictions too, see https://wiki.openstreetmap.org/wiki/Conditional_restrictions . While I haven't looked at in detail your proposal for a timezone extension might have difficulties with that.

Am 14.03.2019 um 00:38 schrieb Simon Poole:
The basic problem with proposing an extension to the current OH grammar
is that it is already far too complicated and full of ambiguities, there
are afaik currently only two parsers that handle > 90% of the grammar
and most of the other ones are rather broken, adding more stuff is
definitely not going to improve things.

That said, there are one or two places where extensions would be low
impact (extra holiday and variable_date  values for example). However in
any case I would suggest you familiarize yourself with the actual
grammar
https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification
first , in particular your proposal begins with a couple of non-starters
that conflict directly with the existing specification.

Simon

Am 13.03.2019 um 19:52 schrieb Phake Nick:
I found that the current way of mapping opening time of features in
OSM map are too limiting, and the opening time of some features cannot
be properly represented with only the current syntax, therefore I have
written a brief idea about how the syntax in key opening_hours could
have been expanded to match more different needs at the article's talk
page. See https://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#Proposed_extension_to_supported_syntax_in_the_page.
. It would be nice if these features can be added into the scheme so
that relevant featurs opening days and time can be represented by the
scheme directly instead of via text description and external link.

The most significant part of what I would like to see are support for
solar term(節氣/节气/節気/절기/Tiết khí) and (East Asia) lunar (lunisolar)
calendar(舊曆/旧历/旧暦/음력/Nông lịch). And because the calculation of both
are dependent on timezone and then when some countries celebrate these
festivals they use the calendar that is not based on their own
country's time but use the Chinese time (or time of other countries
for overseas diaspora of them) so I have also added a proposal to
support timezone specification in the scheme which is also desired by
some other users on the talk page. Note that the scheme I proposed to
express solar term and lunar month representation wasn't actually that
much intuitive but I believe it have an advantage that it's more
internationalized and thus providing a common way of tagging features
across different regions that use the calendar.

Additionally, I have also written in the proposal that I would like to
see additional supported values for bank holidays, offset in term of
number of weeks, and also support for timestamp beyond 24 hours in the
scheme. Expressing time beyond 24 hours can be especially meaningful
when the operator of those features decided to release their time this
way and it can reduce error when inputing or transporting data into
OSM as it is not uncommon for people to forget properly converting
dates when they are asked to change the time format back to 00-23h
format.

And while it seems like the de facto standard, I would also like to
see the formalization of the handling of time range representation
like Su 23:00-07:00 that in such syntax the 07:00 is referring to
07:00 on the next day.

Any thought on the proposal?

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

      
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (495 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Expand the key:opening_hours

Warin
On 14/03/19 10:52, Simon Poole wrote:

>
> Just a PS: any grammar extension need to be compatible with the use of
> OH strings in conditional restrictions too, see
> https://wiki.openstreetmap.org/wiki/Conditional_restrictions . While I
> haven't looked at in detail your proposal for a timezone extension
> might have difficulties with that.
>
> Am 14.03.2019 um 00:38 schrieb Simon Poole:
>> The basic problem with proposing an extension to the current OH grammar
>> is that it is already far too complicated and full of ambiguities, there
>> are afaik currently only two parsers that handle > 90% of the grammar
>> and most of the other ones are rather broken, adding more stuff is
>> definitely not going to improve things.
>>
>> That said, there are one or two places where extensions would be low
>> impact (extra holiday and variable_date  values for example). However in
>> any case I would suggest you familiarize yourself with the actual
>> grammar
>> https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification
>> first , in particular your proposal begins with a couple of non-starters
>> that conflict directly with the existing specification.
>>
>> Simon
>>
>> Am 13.03.2019 um 19:52 schrieb Phake Nick:
>>> I found that the current way of mapping opening time of features in
>>> OSM map are too limiting, and the opening time of some features cannot
>>> be properly represented with only the current syntax, therefore I have
>>> written a brief idea about how the syntax in key opening_hours could
>>> have been expanded to match more different needs at the article's talk
>>> page. Seehttps://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#Proposed_extension_to_supported_syntax_in_the_page.
>>> . It would be nice if these features can be added into the scheme so
>>> that relevant featurs opening days and time can be represented by the
>>> scheme directly instead of via text description and external link.
>>>
>>> The most significant part of what I would like to see are support for
>>> solar term(節氣/节气/節気/절기/Tiết khí) and (East Asia) lunar (lunisolar)
>>> calendar(舊曆/旧历/旧暦/음력/Nông lịch). And because the calculation of both
>>> are dependent on timezone and then when some countries celebrate these
>>> festivals they use the calendar that is not based on their own
>>> country's time but use the Chinese time (or time of other countries
>>> for overseas diaspora of them) so I have also added a proposal to
>>> support timezone specification in the scheme which is also desired by
>>> some other users on the talk page. Note that the scheme I proposed to
>>> express solar term and lunar month representation wasn't actually that
>>> much intuitive but I believe it have an advantage that it's more
>>> internationalized and thus providing a common way of tagging features
>>> across different regions that use the calendar.
>>>
>>> Additionally, I have also written in the proposal that I would like to
>>> see additional supported values for bank holidays, offset in term of
>>> number of weeks, and also support for timestamp beyond 24 hours in the
>>> scheme. Expressing time beyond 24 hours can be especially meaningful
>>> when the operator of those features decided to release their time this
>>> way and it can reduce error when inputing or transporting data into
>>> OSM as it is not uncommon for people to forget properly converting
>>> dates when they are asked to change the time format back to 00-23h
>>> format.
>>>
>>> And while it seems like the de facto standard, I would also like to
>>> see the formalization of the handling of time range representation
>>> like Su 23:00-07:00 that in such syntax the 07:00 is referring to
>>> 07:00 on the next day.
>>>
>>> Any thought on the proposal?
>>>

Think best to separate it from the present opening hours.

Perhaps   opening_hours:persian=* (example - where the Persian calendar
is in use).???



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Expand the key:opening_hours

Sergio Manzi
On 2019-03-14 01:28, Warin wrote:
> Think best to separate it from the present opening hours.
>
> Perhaps   opening_hours:persian=* (example - where the Persian calendar is in use).???

Good idea!

Sergio



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Expand the key:opening_hours

Phake Nick
In reply to this post by Warin
Separating it from the current system might have the advantage that it
will not need to use the same syntax to support all regional specific
methods of day counting and time counting at once, but even after
separated it will still need to support the full set of current
opening_time specification in addition to those regional
specifications.

Warin <[hidden email]> 於 2019年3月14日週四 上午8:29寫道:

>
> On 14/03/19 10:52, Simon Poole wrote:
> >
> > Just a PS: any grammar extension need to be compatible with the use of
> > OH strings in conditional restrictions too, see
> > https://wiki.openstreetmap.org/wiki/Conditional_restrictions . While I
> > haven't looked at in detail your proposal for a timezone extension
> > might have difficulties with that.
> >
> > Am 14.03.2019 um 00:38 schrieb Simon Poole:
> >> The basic problem with proposing an extension to the current OH grammar
> >> is that it is already far too complicated and full of ambiguities, there
> >> are afaik currently only two parsers that handle > 90% of the grammar
> >> and most of the other ones are rather broken, adding more stuff is
> >> definitely not going to improve things.
> >>
> >> That said, there are one or two places where extensions would be low
> >> impact (extra holiday and variable_date  values for example). However in
> >> any case I would suggest you familiarize yourself with the actual
> >> grammar
> >> https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification
> >> first , in particular your proposal begins with a couple of non-starters
> >> that conflict directly with the existing specification.
> >>
> >> Simon
> >>
> >> Am 13.03.2019 um 19:52 schrieb Phake Nick:
> >>> I found that the current way of mapping opening time of features in
> >>> OSM map are too limiting, and the opening time of some features cannot
> >>> be properly represented with only the current syntax, therefore I have
> >>> written a brief idea about how the syntax in key opening_hours could
> >>> have been expanded to match more different needs at the article's talk
> >>> page. Seehttps://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#Proposed_extension_to_supported_syntax_in_the_page.
> >>> . It would be nice if these features can be added into the scheme so
> >>> that relevant featurs opening days and time can be represented by the
> >>> scheme directly instead of via text description and external link.
> >>>
> >>> The most significant part of what I would like to see are support for
> >>> solar term(節氣/节气/節気/절기/Tiết khí) and (East Asia) lunar (lunisolar)
> >>> calendar(舊曆/旧历/旧暦/음력/Nông lịch). And because the calculation of both
> >>> are dependent on timezone and then when some countries celebrate these
> >>> festivals they use the calendar that is not based on their own
> >>> country's time but use the Chinese time (or time of other countries
> >>> for overseas diaspora of them) so I have also added a proposal to
> >>> support timezone specification in the scheme which is also desired by
> >>> some other users on the talk page. Note that the scheme I proposed to
> >>> express solar term and lunar month representation wasn't actually that
> >>> much intuitive but I believe it have an advantage that it's more
> >>> internationalized and thus providing a common way of tagging features
> >>> across different regions that use the calendar.
> >>>
> >>> Additionally, I have also written in the proposal that I would like to
> >>> see additional supported values for bank holidays, offset in term of
> >>> number of weeks, and also support for timestamp beyond 24 hours in the
> >>> scheme. Expressing time beyond 24 hours can be especially meaningful
> >>> when the operator of those features decided to release their time this
> >>> way and it can reduce error when inputing or transporting data into
> >>> OSM as it is not uncommon for people to forget properly converting
> >>> dates when they are asked to change the time format back to 00-23h
> >>> format.
> >>>
> >>> And while it seems like the de facto standard, I would also like to
> >>> see the formalization of the handling of time range representation
> >>> like Su 23:00-07:00 that in such syntax the 07:00 is referring to
> >>> 07:00 on the next day.
> >>>
> >>> Any thought on the proposal?
> >>>
>
> Think best to separate it from the present opening hours.
>
> Perhaps   opening_hours:persian=* (example - where the Persian calendar
> is in use).???
>
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Expand the key:opening_hours

SimonPoole
Some more comments:

- the OH values are currently always evaluated in the local time zone
(or to go even a bit further in a local context as the location they
apply to is always known), so a time zone indicator would be only needed
in the cases that require different processing, the question is if that
is common enough to justify the additional complication.

- Summer and winter solstice can be, as far as I can see, modelled as
additional variable_date values (currently only "easter" is defined), I
would avoid qualifying them with months as again, that require parser
changes that will cause issues.

- Lunar months: are there any common names for these instead of just
numbering? And how are the "leap" variants supposed to be different?

Simon

Am 14.03.2019 um 02:03 schrieb Phake Nick:

> Separating it from the current system might have the advantage that it
> will not need to use the same syntax to support all regional specific
> methods of day counting and time counting at once, but even after
> separated it will still need to support the full set of current
> opening_time specification in addition to those regional
> specifications.
>
> Warin <[hidden email]> 於 2019年3月14日週四 上午8:29寫道:
>> On 14/03/19 10:52, Simon Poole wrote:
>>> Just a PS: any grammar extension need to be compatible with the use of
>>> OH strings in conditional restrictions too, see
>>> https://wiki.openstreetmap.org/wiki/Conditional_restrictions . While I
>>> haven't looked at in detail your proposal for a timezone extension
>>> might have difficulties with that.
>>>
>>> Am 14.03.2019 um 00:38 schrieb Simon Poole:
>>>> The basic problem with proposing an extension to the current OH grammar
>>>> is that it is already far too complicated and full of ambiguities, there
>>>> are afaik currently only two parsers that handle > 90% of the grammar
>>>> and most of the other ones are rather broken, adding more stuff is
>>>> definitely not going to improve things.
>>>>
>>>> That said, there are one or two places where extensions would be low
>>>> impact (extra holiday and variable_date  values for example). However in
>>>> any case I would suggest you familiarize yourself with the actual
>>>> grammar
>>>> https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification
>>>> first , in particular your proposal begins with a couple of non-starters
>>>> that conflict directly with the existing specification.
>>>>
>>>> Simon
>>>>
>>>> Am 13.03.2019 um 19:52 schrieb Phake Nick:
>>>>> I found that the current way of mapping opening time of features in
>>>>> OSM map are too limiting, and the opening time of some features cannot
>>>>> be properly represented with only the current syntax, therefore I have
>>>>> written a brief idea about how the syntax in key opening_hours could
>>>>> have been expanded to match more different needs at the article's talk
>>>>> page. Seehttps://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#Proposed_extension_to_supported_syntax_in_the_page.
>>>>> . It would be nice if these features can be added into the scheme so
>>>>> that relevant featurs opening days and time can be represented by the
>>>>> scheme directly instead of via text description and external link.
>>>>>
>>>>> The most significant part of what I would like to see are support for
>>>>> solar term(節氣/节气/節気/절기/Tiết khí) and (East Asia) lunar (lunisolar)
>>>>> calendar(舊曆/旧历/旧暦/음력/Nông lịch). And because the calculation of both
>>>>> are dependent on timezone and then when some countries celebrate these
>>>>> festivals they use the calendar that is not based on their own
>>>>> country's time but use the Chinese time (or time of other countries
>>>>> for overseas diaspora of them) so I have also added a proposal to
>>>>> support timezone specification in the scheme which is also desired by
>>>>> some other users on the talk page. Note that the scheme I proposed to
>>>>> express solar term and lunar month representation wasn't actually that
>>>>> much intuitive but I believe it have an advantage that it's more
>>>>> internationalized and thus providing a common way of tagging features
>>>>> across different regions that use the calendar.
>>>>>
>>>>> Additionally, I have also written in the proposal that I would like to
>>>>> see additional supported values for bank holidays, offset in term of
>>>>> number of weeks, and also support for timestamp beyond 24 hours in the
>>>>> scheme. Expressing time beyond 24 hours can be especially meaningful
>>>>> when the operator of those features decided to release their time this
>>>>> way and it can reduce error when inputing or transporting data into
>>>>> OSM as it is not uncommon for people to forget properly converting
>>>>> dates when they are asked to change the time format back to 00-23h
>>>>> format.
>>>>>
>>>>> And while it seems like the de facto standard, I would also like to
>>>>> see the formalization of the handling of time range representation
>>>>> like Su 23:00-07:00 that in such syntax the 07:00 is referring to
>>>>> 07:00 on the next day.
>>>>>
>>>>> Any thought on the proposal?
>>>>>
>> Think best to separate it from the present opening hours.
>>
>> Perhaps   opening_hours:persian=* (example - where the Persian calendar
>> is in use).???
>>
>>
>>
>> _______________________________________________
>> Tagging mailing list
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Expand the key:opening_hours

Phake Nick


在 2019年3月14日週四 20:38,Simon Poole <[hidden email]> 寫道:
Some more comments:

- the OH values are currently always evaluated in the local time zone
(or to go even a bit further in a local context as the location they
apply to is always known), so a time zone indicator would be only needed
in the cases that require different processing, the question is if that
is common enough to justify the additional complication.
The three most prominent area that are still using the calendar nowadays are China, Korea, Vietnam. Each of them have their own version of this lunar calendar with the most notable difference being the meridian used to create the calendar. So that once in a few years you could see reports saying that the lunar calendar and the festival that depends on it are not correct on some software.

Let's say you represent the Lunar New Year as L01 01. The software can assume it mean Chinese New Year in China, Vietnamese New Year in Vietnam, and Korean New Year in Korea. So far so good. But then these festivals aren't just celebrated within these three countries. Places like Thailand, Indonesia, Japan, Australia, America, and many other countries around the world all have different events that would take place for the Lunar New Year. Sometimes they're commercial events that are currently catering specifically to Chinese New Year. Sometimes they are diaspora population that celebrate the festival on the same day as their parent countries. You cannot know which exact day it's referring to without referring to the timezone being used to calculate the calendar, and at least it need to specify Korean/Chinese/Vietnamese version and that is assuming the region will not create any new timezone in the future, like how time changes related to the Vietnamese war caused the North Vietnam and South Vietnam celebrated the new year at different date back then and resulted in some military advantages.

One might think it'd be easier to add CNY/KNY/VNY into the variable holiday separately like easter instead, but there are a number of other events that're celebrated based on local lunar calendar and is celebrated at more places than those aforementioned countries, like Confucius birthday, mid-autumn festival, double nine festival, and so on. If calendar-specific version of all these holidays are all getting their own values as variable-holiday then there would be too many of them.

And there also other scenario that timezone value is useful, for instance iirc Fiji decided that the country will implement DST but the school system operation time will not follow the transition. Or in places like Xinjiang or West Bank where there are two different timezones used by different population living in same area.


- Summer and winter solstice can be, as far as I can see, modelled as
additional variable_date values (currently only "easter" is defined), I
would avoid qualifying them with months as again, that require parser
changes that will cause issues.

Except other solar terms are still used. For example March equinox and September equinox are national holiday in Japan. Setsubun celebration in Japan is mainly a day before first solar term in February but also a day before first solar term in May, August, November. Qing Ming (mainly China, Korea, etc.) is the first solar term in April.


- Lunar months: are there any common names for these instead of just
numbering? And how are the "leap" variants supposed to be different?

Simon

It is usually just numbering, but in Chinese there are nickname for the 11th and 12th month, while in Japanese there are nickname for all the months. Consider that those nick name are less popular, regional-specific and language-specific, it seems like it would be a bad idea to name them after the months.
The "leap" version are for when a year have 13 lunar months. Instead of naming the additional month the 13th month, various criteria are used to select one of those thirteen months, and then name it as the "leap" version of the previous month. There are on average about 7 years with leap month in every 19 years.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Expand the key:opening_hours

SimonPoole


Am 14.03.2019 um 23:18 schrieb Phake Nick:


在 2019年3月14日週四 20:38,Simon Poole <[hidden email]> 寫道:
Some more comments:

- the OH values are currently always evaluated in the local time zone
(or to go even a bit further in a local context as the location they
apply to is always known), so a time zone indicator would be only needed
in the cases that require different processing, the question is if that
is common enough to justify the additional complication.
The three most prominent area that are still using the calendar nowadays are China, Korea, Vietnam. Each of them have their own version of this lunar calendar with the most notable difference being the meridian used to create the calendar. So that once in a few years you could see reports saying that the lunar calendar and the festival that depends on it are not correct on some software.

Let's say you represent the Lunar New Year as L01 01. The software can assume it mean Chinese New Year in China, Vietnamese New Year in Vietnam, and Korean New Year in Korea. So far so good. But then these festivals aren't just celebrated within these three countries. Places like Thailand, Indonesia, Japan, Australia, America, and many other countries around the world all have different events that would take place for the Lunar New Year. Sometimes they're commercial events that are currently catering specifically to Chinese New Year. Sometimes they are diaspora population that celebrate the festival on the same day as their parent countries. You cannot know which exact day it's referring to without referring to the timezone being used to calculate the calendar, and at least it need to specify Korean/Chinese/Vietnamese version and that is assuming the region will not create any new timezone in the future, like how time changes related to the Vietnamese war caused the North Vietnam and South Vietnam celebrated the new year at different date back then and resulted in some military advantages.

That's all fine and dandy, but the OSM opening_hours tags is for the opening hours of facilities and similar, not a general purpose event description facility. So I would expect that a shop in AUS that is closed on a Chinese holiday to indicate that in a local Gregorian calendar fashion.


One might think it'd be easier to add CNY/KNY/VNY into the variable holiday separately like easter instead, but there are a number of other events that're celebrated based on local lunar calendar and is celebrated at more places than those aforementioned countries, like Confucius birthday, mid-autumn festival, double nine festival, and so on. If calendar-specific version of all these holidays are all getting their own values as variable-holiday then there would be too many of them.

And there also other scenario that timezone value is useful, for instance iirc Fiji decided that the country will implement DST but the school system operation time will not follow the transition. Or in places like Xinjiang or West Bank where there are two different timezones used by different population living in same area.


- Summer and winter solstice can be, as far as I can see, modelled as
additional variable_date values (currently only "easter" is defined), I
would avoid qualifying them with months as again, that require parser
changes that will cause issues.

Except other solar terms are still used. For example March equinox and September equinox are national holiday in Japan. Setsubun celebration in Japan is mainly a day before first solar term in February but also a day before first solar term in May, August, November. Qing Ming (mainly China, Korea, etc.) is the first solar term in April.


- Lunar months: are there any common names for these instead of just
numbering? And how are the "leap" variants supposed to be different?

Simon

It is usually just numbering, but in Chinese there are nickname for the 11th and 12th month, while in Japanese there are nickname for all the months. Consider that those nick name are less popular, regional-specific and language-specific, it seems like it would be a bad idea to name them after the months.
The "leap" version are for when a year have 13 lunar months. Instead of naming the additional month the 13th month, various criteria are used to select one of those thirteen months, and then name it as the "leap" version of the previous month. There are on average about 7 years with leap month in every 19 years.

The whole reason that the OH spec is such a mess is because it tries to remain human readable (for non-nerds), I doubt that there is any support for suddenly departing from that. A OH evaluator needs to have the logic for determining if it is a leap year or whatever, the OH grammar simply needs to define strings which correspond to the commonly used month names.

Simon



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Expand the key:opening_hours

Phake Nick
Of course such shop will also need to indicate the closing date in Gregorian calendar fashion, but as those date are not fixed, if you are typing that information in Gregorian calendar into OSM then you're effectively inputting one-off event into OSM that needs to be changed every year to match the calendar of the year.

在 2019年3月17日週日 01:57,Simon Poole <[hidden email]> 寫道:


Am 14.03.2019 um 23:18 schrieb Phake Nick:


在 2019年3月14日週四 20:38,Simon Poole <[hidden email]> 寫道:
Some more comments:

- the OH values are currently always evaluated in the local time zone
(or to go even a bit further in a local context as the location they
apply to is always known), so a time zone indicator would be only needed
in the cases that require different processing, the question is if that
is common enough to justify the additional complication.
The three most prominent area that are still using the calendar nowadays are China, Korea, Vietnam. Each of them have their own version of this lunar calendar with the most notable difference being the meridian used to create the calendar. So that once in a few years you could see reports saying that the lunar calendar and the festival that depends on it are not correct on some software.

Let's say you represent the Lunar New Year as L01 01. The software can assume it mean Chinese New Year in China, Vietnamese New Year in Vietnam, and Korean New Year in Korea. So far so good. But then these festivals aren't just celebrated within these three countries. Places like Thailand, Indonesia, Japan, Australia, America, and many other countries around the world all have different events that would take place for the Lunar New Year. Sometimes they're commercial events that are currently catering specifically to Chinese New Year. Sometimes they are diaspora population that celebrate the festival on the same day as their parent countries. You cannot know which exact day it's referring to without referring to the timezone being used to calculate the calendar, and at least it need to specify Korean/Chinese/Vietnamese version and that is assuming the region will not create any new timezone in the future, like how time changes related to the Vietnamese war caused the North Vietnam and South Vietnam celebrated the new year at different date back then and resulted in some military advantages.

That's all fine and dandy, but the OSM opening_hours tags is for the opening hours of facilities and similar, not a general purpose event description facility. So I would expect that a shop in AUS that is closed on a Chinese holiday to indicate that in a local Gregorian calendar fashion.


One might think it'd be easier to add CNY/KNY/VNY into the variable holiday separately like easter instead, but there are a number of other events that're celebrated based on local lunar calendar and is celebrated at more places than those aforementioned countries, like Confucius birthday, mid-autumn festival, double nine festival, and so on. If calendar-specific version of all these holidays are all getting their own values as variable-holiday then there would be too many of them.

And there also other scenario that timezone value is useful, for instance iirc Fiji decided that the country will implement DST but the school system operation time will not follow the transition. Or in places like Xinjiang or West Bank where there are two different timezones used by different population living in same area.


- Summer and winter solstice can be, as far as I can see, modelled as
additional variable_date values (currently only "easter" is defined), I
would avoid qualifying them with months as again, that require parser
changes that will cause issues.

Except other solar terms are still used. For example March equinox and September equinox are national holiday in Japan. Setsubun celebration in Japan is mainly a day before first solar term in February but also a day before first solar term in May, August, November. Qing Ming (mainly China, Korea, etc.) is the first solar term in April.


- Lunar months: are there any common names for these instead of just
numbering? And how are the "leap" variants supposed to be different?

Simon

It is usually just numbering, but in Chinese there are nickname for the 11th and 12th month, while in Japanese there are nickname for all the months. Consider that those nick name are less popular, regional-specific and language-specific, it seems like it would be a bad idea to name them after the months.
The "leap" version are for when a year have 13 lunar months. Instead of naming the additional month the 13th month, various criteria are used to select one of those thirteen months, and then name it as the "leap" version of the previous month. There are on average about 7 years with leap month in every 19 years.

The whole reason that the OH spec is such a mess is because it tries to remain human readable (for non-nerds), I doubt that there is any support for suddenly departing from that. A OH evaluator needs to have the logic for determining if it is a leap year or whatever, the OH grammar simply needs to define strings which correspond to the commonly used month names.

Simon



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Expand the key:opening_hours

Warin
In reply to this post by Sergio Manzi
On 14/03/19 11:30, Sergio Manzi wrote:
> On 2019-03-14 01:28, Warin wrote:
>> Think best to separate it from the present opening hours.
>>
>> Perhaps   opening_hours:persian=* (example - where the Persian calendar is in use).???
> Good idea!
>

Happy Nowruz, Persian year 1398.



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging