ШТОСМ: заметки с тегом пропозалы

Any keys you like

Илья Зверев — Mon, 02 Feb 2015 17:12:56 +0400

Новичкам с первого дня объясняют: придумывайте любые теги, у нас свободная модель. Рисуйте — но лучше справляйтесь по Map Features, а новые теги обязательно задокументируйте. Вы можете обозначить дорогу как «дорога=главная», но чтобы её показывали на картах, придётся изучить значения «highway». Поэтому сначала ищите по вики и форуму, если не нашли — откройте словарь, придумайте варианты, как назвать новый тег, проверьте их по taginfo. Новые теги могут быть любыми, и их не обязательно согласовывать заранее.

Документирование важных тегов начинается с пропозала. Когда-то пропозалы делались для совместного обсуждения моделей тегирования: названий, дополнительных тегов, документации. Человек отметил несколько объектов — пусть это будут люки, к примеру, — изучил их свойства, составил список используемых тегов и подтегов, и хочет узнать мнения у специалистов по люкам и тех, кто мапил люки раньше. Результатами будут вики-страница и осведомлённость авторов картостилей и валидаторов о связанных тегах.

То ли участники стали менее уверенными, то ли викиманьяки всех застращали, но в последние месяцы рассылка tagging@ необычно выросла: одновременно обсуждаются десятки пропозалов. В прошлой радиопередаче мы два часа перечисляли только темы за январь. Оказывается, в головах мапперов всё поменялось: вместо «сделал — задокументировал» порядок обратный: «захотел обозначить — написал пропозал — пришёл в tagging@ — со всеми переругался — пропихнул пропозал через голосование — снова переругался — поставил тег на точку». Яркий пример — man_made=water_tap, автор которого ярко показал недостатки пропозалов, спровоцировал две длинные философские темы, и сколько объектов обозначено спустя две недели его тегом? Пять. Из них две — автором.

Но то новые теги, а если старые не нравятся? 3,5 года назад мы приняли эпохальный пропозал: entrance=*. Он включал в себя не только классификацию входов, но и требование автоматического перетегирования всех 150 тысяч точек с building=entrance. Противники долго удерживали волну, но сейчас последних около 63 тысяч (два дня назад было 67 — процесс ещё идёт). Тот пропозал отверз хляби разума: оказалось, можно менять устоявшиеся схемы с сотнями тысяч использований. Немногие прошли, но примеров достаточно: электроподстанции, трубопроводы, emergency=*, public_transport:version...

Иногда заменить пару тегов недостаточно. Никита «d1g», проведя полгода за наведением порядка в вики, понял: сама модель «ключ=значение» ущербна. В частности, потому что не позволяет использовать несколько значений одного ключа («;» не в счёт, её никто не поддерживает). Заменой он определил формат «ключ:значение=yes». Плюсы такого подхода расписаны на странице пропозала, минусы предъявили другие участники в рассылке tagging@ и русском форуме. Услышав претензии, Никита понял: без изменения API тут не обойтись, потому что наши проблемы решат только иерархические теги с массивами внутри.

OpenStreetMap только в начале своего развития. Почти все элементы его модели плохи, и каждый рано или поздно хочет тип данных для области, более логичную иерархию тегов, JSON API, лучшую документацию, модераторов и орган, куда жаловаться. Но вы знаете: «хочешь — сделай». Следующая версия API назревает, и самое время расчехлить компилятор C++ и написать желаемые функции. Ограничений нет — только ваше рабочее время и обратная совместимость с базой и нынешним API. В этом году мы увидим немало перемен, на которые будем бурчать: «раньше было лучше», — и наша задача в том, чтобы настоящее стало этим «раньше» как можно раньше. Никита, дерзай!

Узлы безумия

Илья Зверев — Wed, 09 Jul 2014 23:44:44 +0400

Сегодня Мартин Коппенхёфер опубликовал пропозал моей мечты под названием «Node relations». В нём он предлагает в ситуации, когда, например, на одном столбе несколько разных знаков, не накладывать точки одна на другую, и не пользоваться мерзким «;», а создавать «виртуальные узлы» с помощью отношений. В отношении type=node может быть только один член — точка — и какие угодно теги.

