[Tagging] Expand the key:opening_hours
61sundowner at gmail.com
Thu Mar 14 00:28:35 UTC 2019
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
>> first , in particular your proposal begins with a couple of non-starters
>> that conflict directly with the existing specification.
>> 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
>>> 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).???
More information about the Tagging