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
Ноющим и несогласным хочется же сразу на блюдечке с золотой каёмкой. Схема «очень сырая», а у нас сейчас какая — тухлая, наверно? Предпочитаю «сырую» (а правильнее — свежую), которую можно приготовить к «употреблению», доведя до кондиции.
Но приятнее ложечкой кушать то, что есть («несырое»).
В любом случае, даже если несогласных будет больше, пользоваться схемой ни кто не запрещает.
Вот это верно. Голосование можно было и не запускать, оставить описание (как Healthcare 2.0) и при необходимости его дополнять/уточнять. Потому что результат предсказуем, на мой взгляд.
education=facultative_school остался в примерах на http://wiki.openstreetmap.org/wiki/Proposed_features/Education_2.0#Old-new_tags_correlation_table
http://wiki.openstreetmap.org/wiki/User:Keder/education_proposal/local_systems нашёл неточность в “Facility that provides additional primary specialized education” - education=facultative_school. primary это основное образование, либо убрать “primary” либо исправить на “additional to the primary” - но не звучит.
education=test_centre примеры объектов неплохо было бы, а то потом разночтения будут. Разница между education=centre + education_service:testing=yes и education=test_centre сомнительна для пользователей будет наверняка (education=test_centre я бы убрал).
Надо заготовки для JOSM начинать делать https://josm.openstreetmap.de/wiki/TaggingPresets
iD будет поддерживать эту схему в принципе потому что виджет сделали такой: https://github.com/openstreetmap/iD/issues/3034 всё что не хватает это написать заготовки к iD
religion=* есть и он обозначает религию к которой относится данное учреждение, его следует отличать от education_profile:religion который говорит что обучение данной религии является одной из специализаций учреждения. education_profile должен указывать общее направление обучения в учреждении, а конкретные вещи вроде учёбы на плотника должны идти в education_programme. Увы некоторые из голосовавших решили не читать пропозал, потому и начали высказываться что мол, как мы перетегируем миллион учреждений. Один вообще не стал заморачиваться и написал что мол всё слишком сложно. Моё любимое: “operator=* не может использоваться для связи объектов поскольку это простая строка”, когда я такое говорил на форуме, меня какахами закидали.
Читая само предложение и комментарии на него, возникает мысль, что такие объемные предложения во-первых, нужно еще подробнее описывать (возможно, с картинками-инфографикой для идиотов), а во-вторых, закладывать в описание анти-демагогические тезисы, чтобы вот “слишком сложно” сказать уже так просто было нельзя, не выставив себя идиотом.
Поддержу BushmanK. Чтобы сделать мир лучше иногда нужно хорошо попотеть тогда как многие считают что достаточно кинуть хорошую идею и всё само образуется.
А закончить традиционным - “то что нас не убивает делает нас сильнее”. Опыт пришёл и пользуясь им можно перейти на новый уровень.
fserges, BushmanK борьба с идиотами это немаловажная, но пе первостепенная задача этого пропозала. Само предложение и так большое, но вполне читаемое, пока ещё. Если же всё расжёвывать с историей, откуда такие объекты берутся (факультативные школы и кружки) то пропозал будет не удобен тем, кому он действительно нужен и кто всё знает и без объяснений. Писание документации и уточнение это хорошо, но отнимает время. Возвращаясь к isced:level=* - даже материалы UNESCO без ссылок на все местные законы и детали как ребёнок проходит все стадии обучения.
Если большинство объектов тегируются нормально по схеме (школы, университеты, языковые школы, полигоны водителей и военных), а небольшой процент - нужно обсуждать, то это не проблема целой схемы, а того небольшого процента объектов которые в принципе не просто формализовать.
Для того, чтобы предложение было принято, нужно оформлять его не как заблагорассудится или для сферической аудитории в вакууме, а для тех людей, которые будут за(против) него голосовать. Это всего лишь учёт объективной реальности (противоположность существованию в выдуманном идеальном мире).
Когда предложение сложнее мычания, всегда найдется идиот, который напишет: “это слишком сложно → никто не будет это использовать → это не нужно” (и сделает это не в обсуждении, а в голосовании). Потому такие вещи стоит адресовать сразу, а не потом, чтобы за этим первым идиотом остальные то же не повторили.
Кроме того, любая схема, касающаяся существующих объектов, вызывает рефлекс, с которого начал эту тему Zverik (которого мы, к слову, помним по кривому предложению которое он сделал через год после регистрации): “А-а! Он предлагает переобозначить миллион объектов!”
Не адресовать это - просто подставиться.
Также, хотя примеры применения новой схемы важны, точно также важна и иллюстрация того, что легко может новая схема из того, что принципиально не может старая. И на это нужно упирать в первую очередь, потому что для идиотов это - единственный (если это вообще для них возможно) видимый плюс любой новой схемы, так как кривизну и непоследовательность существующих они просто не видят. Так что, опять же, ткнуть их носом в то, чего нельзя было сделать раньше, но можно сделать теперь - нужно.
Лично я потому и не берусь пока за составление предложений, потому что успешное голосование за сложную схему требует всей этой последовательной подготовительной работы, которая направлена, главным образом, на тех, кому реально всё равно, но кто будет голосовать против (если не предупредить это) по кретинским мотивам типа “я этого не понимаю, значит автор пытается умничать, ну-ка накажем его за это”. А сделать все формально, чтобы потом вставать в позу непризнанного гения - это просто непродуктивно.