Education 2.0

EugenyN · 2016-07-24 22:59:49

keder wrote:

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

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

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

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

плюсы:

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

и минусы:

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

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

Last edited by EugenyN (2016-07-24 23:01:39)

LLlypuk82 · 2016-07-25 02:52:53

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

EugenyN · 2016-07-25 10:27:08

LLlypuk82 wrote:

Грамотная схема тегирования решает задачи хорошей организации информации (=>удобство внесения и применения) и её большей адекватности по отношению к обозначаемым объектам (=>широкий охват в конкретной области и большая детализация). Это необходимые и достаточные условия применения.

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

насчёт удобства запроса. когда я работал с 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". так что тут нет сложностей с "запросом" он и так удобен.

Last edited by EugenyN (2016-07-25 16:23:11)

LLlypuk82 · 2016-08-07 18:08:14

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

Last edited by LLlypuk82 (2016-08-07 18:24:41)

LLlypuk82 · 2016-08-07 18:23:35

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

Last edited by LLlypuk82 (2016-08-07 18:26:28)

BushmanK · 2016-08-07 22:34:33

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

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

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

Last edited by BushmanK (2016-08-07 22:35:39)

keder · 2016-08-08 10:08:18

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

EugenyN · 2016-08-08 14:42:22

LLlypuk82 wrote:

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

об этих двух плюсах я писал. http://forum.openstreetmap.org/viewtopi … 48#p601548

LLlypuk82 wrote:

Широкий охват — возможность обозначить то, что ранее вообще не обозначалось никак (или абы как), причём — именно в том namespace, которому объект наиболее соответствует.
Большая детализация — обозначение тех признаков, которые ранее никак не обозначались (или через пень-колоду).

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

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

LLlypuk82 · 2016-08-08 15:03:39

EugenyN wrote:

т.е. можно расширить amenity для недостающих объектов

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

Last edited by LLlypuk82 (2016-08-08 15:04:10)

BushmanK · 2016-08-08 16:09:42

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

d1g · 2016-08-26 10:52:17

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

Polarbear:

max_age=* and min_age=* are established and easier to parse than a specialised education_for:ages=6-12.

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 "с миллионами объектов" - не понятно.

proposal is trying to do too much at once. Introduce a simple education tag first and when that is firm on the ground, then you can add additional things like what age group is something for or do they have a medical dummy yes/no. Don't try to add tags for all eventualities at once - this isn't OSM style.

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

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

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

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

Last edited by d1g (2016-08-26 12:29:10)

LLlypuk82 · 2016-08-26 18:15:06

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

Announcement

#51 2016-07-24 22:59:49

Re: Education 2.0

#52 2016-07-25 02:52:53

Re: Education 2.0

#53 2016-07-25 10:27:08

Re: Education 2.0

#54 2016-08-07 18:08:14

Re: Education 2.0

#55 2016-08-07 18:23:35

Re: Education 2.0

#56 2016-08-07 22:34:33

Re: Education 2.0

#57 2016-08-08 10:08:18

Re: Education 2.0

#58 2016-08-08 14:42:22

Re: Education 2.0

#59 2016-08-08 15:03:39

Re: Education 2.0

#60 2016-08-08 16:09:42

Re: Education 2.0

#61 2016-08-26 10:52:17

Re: Education 2.0

#62 2016-08-26 18:15:06

Re: Education 2.0

Board footer