[Tagging] Expand the key:opening_hours
simon at poole.ch
Sat Mar 16 17:56:21 UTC 2019
Am 14.03.2019 um 23:18 schrieb Phake Nick:
> 在 2019年3月14日週四 20:38，Simon Poole <simon at poole.ch
> <mailto:simon at poole.ch>> 寫道：
> 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
> in the cases that require different processing, the question is if
> 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
> 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?
> 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 commonly used month names.
> Tagging mailing list
> Tagging at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: OpenPGP digital signature
More information about the Tagging