Это ещё один шаг к разделению геометрии и её свойств. Когда-то давно я предлагал радикальное изменение модели OpenStreetMap: запретить теги на точках и линиях, все сущности обозначать отношениями. Если вдобавок освободить отношения от геометрического смысла (т. е. вместо мультиполигонов сделать тип area), это устранит все двусмысленности в данных, позволит сохранять идентификаторы при перерисовке геометрии, позволит объединять, например, линии в сущность «улица», и заставит, наконец, программистов сделать нормальное редактирование отношений.

Жаль, слишком радикально для сообщества, но даже ничтожный шаг в правильную сторону — уже хорошо.

До 19 июля идёт голосование за обозначение портов и перегрузочных терминалов. Голосуют пока какие-то незнакомые люди. Рассылку tagging@ читают всё меньше нормальных людей, проще изучить C++ и уйти в программирование, чем спорить с тегоманьяками. Недавно, вон, кто-то предложил способ обозначения дверей, так его оборвали на полуслове: был уже такой, отклонили восемью неизвестными. Автор в сердцах написал за ночь 30 килобайт второй версии пропозала, и с лёгким сердцем выкинул его из головы.

За мосты и электричество

Илья Зверев — Thu, 26 Sep 2013 17:19:57 +0400

До 6 октября можно отдать голос за два многолетних пропозала. Первый — про подстанции: power=station и power=sub_station объединяются в новый power=substation, для которого можно указать тип, местоположение и вольтаж. Из обсуждения пропозала вы узнаете, что GIS — это подстанции с элегазовой изоляцией. На сегодня тегов substation всего 79, часть из которых мои, а обоих «устаревающих» вместе — почти 140 тысяч.

Объектов со значениями тега bridge=*, отличными от yes, которые вводит пропозал про типы мостов, почти 40 тысяч. Фотографии для каждого значения делают выбор элементарным, и глядя на пропозал, удивляешься, почему его принимают только сейчас. Даже в Петербурге, известном своими мостами, последние тегированы просто как bridge=yes — а будут bridge=movable, bridge:movable=bascule, bridge:structure=*.

Есть ещё третье голосование, кардинально отличающееся от этих двух: за ~~landuse=plot~~ allotments=plot. Человек зарегистрировался 17 сентября, в тот же день набросал пропозал и написал о нём в tagging@, через три дня запустил голосование, которое планирует закрыть до конца месяца. Он также добавил упоминание нового тега на страницу landuse=allotments, что заметил Dinamik, сразу дополнивший список многострадальным boundary=lot, которых, оказывается, в базе почти полторы тысячи, и ещё 685 — необъяснимых lot=*.

За дороги и электричество

Илья Зверев — Wed, 29 May 2013 14:24:36 +0400

Позавчера открыли голосование за пропозал, вводящий новый тег power=plant для обозначения электростанций, и слегка корректирующий требования к тегированию power=generator. В частности, добавляется тег generator:type для более детальной классификации генераторов энергии. Страница весит 50 килобайт (и ещё 35 — обсуждение), но большую её часть занимают примеры и классификация. Отдать голос можно до 10 июня.

Спорные предложения переименования sub_station в substation, уточнения схемы тегирования подстанций и их компонентов и перевода тега power=station в устаревшие вынесены в отдельный пропозал (с сорокадвухкилобайтным обсуждением). Я был неправ в февральской заметке: трансформаторные подстанции останутся substation с дополнительным тегом substation=distribution. Пропозал хорошо проработан и щедро иллюстрирован, этап RFC начался неделю назад.

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

Для обозначения приоритета главной дороги, кстати, можно применять тег priority_road со значениями designated или yes_unposted (зависит от наличия перекрёстков со второстепенными дорогами после знака). В России, как ни удивительно, этот тег используется ноль раз.

Викиданные в тегах

Илья Зверев — Sat, 30 Mar 2013 17:44:58 +0400

В октябре открыли проект Wikidata: централизованное структурированное хранилище данных и метаданных всех объектов (другими словами, базу знаний) под лицензией CC0. С 6 марта на него перевели систему интервики (как следствие, последней строчкой в списке языков висит ссылка на wikidata), а во второй и третьей фазах планируется автоматически обновлять из Викиданных инфобоксы и списки.

Количество объектов в хранилище приближается к десяти миллионам; каждый, в отличие от страниц википедии, имеет уникальный идентификатор вида «Q12345», не зависящий от языка и других объектов. Janko Mihelić месяц назад предложил использовать ссылку на викиданные в формате wikidata=Q234 паралелльно тегам wikipedia, а заодно по возможности снабжать такой ссылкой каждое значение-объект: например, architect:wikidata=*.

