Education 2.0

Основная проблема, как с той же social_facility - это уместить абзац текста определения в 1-2 слова заготовки.

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

зачем использовать education=* , когда можно добавить недостающие обр. учреждения в amenity ? например вместо education=courses использовать amenity=courses.

тем самым схема избавится от экспансионистских претензий на замену старой схемы и избавится от дублирования вроде amenity=kindergarten + education=kindergarten

это проблема номер два этой схемы.

проблема номер один, на мой взгляд - излишне подробные описания. лучше отсылать в википедию (или на специализированный сайт вроде сайтов с базой православной архитектуры http://sobory.ru/geo/ за более подробной информацией. об этом писал как-то в другой теме. иначе из картографического проекта получается база данных учреждений со всеми деталями. нарушается важный инженерный принцип - разделение ответственности различных систем и сервисов.

Мы тут базу данных как бы составляем, а не набор жёлтых страниц. Ссылка на страницу никак не поможет увидеть в округе школы для девочек-блондинок-левшей.

А почему в 1-2? Я делал заготовки, и по семь-восемь слов определение получалось, все работало. Да и сделать хотя бы для основных российских понятий - общеобраз. школа, детсад, художка, музыкалка…

Самое эффективное «голосование» — делом: тегирование объектов, создание пресетов, перевод страниц документации, устранение замеченных недочётов, продвижение поддержки в приложениях.

Проблема ключа amenity в том что он ни о чём, это просто мусорка куда кидают то что не подошло в другие категории. Зачем нужен ключ если он не играет никакой роли? education же ключ позволяет не напрягаясь разом выгрузить все учреждения связанные с образованием.

Поддерживаю. amenity - супер-общий ключ, назначение которого и описать-то толком не получится, который также не имеет никакого практического смысла без значений (то есть запрос amenity=* выдаст всё подряд).
Отдельный ключ для класса образовательных учреждений (а это совершенно ясная категория без размытых краёв) - совершенно логичная мера, повышающая качество данных. Для выборки нужен только запрос education=*, а не amenity=длинный список всех вариантов. Это, к слову, и с точки зрения производительности запроса куда лучше.

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

ок. есть ли ещё какие-то преимущества, кроме удобного запроса всех образовательных учереждений разом ?

кстати, тут можно подмать ещё над двумя вопросами: часто ли встречается на практике такой запрос. всех обр. учреждений от институтов до автокурсов. и так ли неудобен поиск с условием состоящим из нескольких amenity.

конечно упорядоченная структура где всё по полочкам выглядит красивее. но кроме красоты интересны практические преимущества. одно у нас есть - удобный запрос. с преимуществом понятно. но что с недостатками ?

плюсы:

  • красота. всё по полочкам. сгруппированность.
  • удобный запрос

и минусы:

  • необходимость поддержки новых тегов в инструментах, рендерах и прочих сервисах. (кто будет пул реквесты слать ?)
  • необходимость поддержки так же старых тегов. (их пока ещё 99%)
  • так как поддержка появится мягко говоря не сразу, мапер должен будет вносить дублирующиеся теги. другие будут созерцать и работать с такими дубликатами.
  • необходимость в документации новых тегов. отдельные страницы или редирект на старые теги ?
  • пресеты для редакторов. тоже дублировать ? ведь старые пресеты мы не убираем.
  • нужно будет отдельно описать или постоянно объяснять на форуме тонкости отличий старой версии тега от новой. и есть ли такие различия для конкретно типа обр. учр. и почему можно или нужно использовать одно, а не другое.
  • что если добавят в старую схему, новые недостающие теги для обр. учр.? их нужно будет “синхронизировать” с новой схемой.
  • лишний стресс от выбора между двух вариантов. портит всё удовольствие от созерцания красоты “сгруппированности” :slight_smile: шутка.

не слишком ли много минусов для “удобного запроса” ?

Если плюсы представить как говноплюсы, а «минусы» раздуть, то и думать нечего: победил EugenyN и сотоварищи. Публика аплодирует, занавес.
А если подумать?
Грамотная схема тегирования решает задачи хорошей организации информации (=>удобство внесения и применения) и её большей адекватности по отношению к обозначаемым объектам (=>широкий охват в конкретной области и большая детализация). Это необходимые и достаточные условия применения.
Далее по «минусам». Необходимость поддержки — не проблема схемы, а дополнительная задача, стоящая за её рамками. Пул реквесты будут писать заинтересованные в улучшениях люди.
Старые теги уже поддерживаются, о чём вообще речь?
Дублирование схем будет необходимо до момента осознанного перехода на более гибкую и упорядоченную (с её поддержкой в большинстве случаев). Старая отпадёт, как рудимент.
Документация уже есть (снова непонятно, о какой «необходимости» речь), достаточно перекрёстных ссылок.
Пресеты «дублировать» нет надобности, они существуют с пометками «новая схема»/«старая схема» (как с ОТ).
Никакие «тонкости» объяснять не надо (потому что их нет). Есть описанная новая схема, включающая в себя все старые объекты+новые+доп. св-ва, ранее никак не отражаемые.
О какой «синхронизации» речь — не понятно в очередной раз. Она будет происходить автоматически (при наличии перекрёстных ссылок на страницах документации).

это общие слова. “задачи хорошей организации”, “удобство внесения и применения”, “большей адекватности” “широкий охват в конкретной области”, “большая детализация” - какие значения у этих поэтических образов ? объясните на конкретных практических примерах, как сделали выше, приведя пример с “удобным запросом”.

насчёт удобства запроса. когда я работал с maperitive (думаю другие рендеры делают так же) . так вот рендер часто работает не с самими тегами, а с собственными типами/группами вроде “лес”, “вода”, “обр. учреждение”, которые определяются уже с помощью тегов. т.е. создаётся дополнительный слой абстракции.

например

features
areas
academic : node[@isOneOf(amenity, university, college, school)] area[@isOneOf(amenity, university, college, school)]
water : natural=water OR waterway=riverbank OR landuse=reservoir OR landuse=basin or waterway=dock

и дальше работа идёт с таким типом как “academic” и “water”. так что тут нет сложностей с “запросом” он и так удобен.

За «общими словами» стоят конкретные смыслы.
Хорошая организация — когда мы обозначаем, а потом ищем всё, что связано с обучением, в графе «Обучение» (а не в графе «Сортиры»).
Большая адекватность — когда обозначаем «public_transport=platform», а не «highway=bus_stop».
Широкий охват — возможность обозначить то, что ранее вообще не обозначалось никак (или абы как), причём — именно в том namespace, которому объект наиболее соответствует.
Большая детализация — обозначение тех признаков, которые ранее никак не обозначались (или через пень-колоду).
И хватит уже долдонить про «только удобный запрос».

Keder, были ли замечены указания на действительные недочёты (что называется «по делу») в предложенной схеме и есть ли в планах их устранить?
Под действительными подразумеваю не из разряда «я ни хрена не понял (не очень-то и старался) и выступаю против», или «мне не нравится эта схема, она придумана русским», или «почему не предусмотрели продажу печенек в столовой?», или «нет объектов, УЖЕ обозначенных по данной схеме, зато есть миллионы говнообъектов, кое-как обозначенных и это число неуклонно растёт», или «а-а-а-а, какой ужос — это ж сколько перетегировать придётся!», или «эта схема никем и нигде не будет поддерживаться», или «я против, а далее — простыня в стиле «бла-бла-бла о космических кораблях, бороздящих просторы Вселенной».

Да, по поводу того, только или не только простота запроса важна. Это классическая демагогия, употребляемая в ситуации, когда предлагается любое усовершенствование: сказать, что “если постараться, можно справиться со всем”. Объем усилий, которые кто-либо готов приложить при обработке данных (да и вообще, всегда) - ограничен. Чем он меньше и чем очевиднее то или иное решение, тем лучше, потому что большее количество людей готовы будут с этим возиться, употребляя меньший объем ресурсов. Приблизительно об этом я писал в своей последней записи в дневниках, давая разъяснение, почему списки свойств, разделенные точкой с запятой - геморрой, а бинарные теги - куда меньшее зло.

Другая демагогия - это сказать “для меня эти плюсы (или минусы) теоретически не важны, потому они не важны вообще”. Это говорится в форме объявления этих плюсов (минусов) “трёпом”, “общими словами” и так далее, а “сколько-нибудь реальным” аргументом, как раз, выбирается тот, который демагог считает наиболее простым для опровержения (в том числе, способом, упомянутым выше). Логично объяснить, почему в реальном случае (а не теоретически) эти моменты незначительны, демагог, традиционно, не может.

Да, и производительность запросов, а также возможность не использовать дополнительные уровни абстракции (фильтрации, нормализации данных) - это уже весомый плюс, даже если нет никаких других.

Ну есть возражения на счёт education=department, тут я и сам сомневаюсь как правильно указывать подразделения. В остальном же люди либо не внимательно читали пропозал (например возражение о том что education_system:religious не нужен поскольку есть religion), либо (их большинство) возражения против ключей с двоеточиями (что странно поскольку их у нас полно). Возможно стоит сделать больше примеров и привести пояснения для непонятливых вроде предложенных BushmanK, но не знаю как будет время и желание. Мне всё же маппить нравится больше. Я, кстати, не буду возражать если кто-то присвоит предложение и переделает по-своему.

об этих двух плюсах я писал. http://forum.openstreetmap.org/viewtopic.php?pid=601548#p601548

это относится вообще к любым новым тегам, какие мы добавляем. ( т.е. можно расширить amenity для недостающих объектов.) интересно же преимущество именно ключа education, из-за которого все проблемы.

“Хорошая организация” и “Большая адекватность” - принимается. хотя тоже вещи спорные.

При эксплуатации полигонов ТБО рано или поздно приходит осознание, что пора начинать утилизацию и рациональное использование ресурсов, а не нагромождение куч мусора в одном месте.
Процесс тем легче и безболезненнее, чем раньше придёт осознание.
Но можно законсервировать одну кучу и приняться за громождение следующей, согласен — чем не вариант.

Хм, а почему education 2.0 вообще должен быть каким-то особенным по отношению к любым толково придуманным новым тегам? Это просто приличная новая схема, которая именно схема, а не конструкция “понятие - тег”, то есть позволяет описывать не только ограниченную группу реальных объектов, для которых придумана, а путем комбинирования тегов, описывать что угодно (практически, как Healthcare 2.0).
Выделение всех объектов и свойств класса в отдельный namespace, естественно, удобнее с точки зрения архитектуры данных. Ровно по той же причине, почему, например, при написании программного кода функции получают префиксы имен, то де делают с классами для CSS для оформления HTML-страниц и так далее.

Среди не очень коструктивных голосов против “да ладно вам у нас GIS”, “сделайте без ошибок, а потом принимайте”, “не вводите противоречиывые теги”, “мне такая детализация не нужна” нашёл вот что:

Polarbear:

amenity=kindergarten, amenity=school уже были введены. Никто их не запрещает, с домысламы о замене тегов от Fkv и ряда других лиц не согласен.

Заменять amenity=school на education=school никто не будет. Пусть хоть тысячу лет висит и всех рисовальщиков в OSM указывает.

Очевидно, что большиство отметившихся не понимаю уточняющие свойства (тот же min_age, religion, education_for:males/education_for:female), а только ведут разговор о похожих буквах в amenity=school и education=school.

Что все взъелись на схему уточнений как замену священных коров amenity=kindergarten, amenity=school “с миллионами объектов” - не понятно.

Frederik сказал что смешиваем в кучу под education, нужно было с маленьких пропозалов начать, но это только усложнит тегирование:

  1. образовательная инфраструктура (площадка у автошколы, тренировочная площадка пожарных и МЧС)
    На Викимапии им лепят спортивные площадки (вроде leisure=pitch)
    http://wikimapia.org/31919443/
    http://wikimapia.org/35001815/

fkv и Zverik будут лепить amenity=school или amenity=kindergarten или что там их программы способны поддерживать.

Или вообще не тегировать такие объекты, они опытны в детализации OSM!
Или запрещать другим обозначать такие объкты http://wiki.openstreetmap.org/wiki/Any_tags_you_like

  1. образовательные комитеты (государственные, меж-государственные)
  2. образовательные организации (главные офисы)
  3. образовательные филиалы и отделения (с корпусами и прочим)
  4. образовательные правила и ограничения (пол, возраст, религия и прочие)

Если разбить так (4-6 отдельных предложений), то без примеров не будет понятно как они соотносятся друг с другом.

Согласен с Frederik что предложение получилось “на все случаи жизни” и для простых объектов (школа в отдалённом селе) это перебор, но эта схема не расчитывалась “для простых случаев” или “маленьких” объектов, а для всех объектов участвующих в образовательных процессах и всех их аспектах.

Так в этом и преимущество схемы, что охватываются множественные случаи (от простых до более сложных). Но подано как недостаток (раз человек голосует против). Загадочный критерий отбора, однако.
А различные мелкие нюансы, вроде возрастных ограничений — не трудно нивелировать, но для кого-то проще отказаться сразу от всей схемы (ещё одна «загадка» для меня).