Education 2.0

Причин для “вечных” amenity=* тегов я лично не вижу, amenity - бессмысленная категория, без критериев, слишком общая.

Удалять только на неправильных объектах или когда поддержка 2.0 будет почти везде (основной стиль, редаторы, пару популярных программ).

Да, это удобнее во всех программах, почитай ссылки у меня в подписи про строка=строка.

ну я не имел ввиду, что совсем никогда)) ну, выразился размашисто!

Прошу обратить внимание что в пропозале я исправил некоторые теги - center на centre и program на programme, поскольку в тегах мы используем английский вариант написания слов. Пропозал всё ещё на стадии обсуждения, поэтому возможны и другие изменения в случае если найдутся ещё ошибки или дельные предложения.

Т. е. дифференцировать языковую направленность, чтобы не путалось с курсами по обучению языку (речь, письмо, чтение), родному для местного (и не только) населения.

Если это именно курсы языка, то лучше использовать education_programme:language_eng. Так не выбивается из общей системы.

Сорри, не сразу сообразил что вы имели ввиду. Не уверен имеет ли смысл уточнять конкретные языки в профиле учреждения, обычно потребителю достаточно знать что здесь обучают иностранным языкам, а конкретику смотреть уже в программах. Но если это необходимо, то первый вариант предпочтительнее.

Дело в том, что education_programme может быть в одном центре много для одного и того же языка. Тегировал такие примеры:
amenity=training
contact:email=solminsk@nsys.by
contact:phone=+375(17) 237-76-09;+375(17) 237-76-10
contact:website=http://www.sol.by/
education=centre
education_fee=only
education_for:adolescent=yes
education_for:adult=yes
education_for:child=yes
education_form:parttime=yes
education_profile:foreign_language=yes
education_programme:business_english=yes
education_programme:cae=yes
education_programme:fce=yes
education_programme:ielts=yes
education_programme:toefl=yes
foreign_language=deu;eng;fra;ita;pol;rus;spa
name:ru=СОЛ Минск
name=SOL Минск
training=language

amenity=training
contact:email=study_abroad@str.by
contact:phone=+375(29) 240-18-40;+375(44) 588-77-24;+375(17) 289-18-81
contact:website=http://www.str.by/holiday/
education=centre
education_fee=only
education_form:parttime=yes
education_profile:foreign_language=yes
education_programme:business_english=yes
education_programme:ielts=yes
education_programme:tcf_québec=yes
education_programme:toefl_ibt=yes
education_programme:ösd=yes
education_service:testing=yes
foreign_language=ces;deu;eng;fra;ita;pol;rus;spa;zho
name=Школа иностранных языков Streamline
opening_hours=Mo-Th 10:00-19:00; Fr 10:00-18:00
operator=Учебный центр «Образовательные технологии»
ref=609
standard_testing:act=yes
standard_testing:lcci=yes
standard_testing:tcf_québec=yes
standard_testing:toefl_ibt=yes
standard_testing:ösd=yes
training=language

Этот вариант всё же предпочтительнее чем точки с запятыми.

А чем? Я исходил их компактности при сохранении полноты данных. И то простыня немаленькая вышла.

Semicolon-delimited списки в значениях тегов - скользкая тема. С точки зрения обработки данных это еще один уровень вложенности модели хранения данных и, соответственно, еще один уровень разбора строки относительно обычного “ключ”+“значение”. То есть это такая штука, которая в OSM условно допускается, но никто не горит желанием ее поддерживать. Есть единицы случаев, когда разбор значений реально поддерживается (часы работы - самый известный, но там иначе никак).

Можно напрямую сделать запрос foreign_language:deu=yes и получить ответ.

И вообще: http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator#When_NOT_to_use

Это не зря написано.

Раз такое дело со сложностью обработки данных, то не имею ничего против. Только за.
UPD Не являюсь экспертом, но предлагаю посмотреть на вопрос с другой точки зрения. Как быстрее и удобнее получить информацию о языках, которым обучают в данном заведении (или их множестве):
а) Сделать один запрос, получив исчерпывающий список (из которого нетрудно выделись искомый, если требуется найти конкретный язык)
б) Сделать неопределённое число запросов (в пределе равное кол-ву известных языков)
Или всё упирается в «хитрость» запроса?