Другие осмеры сразу заметили, что новый тег а) неочевиден пользователям; б) дублирует тег wikipedia; в) ничем не поддерживается; г) может содержать несколько значений (поскольку объекты OSM могут обозначать несколько сущностей: например, теги магазина на контуре здания). Реакции разнятся — от «дурацкий тег, давайте его забудем» до «массово заменим wikipedia на wikidata!» Жаркие споры, вызванные этим пропозалом в рассылке и вики, проявляют не столько спорность предложения, сколько проблемы самого механизма пропозалов. Simone Saviolo подытожил:

Я слегка озадачен: долгие годы мы говорили, что OSM должен хранить только геоданные, а остальной информации место в отдельной базе данных. И теперь, когда появилась такая отдельная база, у неё оказалось столько противников.

ЛЭП

Илья Зверев — Tue, 12 Feb 2013 00:55:16 +0400

После длительного спора о замене power=cable на power=line + location=underground Франсуа Лакомб решил восстановить два старых пропозала: про производство и передачу электроэнергии. На нашем форуме совершенно независимо ожила релевантная тема.

В первом пропозале, за который уже голосовали, но всего восемь человек (недостаточно для принятия), предлагается отменить слишком размытый тег power=station (заменив его на power=plant или подстанцию) и переименовать sub_station (станция субмарин) в substation (подстанция). Трансформаторные подстанции нужно будет отмечать как power=transformer — то есть, все уже обозначенные в ваших городах ТП придётся переделать (а может и нет — см. комментарии). Текст предложения уже достаточно подробен, голосование планируется открыть через месяц.

Как сообщает shafr, по новому закону об энергетике на сайтах региональных компаний должны быть опубликованы списки станций и подстанций с координатами. Список ссылок на эти карты участники ведут в вики. Получается хорошее подспорье не только для расстановки напряжений, но и для валидирования отмеченных станций.

Пропозал про линии электропередач пока весьма сыр, но суть уже ясна: все линии обозначаются как power=line, расположение записывается в location, а напряжение — в voltage, при этом необязательно считать изоляторы для получения точного значения, а можно использовать слова low / medium / high. Границы ещё обсуждаются, пока предлагают 1 и 50 киловольт. Уход от power=cable некоторые воспринимают болезненно, исписывая десятки килобайт не только в рассылке, но и в обсуждении пропозала.

Также непонятно, что делать, когда через опору проходят несколько линий. Общее мнение — что придётся использовать отношения, только какие именно? Лагеря два: за type=route с route=power и за другие type: встречаются power и power_circuit. Противники первой схемы утверждают, что type=route подразумевает, что по линиям такого отношения можно проехать, а то и пустить общественный транспорт — троллейбусы, например.

Вопросов пока не вызывает только деление опор на power=tower и power=pole: первым тегом обозначаются большие, нередко металлические ажурные конструкции для линий среднего и большого напряжения, а вторым — простые столбы, обычно деревянные или бетонные. Впрочем, стоит собрать галерею — и классификация местами оказывается затруднительной.

Для понимания всех упомянутых страниц, споров, схем и матчасти рекомендую статью Алексея Толмачёва: чередуя короткие абзацы и фотографии, он доходчиво объясняет, на что смотреть, оказавшись рядом с подстанцией или опорой линии электропередач.

Глобально устаревшая схема тегирования

Илья Зверев — Thu, 13 Dec 2012 11:52:51 +0400

Недавно ErshKUS и Komяpa вновь подняли в чатике вопрос автоматической замены building=entrance на entrance=yes: после прошлогоднего голосования за новый вариант обозначения сотни тысяч «старых» тегов мозолят некоторым участникам сообщества глаза. И тут же обнаружилось, что pschonmann без спроса взял и загрузил огромные ченджсеты, где не только исправил спорный тег, но и другие, которые валидатор KeepRight пометил как устаревшие. Разумеется, DWG всё это откатила на следующий день.

Это повлекло очередную волну споров в чатике и вылилось в тему на форуме, где Hind поставил сообщество перед выбором: покрываться плесенью, не форсируя замену тегов, или запускать массовые правки, как только будет принят очередной пропозал с обновлением схемы тегирования.

