Прошу обратить внимание что в пропозале я исправил некоторые теги - 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
Ноющим и несогласным хочется же сразу на блюдечке с золотой каёмкой. Схема «очень сырая», а у нас сейчас какая — тухлая, наверно? Предпочитаю «сырую» (а правильнее — свежую), которую можно приготовить к «употреблению», доведя до кондиции.
Но приятнее ложечкой кушать то, что есть («несырое»).
В любом случае, даже если несогласных будет больше, пользоваться схемой ни кто не запрещает.