Вообще, механизм запросов сильно зависит от сценария использования. Но в конечном счете, все упирается в разбор строк.
Выдернуть из OSM одно значение искомого ключа - легко. А дальше нужно разбирать строку с разделителями, при том неизвестной длины, и из этой строки делать массив признаков (длина которого заранее неизвестна и становится известна только когда строка полностью разобрана, либо ее нужно определить отдельной предварительной операцией подсчета разделителей). И это все в случае идеального следования синтаксису.
В случае же отдельного ключа для каждого языка с использованием префикса пространства имен, уже сам первый запрос “все теги, указывающие на языки”, отдает массив отдельных признаков, каждый из которых можно просто сравнить с искомым.

Стоит при этом понимать, что когда какое-нибудь API, язык запросов или другое подобное средство заточено под работу с тегами в виде “ключ=значение”, оно, вероятнее всего, не содержит инструментов для дальнейшего разбора. Напрмиер, если вам при использовании semicolon-delimited списков придет в голову сделать запрос через Overpass API и найти все учреждения, где преподают японский, вам придется писать в запросе регулярное выражение. А если вам нужно найти, где преподают и японский, и немецкий, то вам понадобится адова конструкция типа вот этого http://www.rubular.com/r/XzVf1NQtjX (этот пример выбирает те строки, которые содержат обе подстроки “jack” и “james” в произвольном порядке). Чуете, в чем тут подвох? А так, вы просто напишете условие с тремя тегами.

Отвечая прямо на ваш вопрос, вариант “б” вообще не используется, так как лишен смысла. А вариант “а” возвращает не исчерпывающий список, а единую строку, которую еще предстоит разобрать.

Я начал голосование за proposal. Вы можете проголосовать здесь. Там же есть описание, если кто забыл о чём он.

Чётко прослеживается, как один обсерун-говорун (но не предлогун как делать, как улучшить, подкорректировать, доработать) быстро находит единомышленников на подхвате, готовых отстаивать и лелеять то дерьмо, которым они довольствуются и во что бы то ни стало желают, чтобы им довольствовались остальные. В говне приятней в компании бултыхаться, а иначе ж делать что-то надо, свой ленивый зад беспокоить.
Поэтому: неча тут новаторствовать — и так сайдёть, мол, недочёты сильныя имеюцца, а сяйчас-то получше будет гораздо. То-то и оно.

…особо забавляют

В следующий раз все образовательные учереждения затегирую по новой схеме.

Единственное замечание что religion=* действительно был уже, есть причины отличать их?.. Остальное - пустой трёп “у нас GIS”. Теги как булевы ключи обсуждали здесь: http://forum.openstreetmap.org/viewtopic.php?id=29907

Они были приняты крен знает сколько лет назад http://wiki.openstreetmap.org/wiki/Proposed_features/boolean_values

Новое предложение нужно чтобы затегировать такую ситуацию:
в каком-то здании есть “курсы языковые” - education=courses + education_profile:languages=yes

Ни чехарда amenity, ни isced:level (который я активно использовал) не предоставляют единой схемы обозначений.

Если чему-то здесь учат - за детальным обозначением нужно обращаться к Proposed features/Education 2.0, потому как другие теги не предоставляли детального обозначения. Даже в isced:level нет способа обозначить отдельные языки.

Тем, кому не нужны теги отдельных языков, автошкол и сертификации могут просто помолчать, а не голосовать “нет”.

Я бы добавил ещё education_profile:pc=yes для курсов владения компьютером.

В принципе, education_profile:=yes я вижу как расширяемый, либо нужно отдельную ветку сделать для курсов брадобрея и макияжа и прочих? Не все они вписываются в education_profile:professional= т.к. профессиональное применение таких навыков потом не обязательно.

Продолжая сказанное, тегирование отедельных навыков не помешало бы:

education_profile:skill:pc=yes
education_profile:skill:barber=yes
education_profile:skill:makeup=yes

Например, школы бульдозеристов очень специфичный навык:
http://service-im.ru/training/podgotovka-mashinista-buldozera.php
http://www.uash.ru/offhighway

education_profile:skill:бульдозерист=yes