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
