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 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging