I frequently find opening hours of shops etc. with different times for лято/зима I often assume that лято = Apr-Sep and зима is Oct-Mar and tag these hours on the PoI but of course лято and зима are more vague than that. How do others here tag such opening hours? Any better suggestions?
Разглеждайки примерите от opening_hours evaluation tool , си мисля за такъв примерен вариант:
Jun 22-Dec 22: Mo-Fr 08:00-19:00; PH off
Dec 22-Jun 22: Mo-Fr 09:00-18:00; PH off
Това при условие, че приемем за начална дата на астрономическото лято 22 юни, а на зимата - 22 декември.
Ако трябва да сме много точни, можем да потърсим в различни changesets обекти, при които имаме данни за различно работно време през двата сезона и на базата на болшинството от тях статистически да се извадят интервали. Но как ще стане технически… Трябва да се рови историята на обектите. Например, при твоите проверки ти виждаш, че за поне 6 обекта има обявено работно време за месеци април-септември от 8 до 18 ч., а за месеците септември до април - 9 до 17 ч. И въз основа на такива данни би могло да се говори за тенденция и се документира после в уикито и т.н. Тук целиш еднаквост на месеците, часовете може да са различни.
Update: Имаше грешка в синтаксиса на примера, която оправих. Двата сезона се разделят с точка и запетая. Валидаторът приема
Jun 22-Dec 22: Mo-Fr 08:00-19:00; PH off; Dec 22-Jun 22: Mo-Fr 09:00-18:00; PH off
Take this shop as an example Node: 10 Клептуза (14065485495) | OpenStreetMap Someone tagged the opening hours as opening_hours=Summer 08:30-21:30; Winter 08:30-19:30This is human-readable, but software can’t handle this as “Summer” and “Winter” are undefined values and it won’t be able to tell you if at 20.13 on 5th June, this shop is open or not. For it to be machine-readable, we have to use a more precise description of the hours in different periods of the year, however the sign on the door probably doesn’t offer it. What is our best choice for the start and end of summer and winter to feed to the software so that it is most likely to be correct most of the time? Astronomical summer/winter, daylight saving time periods, nice/not nice weather periods, …? This is a cultural question and that’s why I’m asking it in this forum and not on the international one: what do we think is most likely what a Bulgarian shop owner means by “лято” & “зима”? The alternative is to keep “Summer” and “Winter” in the tag value, with the result that software will always return an error.
what a Bulgarian shop owner means by “лято” & “зима”?
Аз си мисля, че всеки, който използва такова работно време, трябва да не се възприема сериозно 
Да, сигурно има частни случаи, когато бизнесът зависи от смяната на лятно/зимно часово време и часовникът се върти +/- 1 час. Тогава има някаква логика да се взема в предвид смяната на часа, но това не се случва на точна дата, а е в ранните часове на неделен ден.
Повече смисъл има за курортните обекти, които зависят от туристическият сезон. Там също няма точна дата. Летният сезон може да започне късно, заради дъждовна пролет. Зимният сезон може да приключи рано, поради липса на сняг.
Ще се повторя, но не бих разчитал на подобно сезонно работно време. На машинките, които искат да работят с точни данни, им е трудно, но трябва и те да разберат, че обикновето това е препоръчително работно време и няма категорична граница. Този пример с 20:13 часа, трябва да се възприема като задача от квантовата физика - докато не видиш с очите си обекта, няма да знаеш дали работи или не работи.
Fact is that such shops exit, including the new courier chain Pigeon Express. Should we boycot the mapping of opening hours of these shops?
The reason I arbitrarily chose to enter them as лято = Apr-Sep, зима = Oct-Mar is that this is easy to enter on StreetComplete. лято = last Sunday in March - last Sunday in October is more difficult to enter (though possible). We’d have to ask the shop operators what they understand by their opening hours.
Е, не да ги бойкотираме. Но пък в другата тема за училищата, говорехме, че не трябва да тагваме за рендера. И докато там имаме ясни данни, които просто се систематизират, тук случаят е, че нямаме точни данни и си измисляме граници, които може да са правилни, но може и да не са. Но си ги натъкмяваме за да може рендера да изплюе точна стойност.
Не съм видял какво е работното време на Pigeon Express, но най-правилният подход би бил да се поискат точни данни. Всичко останало е налучкване.