Разумеется, околотехнические гики, из которых OSM состоит чуть менее чем полностью, сразу выбрали второй вариант: как же так, база данных не соответствует схеме! И бросились обсуждать технические мелочи: величину переходного периода, последовательность действий, зоны ответственности. Чтобы не вовлекать страшный DWG, сразу отметили, что такие замены лучше делать в пределах одной страны. Проблема же в том, что изначальная постановка вопроса некорректна. И более того, она базируется на двух неверных предпосылках: 1) механизм пропозалов имеет смысл; 2) вики определяет используемые теги.

Модель тегирования в OpenStreetMap зиждется на принципе «Any tags you like»: у нас свободная база и никто не может указать, какой тег использовать. Другой вопрос, что если ваш тег никто не понимает, то он бесполезен. Поэтому все используемые теги очень желательно документировать в вики. Многие так и поступают: в нашей вики можно найти множество страниц, посвящённых очень редким тегам. Ссылки на такие страницы объединяются в каталоги по типам, а каталоги фильтруются и объединяются в колоссальные страницы «Map Features» и «How To Map A». Благодаря этой документации вам не нужно придумывать и продвигать тег каждый раз, когда вы встречаете что-то новое: большинство объектов уже имеют обозначения, и найти их не очень сложно.

Вместо создания вики-страницы втихаря, можно организовать пропозал: предложить модель тегирования, обсудить её с другими мапперами и проголосовать за её использование. Тем самым схема оттачивается, а голоса, отданные в её пользу, добавляют ей веса: после принятия сложно будет оспаривать место нового тега в общеупотребимых таблицах. Особенно это полезно, когда разные участники предлагают разные схемы тегирования одного и того же: победивший пропозал определит теги, используемые тысячами мапперов. И поскольку тегов уже очень много, не удивительно, что некоторые пропозалы, расширяя схему тегирования, делают некоторые теги ненужными.

Постоянное упоминание пропозалов привело к тому, что мапперы выдвигают их до того, как что-то закартировать с использованием предлагаемых тегов. Затем тратят месяц на споры, полировку схемы и обслуживание голосования. И потом не понимают, что делать, если схема оказалась отвергнута. Или хуже — принята. Объём бюрократии чудовищен, и всё ради включения в обсуждение лишних 20 человек. Разумеется, в их числе не будет пользователей новой модели тегирования, не будет мапперов, нуждающихся в этом теге, и не будет специалистов по обсуждаемой предметной области. В итоге многие современные теги остаются без описания в вики, потому что новички боятся создавать страницы тегов, минуя пропозалы, а главным информационным сайтом стал TagInfo.

Другими словами, вики создавалась, чтобы описывать используемые теги. Со временем часть мапперов решила, что вики первична: как тaм написано, только так и можно мапить. Поэтому они начали смотреть на пропозалы как на директивы, создавая их, когда тег почти не представлен в базе и чувствуя, что как только схему примут, все станут на неё смотреть и использовать, и уже ничего не изменишь. Отсюда родились вики-бюрократы, следящие, чтобы каждый принятый пропозал был идеален. Жёсткость схемы привела к тому, что пропозалы стали создаваться не только для введения новых тегов, но и для изменения существующих схем. При этом, как видно, основания у этого нет: кажущаяся директивность, со всеми устареваниями тегов и требованиями мапить правильно, основывается на неверной предпосылке первичности вики. В реальности хорошо если одна десятая мапперов вообще в курсе, что по решению десятка человек может поменяться тег, использованный сотни тысяч раз. Поэтому поставленный Hind вопрос нужно рассматривать не в контексте «заменить устаревшую схему на новую», а как «у нас есть один распространённый тег, давайте заменим его на другой».

Теперь посмотрим, что на что предлагается заменить. В модели тегирования OSM есть каскадные теги (они тоже нравятся не всем, но практика устоялась). Например, highway=crossing + crossing=uncontrolled или natural=water + water=pond. Второй тег уточняет первый, но без него смысл тоже понятен. А что если мы введём crossing=yes и water=yes? Внезапно, первый тег стал не нужен! Уточняющие теги почти всегда уточняют один фиксированный тег. Избыточность в нашей базе, неужели у вас не чешутся руки её поправить? Давайте сделаем water=yes и устраним natural=water! То есть, давайте, раз случайно приняли entrance=yes, устраним building=entrance. Аргументация «за» и «против» для обоих предложений не может отличаться, и в контексте становится более понятной. Например, давайте перевернём в соответствии с известностью тегов: если на входе есть building=entrance, зачем ставить дополнительно entrance=yes? Устранение building=entrance совершенно немотивировано («но так же лучше» — это не мотив, всё работало и до пропозала) и касается тега, используемого более половины жизни проекта.

Получается, вопрос касается только массовой правки с указанными параметрами, но при этом с подразумеваемым упрощением принятия решений по последующим подобным правкам (как crossing=yes). Без опоры на «устаревший тег» и «актуальную схему». Сообщество совершило ошибку, приняв тег, эквивалентный уже используемому, и решение может быть только одно: во всех программах теперь нужно поддерживать оба. Глупо ожидать, что после правки building=entrance перестанут использовать: продолжат — вики же не директивна, — и пользователям не резон удалять строчку из программы для этого тега.

Моё отношение к массовым правкам, будь то импорты или ковровые замены тегов, известно: лучше не надо. На мой взгляд, они лишают базу «жизни», закрепляют её состояние и дают пользователям ложное ощущение стабильности. Участникам OpenStreetMap, программистам, значительно проще написать робота, нежели аргументировать его использование. Так, предлагаемая массовая правка предсказуемо не следует правилам OSMF для массовых правок, на которые ссылается страница «устаревших тегов». Вместо этого инициаторы «по-русски» хотят договориться с, судя по форуму, новичками и быстренько провернуть замену. Предложения написать в DWG или, как минимум, оповестить tagging@ сталкиваются с непониманием и страхом: вдруг откажут? По-моему, это — первый признак того, что вопрос перехода на новую схему вообще не стоит (а не «я выбираю первый вариант»), и что проблема «неактуальной тягомотины» надумана и раздута, не столько ради этой конкретной замены, сколько для оправдания будущих масштабных актов наведения порядка в базе.

Десятки миллиардов отношений

Илья Зверев — Wed, 14 Nov 2012 20:54:58 +0400

Dr&mx навёл на великолепный пропозал отношения, которое широко используется в Польше: type=person. Оно связывает места рождения и смерти человека, а также место захоронения и памятники. И разумеется, отношения могут быть связаны друг с другом по родству (с закольцовыванием parent-child). Сделан этот пропозал специально для использования на кладбищах, к нему прилагается пресет и плагин для JOSM.

Могилы же отмечаются как tomb=* (тоже ссылка на польскую страницу: в английском переводе ограничились общим описанием). Интересно, что их количество в базе не сильно превышает количество отношений person. Возможно, американцы и итальянцы, также детализировавшие несколько кладбищ, удержались от создания отношения на каждого человека.

Пропозал childcare не прошёл, потому что вы все мужчины и не понимаете

Илья Зверев — Sun, 14 Oct 2012 11:12:47 +0400

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

Граф на графе

Илья Зверев — Tue, 10 Apr 2012 18:36:09 +0400

Немцы сочинили очередной грандиозный пропозал, но на этот раз — с практическим смыслом. Для обозначения рёбер TMC (пробочного радиосервиса со стандартизованным протоколом) раньше использовались жуткие теги, которые предлагается заменить одним, с читаемым значением вида tmc=DE:12345+58934. Текст пропозала пока написан только на немецком языке, но иллюстраций и примеров столько, что понятно и так. Tobias Knerr доходчиво объяснил преимущества новой схемы, а спустя неделю Eckhart Wörner перечислил её недостатки в практических применениях.

В России по данным википедии услуги RDS-TMC предоставляет Навиком, но они поддерживаются только некоторыми моделями Garmin, найти номера рёбер для улиц в сети невозможно, а ограничения протокола делают сервис в больших городах почти бесполезным: посмотрите, например, на эти карты. В обсуждениях пробок на карте OSM чаще всплывает название OpenLR — но о поддержке этого сервиса даже в Европе ничего не известно.

Полосатые пропозалы

Илья Зверев — Tue, 14 Feb 2012 16:47:29 +0400

На останках закиданного камнями пропозала Turn Lanes выросли аж два новых, примерно на ту же тему.

Lane group развивает идею брошенного мной lanes:directions. В первом приближении выглядит мило: lane_group=l,s,s,r. Второй раздел, внезапно, вводит дикую систему тегирования, которая позволяет значения вроде lane_group=-cycle_lane:n,-tram:n#,#tram:s,rr. Третья часть касается расстановки свойств отдельным полосам: lane_group:maxspeed=,,70,70

Именно свойства полос заинтересовали австрийца, сотворившего пропозал Lanes General Extension. Он начал с простого и очевидного способа: maxspeed:lanes=80|50|50 (точки с запятой не подходят по понятным причинам, запятые заменили палками после напоминания про opening_hours). Введя суффикс :lanes, автор говорит: «это самая суть пропозала, и за неё будем голосовать. Всё остальное опционально».

Между тем, именно в опциях схема начинает покрываться эээ мраком. Вот почему они не могут вовремя остановиться? Суффикс :bothways для полос в обе стороны (то есть, для ключей на обе полосы... наверное), ключ reversible:bothways (бывают другие?), ключ turn, заменяющий весь мой пропозал (пример: turn:lanes=left|left|through|through;right|through;right), на первый взгляд очевидный ключ cycleway:lanes, который резко теряет смысл, если вспомнить, что сообщество решило учитывать в теге lanes только полосы для автотранспорта, и под конец — отношение связи полос, которое почти, но не совсем, не похоже на отношение запрета поворотов.

Оба пропозала обсуждаются уже вторую неделю, и вместе со страницами обсуждений весят 26 и 66 килобайт соответственно. Готовьтесь к голосованию!

<member type=’relation’ ref=’1370727’ role=’level_-1’ />

Илья Зверев — Mon, 23 Jan 2012 17:47:05 +0400

Недавно в блоге OpenGeoData развёрнуто описывали очередное предложение по рисованию внутренностей зданий. Студент гейдельбергского университета без особого представления о схемах тегирования OSM, изучения других пропозалов и, видимо, программистского опыта сотворил способ рисования комнат и роутинговых рёбер внутри зданий. Первые делаются вложенными отношениями, вторые — через указание id точек. Осторожно, берегите глаза.

Вообще, интересная перспектива для студентов: нынче можно в качестве диссертации выдумывать схемы тегирования, оставляя их потом пылиться на задворках вики. Кто-нибудь в России уже пользовался OSM в научных целях?

Взял и располосовал

Илья Зверев — Sat, 14 Jan 2012 20:56:39 +0400

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

Уровень пофига я даже не предполагал: в Австрии, тем временем, Martin Vonwald решил, что исследование существующих схем не для него, и придумал новую с потолка. Затем вместо создания вики-страниц отослал её двум сотрудникам Skobbler (компания, делающая навигационную программу на основе наших данных, авторы MapDust и спонсоры плагина turnrestrictions), и завтра в 19 часов по австрийскому времени они будут обсуждать схему тегирования полос через Skype.

I hereby proclaim this neighbourhood Trumandale of the Burbank Quarter

Илья Зверев — Sun, 08 Jan 2012 23:21:54 +0400

Между прочим, прямо сейчас весьма успешно идёт голосование по двум новым значениям тега place:

neighbourhood: небольшой район, квартал или подобная часть населённого пункта — недостаточно значительная, чтобы использовать place=suburb. Можно использовать в качестве suburb для деревень.
quarter: район больше neighbourhood, но меньше suburb.

Это новое деление давно обсуждалось, но актуально, в основном, для азиатских и англоговорящих стран.

Где бы притулиться

Илья Зверев — Wed, 04 Jan 2012 17:38:02 +0400

Kay Drangmeister уже давно поддерживает карту стоянок, и позавчера обновил её стиль. Эта карта сделана в поддержку пропозала по тегированию мест на улицах, где можно оставить машину, — до сих пор не принятого, но уже широко используемого в Германии и Финляндии, например. В наших городах на карте всё серо, что странно: знаков «остановка запрещена» у нас хоть отбавляй.

Дурной хребет

Илья Зверев — Mon, 07 Nov 2011 09:33:04 +0400

Хребты у нас нарисованы безобразно: линии, состоящие из place=locality с однобуквенными названиями. Конечно, можно было бы написать пропозал и не забыть о нём на следующий день, со временем подтолкнув редакторов основного стиля. Но русскому сообществу приятнее общаться на форуме, не стремясь к закрытию вопросов. В теме обсуждается терминология, в вики lzhl плодит ещё более непонятные пропозалы (раз, два, три: «они, на мой взгляд, будут приняты практически единогласно»), и о проблеме по-прежнему знают не более десятка человек.

На картинке также видны некоторые пики из тысяч, добавленных в прошлом году участником stiker1 из неизвестного источника.

Многоэтажное отношение

Илья Зверев — Sat, 29 Oct 2011 22:46:16 +0400

