Да.
Художественные кружки - amenity=training + training=art.
Физкульт школы - amenity=training + training=sport.
Сейчас я себе это так представляю: на территорию вешается amenity=school + name=Учебно-воспитательный комплекс #5 (например), все остальные объекты (детский сад, художественная школа, музыкальная школа и т. д.) обозначаются отдельными объектами внутри этой территории.
fserges, это называется конкретное мышление - неспособность к абстракции, то есть выделению в привычных объектах и явлениях характеризующих их свойств. Такие люди всегда хотят иметь отдельный термин для каждого экземпляра объекта или явления, несмотря на минимальные или неопределенные различия между ними.
Набросал черновик предложения по образовательным учреждениям. Схема создавалась с оглядкой на Healthcare 2.0. Поскольку я не работаю в сфере образования описания и теги могут быть неточными, также могут быть фактические ошибки, потому любые предложения приветствуются. После обсуждения сделаю что-то более официальное на английском.
type=education это перебор. Для связи есть всякие operator/owner/branch. А очень заумным связям дело в отдельном проекте.
Я правильно понимаю, что данная схема отменит схему с amenity=training?
предлагаю добавить в системы образования систему Монтессори https://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D0%B4%D0%B0%D0%B3%D0%BE%D0%B3%D0%B8%D0%BA%D0%B0_%D0%9C%D0%BE%D0%BD%D1%82%D0%B5%D1%81%D1%81%D0%BE%D1%80%D0%B8
Ну теги не пересекаются по именам, теоретически можно вместе использовать. Другое дело что там вроде тег палка-верёвка и практически не сообщает никаких деталей об учебном заведении.
Я лишь примерно процитировал то что есть Healthcare 2.0. Если сообщество решит что отношения не нужны, уберу, не проблема собственно.
driving_category:a=yes
education_program:driving_licence=yes
Я заменил бы на:
education_program:category_a=yes
Ыыы, driving_category:ru_a=yes - категории в разных странах - разные.
Я опасаюсь может получится неоднозначно, может лучше education_program:driving_category_a=yes? Так сразу понятно что это курсы вождения, а не чего-либо ещё. Если мне память не изменяет то есть права на вождение водного транспорта, там могут быть схожие категории.
Ок, education_program:ru_driving_category_a=yes, правда длинновато. Не знал кстати что категории по странам разные, права же вроде международные дают. Интересно, а как полицейские других стран в них разбираются?
Это, по идее, будет отражено в education_profile:navigation, education_profile:piloting и т. п.
https://www.gov.uk/driving-licence-categories
https://en.wikipedia.org/wiki/Driver’s_licence_in_Canada
https://en.wikipedia.org/wiki/Driver’s_license_in_the_United_States
зачем нужна такая подробность на карте ? у нас база данных топографических объектов, а не образовательных учреждений. не лучше ли сделать отдельный проект “Open Educational Institutions” и собирать там данные об обр. учреждениях ? а с карты ссылаться на эту базу данных.
OSM это не база топографических объектов. Для чего нужна такая детальность на карте? Да потому что ей люди пользуются, а не топографы.
amenity=school не учитывает:
Это база данных далеко не только топографических объектов. А подробность нужна для внятной и удобной (в использовании) классификации объектов, включённых в базу.
Я на этот вопрос смотрю так:
Определенно, есть спрос на обозначение разного рода сущностей, которые не вписываются в простейший список: детский сад, общеобразовательная школа, колледж, университет (можно добавить еще несколько сущностей, вроде школы вождения). Люди пытаются это обозначать и обозначают всегда плохо (плохо, потому что хорошей схемы нет).
Нет никаких разумных аргументов, чтобы ограничивать людей в желании обозначить это адекватным образом.
При этом пытаться обозначить вообще все-все детали - тоже не обязательно, потому что, по опыту существующих уточняющих свойств, уточнения не столь популярны.
Например, в Москве и ближайших окрестностях всего 1500 школ в базе имеют контактный телефон, тогда как всего обозначено на той же территории около 33000. Это всего 4%.
Детали, которые, грубо говоря, “не указаны на табличке у входа”, имеют весьма малый шанс оказаться в базе.
Потому, мне кажется важным, в первую очередь, указать “корневую сущность”, для чего может быть нужно два-три тега на одном объекте, не больше.
Я очень уважаю схему Healthcare 2.0 и сам, по возможности, стараюсь потихоньку пополнять документацию. Но нужно понимать, что обозначение противотуберкулезного диспансера вот такого вида:
Справедливо, как и для других подробных схем тегирования. Поэтому полезно выработать рекомендованный минимум (“корневую сущность”), являющийся фрагментом предлагаемых детальных схем. А насколько полно уточнять эти детали — решение человека, вносящего данные. Здесь —хорошие пресеты в помощь.
Конечно.
Это я к тому, что когда начинается обсуждение какого-то нового способа, очень многие начинают цепляться к деталям, касающимся обозначения очень специфических свойств.
Меж тем, вероятно, сначала стоит ограничиться именно этими корневыми сущностями (имея в голове необходимость расширяемости), а мелкие детали оставить на потом. Это позволит перекрыть 90% нужд и исключить 90% придирок к второстепенным деталям, составляющим всего 10% конечной пользы от новой схемы. Т.е. ставить реальные цели, а не пытаться объять необъятное.
В этой схеме вот они:
1.education_facility:type
2.education_profile:*