[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 <61sundowner at 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 at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190314/e6fdbeb9/attachment.sig>