Некоторое время назад очередной немец потряс читающих вики мапперов своим грандиозным пропозалом. На этот раз — про рисование этажей (или уровней на улице) и переходов между ними. Суть в использовании единственного отношения, включающего абсолютно все объекты. Разумеется, эта задача невыполнима без особо витьеватых тегов, которых в тексте предложения избыток: levels=B=Basement@-4;G=Ground floor@0;1@5;2@9;3=Roof garden@13 — обычное описание этажей, role:FrontStairsPlateau=1@3;repeat=all@4 — описание параметрических ролей. Сюда можно добавить остроумную попытку моделирования вертикальных линий через точки, например, vway:highway=footway (что бы это ни было). И нельзя пропустить грандиозный финал — трёхмерные мультиполигоны!

Объём предложения уже превысил 65 килобайт, если считать учебник и попытки объяснить смысл затеи в обсуждении. Автор очень увлечён, и есть шанс, что рано или поздно начнётся голосование. Как альтернатива, мне больше нравится более простое (и заброшенное) предложение обозначать каждый этаж отдельным отношением, а Tordanik вообще предлагает ограничиться тегом level. И конечно, в вики уже почти два года поддерживается сводный список способов рисования многоэтажных карт.

Рано или поздно, каждый подвержен

Илья Зверев — Thu, 13 Oct 2011 09:49:28 +0400

История о том, как один давний и уважаемый участник решает, будто база России — его playground, и начинает наводить свой порядок: http://forum.openstreetmap.org/viewtopic.php?id=14007

Что хорошего пока получается из спора? Пропозал по тегированию входов через entrance=* вот-вот будет принят, а в tagging@ обсуждаются возможность и механизмы санкционирования массовой замены устаревших тегов. Да, и из некоторых регионов пропали, наконец, теги cladr:*, избавляя новичков от тяжёлой работы ввода их вручную.

Turn Lanes

Илья Зверев — Thu, 06 Oct 2011 11:50:21 +0400

Сегодня пропозал по полосам съезда/разгона перешёл в стадию обсуждения. Если коротко, предлагается:

указывать количество дополнительных полос (которые обязательно учитываются в lanes=*) тегами lanes:* (например, lanes:turnright:forward=1 означает, что в направлении «по линии» правая полоса служит для поворота направо);
~~при необходимости раскрывать назначение каждой полосы тегом lanes:directions (пример значения — l,s,sr);~~
при необходимости указывать расположение группы полос тегом lanes:X:location (пример — lanes:merge:location=left);
на сложных развязках может пригодиться отношение type=lane_restriction, которое копирует обычное отношение restriction, но с добавленным тегом lane для указания полосы.

Страница предложения велика, но только из-за огромного количества примеров. Если интересно, написанию предшествовало изучение вопроса: обсуждений, предыдущих пропозалов, аэрофотоснимков дорог разных стран. На русском языке вопросы можно задавать в форумной теме.

Полосы

Илья Зверев — Tue, 20 Sep 2011 22:14:15 +0400

На выходных в tagging@ развернулся нешуточный спор про тег lanes: стоит ли им отмечать разгонные/поворотные полосы, или только основные? И считать ли полосы для велосипедов и общественного транспорта? Пока дискуссия склоняется к подсчёту всех полос, кроме велосипедных, а конкретизировать тегами вроде lanes:turning:left. С другой стороны, куда проще считать только полосы для потока, а для остального использовать дополнительные теги или отношения, например:

Украинский пропозал по обозначению знаков движения по полосам — хороший, самоочевидный, но недоработанный.
Направления в зависимости от полосы — рассматривает только полосы съездов с магистралей.
Пропозал отношения, для продвижения которого автор даже сделал плагин к JOSM. Правда, там нужно считать длину полос в метрах, так что пользователям других редакторов не повезло.
Ещё один пропозал с отношениями, на этот раз по отношению на каждую полосу плюс группирующее отношение. Правда, непонятно, что там с направлениями и поворотами.
Наконец, можно (но очень осторожно) банально рисовать каждую полосу отдельной линией highway=lane.

Меня больше занимал такой вопрос: считать ли трамвайные рельсы за отдельные полосы?

На белорусском форуме сейчас как раз обсуждается вопрос рисования полос движения для прогорода (позже: и на русском). Они там находят одни пропозалы («плагин сгенерировал 17 отношений») и переизобретают другие («laneinfo:end=ls;s;s;r;»). Советую принять участие, пока в соответствии с принципами do-ocracy не насадили кустарных схем.