Прошу обратить внимание что в пропозале я исправил некоторые теги - center на centre и program на programme, поскольку в тегах мы используем английский вариант написания слов. Пропозал всё ещё на стадии обсуждения, поэтому возможны и другие изменения в случае если найдутся ещё ошибки или дельные предложения.
Т. е. дифференцировать языковую направленность, чтобы не путалось с курсами по обучению языку (речь, письмо, чтение), родному для местного (и не только) населения.
Сорри, не сразу сообразил что вы имели ввиду. Не уверен имеет ли смысл уточнять конкретные языки в профиле учреждения, обычно потребителю достаточно знать что здесь обучают иностранным языкам, а конкретику смотреть уже в программах. Но если это необходимо, то первый вариант предпочтительнее.
Дело в том, что 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
Semicolon-delimited списки в значениях тегов - скользкая тема. С точки зрения обработки данных это еще один уровень вложенности модели хранения данных и, соответственно, еще один уровень разбора строки относительно обычного “ключ”+“значение”. То есть это такая штука, которая в OSM условно допускается, но никто не горит желанием ее поддерживать. Есть единицы случаев, когда разбор значений реально поддерживается (часы работы - самый известный, но там иначе никак).
Раз такое дело со сложностью обработки данных, то не имею ничего против. Только за. UPD Не являюсь экспертом, но предлагаю посмотреть на вопрос с другой точки зрения. Как быстрее и удобнее получить информацию о языках, которым обучают в данном заведении (или их множестве):
а) Сделать один запрос, получив исчерпывающий список (из которого нетрудно выделись искомый, если требуется найти конкретный язык)
б) Сделать неопределённое число запросов (в пределе равное кол-ву известных языков)
Или всё упирается в «хитрость» запроса?
Вообще, механизм запросов сильно зависит от сценария использования. Но в конечном счете, все упирается в разбор строк.
Выдернуть из OSM одно значение искомого ключа - легко. А дальше нужно разбирать строку с разделителями, при том неизвестной длины, и из этой строки делать массив признаков (длина которого заранее неизвестна и становится известна только когда строка полностью разобрана, либо ее нужно определить отдельной предварительной операцией подсчета разделителей). И это все в случае идеального следования синтаксису.
В случае же отдельного ключа для каждого языка с использованием префикса пространства имен, уже сам первый запрос “все теги, указывающие на языки”, отдает массив отдельных признаков, каждый из которых можно просто сравнить с искомым.
Стоит при этом понимать, что когда какое-нибудь API, язык запросов или другое подобное средство заточено под работу с тегами в виде “ключ=значение”, оно, вероятнее всего, не содержит инструментов для дальнейшего разбора. Напрмиер, если вам при использовании semicolon-delimited списков придет в голову сделать запрос через Overpass API и найти все учреждения, где преподают японский, вам придется писать в запросе регулярное выражение. А если вам нужно найти, где преподают и японский, и немецкий, то вам понадобится адова конструкция типа вот этого http://www.rubular.com/r/XzVf1NQtjX (этот пример выбирает те строки, которые содержат обе подстроки “jack” и “james” в произвольном порядке). Чуете, в чем тут подвох? А так, вы просто напишете условие с тремя тегами.
Отвечая прямо на ваш вопрос, вариант “б” вообще не используется, так как лишен смысла. А вариант “а” возвращает не исчерпывающий список, а единую строку, которую еще предстоит разобрать.
Чётко прослеживается, как один обсерун-говорун (но не предлогун как делать, как улучшить, подкорректировать, доработать) быстро находит единомышленников на подхвате, готовых отстаивать и лелеять то дерьмо, которым они довольствуются и во что бы то ни стало желают, чтобы им довольствовались остальные. В говне приятней в компании бултыхаться, а иначе ж делать что-то надо, свой ленивый зад беспокоить.
Поэтому: неча тут новаторствовать — и так сайдёть, мол, недочёты сильныя имеюцца, а сяйчас-то получше будет гораздо. То-то и оно.
В следующий раз все образовательные учереждения затегирую по новой схеме.
Единственное замечание что religion=* действительно был уже, есть причины отличать их?.. Остальное - пустой трёп “у нас GIS”. Теги как булевы ключи обсуждали здесь: http://forum.openstreetmap.org/viewtopic.php?id=29907
Новое предложение нужно чтобы затегировать такую ситуацию:
в каком-то здании есть “курсы языковые” - 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= т.к. профессиональное применение таких навыков потом не обязательно.