Re: [Tagging] Expand the key:opening_hours

[Warin]

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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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  寫道：

>
> Am 14.03.2019 um 23:18 schrieb Phake Nick:
>
>
>
> 在 2019年3月14日週四 20:38，Simon Poole  寫道：
>
>> 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 

Re: [Tagging] Expand the key:opening_hours

[Simon Poole]

Am 14.03.2019 um 23:18 schrieb Phake Nick:
>
>
> 在 2019年3月14日週四 20:38，Simon Poole  > 寫道：
>
> 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 

Re: [Tagging] Expand the key:opening_hours

[Phake Nick]

在 2019年3月14日週四 20:38，Simon Poole  寫道：

> 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Expand the key:opening_hours

[Simon Poole]

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 <61sundow...@gmail.com> 於 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 

Re: [Tagging] Expand the key:opening_hours

[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 <61sundow...@gmail.com> 於 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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Expand the key:opening_hours

[Simon Poole]

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
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Expand the key:opening_hours

[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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging