{ "version": "https:\/\/jsonfeed.org\/version\/1", "title": "ШТОСМ: заметки с тегом пропозалы", "_rss_description": "ШТОСМ", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/shtosm.ru\/tags\/proposals\/", "feed_url": "https:\/\/shtosm.ru\/tags\/proposals\/json\/", "icon": false, "author": { "name": "Илья Зверев", "url": "https:\/\/shtosm.ru\/", "avatar": false }, "items": [ { "id": "1298", "url": "https:\/\/shtosm.ru\/all\/any-keys-you-like\/", "title": "Any keys you like", "content_html": "

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

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

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

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

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

OpenStreetMap только в начале своего развития. Почти все элементы его модели плохи, и каждый рано или поздно хочет тип данных для области, более логичную иерархию тегов, JSON API, лучшую документацию, модераторов и орган, куда жаловаться. Но вы знаете: «хочешь — сделай». Следующая версия API назревает, и самое время расчехлить компилятор C++ и написать<\/a> желаемые функции. Ограничений нет — только ваше рабочее время и обратная совместимость с базой и нынешним API. В этом году мы увидим немало перемен, на которые будем бурчать: «раньше было лучше», — и наша задача в том, чтобы настоящее стало этим «раньше» как можно раньше. Никита, дерзай!<\/p>\n", "date_published": "2015-02-02T17:12:56+04:00", "date_modified": "2015-02-02T17:12:06+04:00", "_date_published_rfc2822": "Mon, 02 Feb 2015 17:12:56 +0400", "_rss_guid_is_permalink": "true", "_rss_guid": "https:\/\/shtosm.ru\/all\/any-keys-you-like\/", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "1248", "url": "https:\/\/shtosm.ru\/all\/uzly-bezumiya\/", "title": "Узлы безумия", "content_html": "

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

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

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

До 19 июля идёт голосование за обозначение портов<\/a> и перегрузочных терминалов<\/a>. Голосуют пока какие-то незнакомые люди. Рассылку tagging@ читают всё меньше нормальных людей, проще изучить C++ и уйти в программирование, чем спорить с тегоманьяками. Недавно, вон, кто-то предложил способ обозначения дверей, так его оборвали на полуслове: был уже такой<\/a>, отклонили восемью неизвестными. Автор в сердцах написал за ночь 30 килобайт второй версии пропозала, и с лёгким сердцем выкинул его из головы.<\/p>\n", "date_published": "2014-07-09T23:44:44+04:00", "date_modified": "2014-07-09T23:44:21+04:00", "_date_published_rfc2822": "Wed, 09 Jul 2014 23:44:44 +0400", "_rss_guid_is_permalink": "true", "_rss_guid": "https:\/\/shtosm.ru\/all\/uzly-bezumiya\/", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "1163", "url": "https:\/\/shtosm.ru\/all\/za-mosty-i-elektrichestvo\/", "title": "За мосты и электричество", "content_html": "

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

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

Есть ещё третье голосование, кардинально отличающееся от этих двух: за landuse=plot<\/s> allotments=plot<\/a><\/i>. Человек зарегистрировался 17 сентября, в тот же день набросал пропозал и написал о нём в tagging@, через три дня запустил голосование, которое планирует закрыть до конца месяца. Он также добавил упоминание нового тега на страницу landuse=allotments<\/a><\/i>, что заметил Dinamik, сразу дополнивший список многострадальным boundary=lot<\/i>, которых, оказывается, в базе почти полторы тысячи, и ещё 685 — необъяснимых lot=*<\/i>.<\/p>\n", "date_published": "2013-09-26T17:19:57+04:00", "date_modified": "2013-09-26T17:19:22+04:00", "_date_published_rfc2822": "Thu, 26 Sep 2013 17:19:57 +0400", "_rss_guid_is_permalink": "true", "_rss_guid": "https:\/\/shtosm.ru\/all\/za-mosty-i-elektrichestvo\/", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "1111", "url": "https:\/\/shtosm.ru\/all\/energogolosovanie\/", "title": "За дороги и электричество", "content_html": "

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

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

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

Для обозначения приоритета главной дороги, кстати, можно применять тег priority_road<\/a> со значениями designated<\/i> или yes_unposted<\/i> (зависит от наличия перекрёстков со второстепенными дорогами после знака). В России, как ни удивительно, этот тег используется ноль раз.<\/p>\n", "date_published": "2013-05-29T14:24:36+04:00", "date_modified": "2013-05-29T14:24:16+04:00", "_date_published_rfc2822": "Wed, 29 May 2013 14:24:36 +0400", "_rss_guid_is_permalink": "true", "_rss_guid": "https:\/\/shtosm.ru\/all\/energogolosovanie\/", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "1065", "url": "https:\/\/shtosm.ru\/all\/wikidata\/", "title": "Викиданные в тегах", "content_html": "

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

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

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

\n

Я слегка озадачен: долгие годы мы говорили, что OSM должен хранить только геоданные, а остальной информации место в отдельной базе данных. И теперь, когда появилась такая отдельная база, у неё оказалось столько противников.<\/p>\n<\/blockquote>\n", "date_published": "2013-03-30T17:44:58+04:00", "date_modified": "2013-03-30T19:23:12+04:00", "_date_published_rfc2822": "Sat, 30 Mar 2013 17:44:58 +0400", "_rss_guid_is_permalink": "true", "_rss_guid": "https:\/\/shtosm.ru\/all\/wikidata\/", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "1026", "url": "https:\/\/shtosm.ru\/2013\/02\/12\/1\/", "title": "ЛЭП", "content_html": "

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

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

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

\"\"

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

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

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

Для понимания всех упомянутых страниц, споров, схем и матчасти рекомендую статью<\/a> Алексея Толмачёва: чередуя короткие абзацы и фотографии, он доходчиво объясняет, на что смотреть, оказавшись рядом с подстанцией или опорой линии электропередач.<\/div>", "date_published": "2013-02-12T00:55:16+04:00", "date_modified": "2013-02-12T09:36:56+04:00", "_date_published_rfc2822": "Tue, 12 Feb 2013 00:55:16 +0400", "_rss_guid_is_permalink": "true", "_rss_guid": "https:\/\/shtosm.ru\/2013\/02\/12\/1\/", "_e2_data": { "is_favourite": false, "links_required": null, "og_images": [] } }, { "id": "974", "url": "https:\/\/shtosm.ru\/2012\/12\/13\/1\/", "title": "Глобально устаревшая схема тегирования", "content_html": "
Недавно ErshKUS и Komяpa вновь подняли в чатике вопрос автоматической замены building=entrance на entrance=yes: после прошлогоднего голосования<\/a> за новый вариант обозначения сотни тысяч «старых» тегов мозолят некоторым участникам сообщества глаза. И тут же обнаружилось, что pschonmann без спроса взял и загрузил огромные ченджсеты<\/a>, где не только исправил спорный тег, но и другие, которые валидатор KeepRight пометил как устаревшие. Разумеется, DWG всё это откатила на следующий день.

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

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

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

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

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

Другими словами, вики создавалась, чтобы описывать используемые теги. Со временем часть мапперов решила, что вики первична: как т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 совершенно немотивировано («но так же лучше» — это не мотив, всё работало и до пропозала) и касается тега, используемого более половины жизни проекта.

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

Моё отношение к массовым правкам, будь то импорты или ковровые замены тегов, известно: лучше не надо. На мой взгляд, они лишают базу «жизни», закрепляют её состояние и дают пользователям ложное ощущение стабильности. Участникам OpenStreetMap, программистам, значительно проще написать робота, нежели аргументировать его использование. Так, предлагаемая массовая правка предсказуемо не следует правилам OSMF<\/a> для массовых правок, на которые ссылается страница «устаревших тегов<\/a>». Вместо этого инициаторы «по-русски» хотят договориться с, судя по форуму, новичками и быстренько провернуть замену. Предложения написать в DWG или, как минимум, оповестить tagging@ сталкиваются с непониманием и страхом: вдруг откажут? По-моему, это — первый признак того, что вопрос перехода на новую схему вообще не стоит (а не «я выбираю первый вариант»), и что проблема «неактуальной тягомотины» надумана и раздута, не столько ради этой конкретной замены, сколько для оправдания будущих масштабных актов наведения порядка в базе.<\/div>", "date_published": "2012-12-13T11:52:51+04:00", "date_modified": "2012-12-13T11:51:56+04:00", "_date_published_rfc2822": "Thu, 13 Dec 2012 11:52:51 +0400", "_rss_guid_is_permalink": "true", "_rss_guid": "https:\/\/shtosm.ru\/2012\/12\/13\/1\/", "_e2_data": { "is_favourite": true, "links_required": null, "og_images": [] } }, { "id": "952", "url": "https:\/\/shtosm.ru\/2012\/11\/14\/2\/", "title": "Десятки миллиардов отношений", "content_html": "
Dr&mx навёл на великолепный пропозал отношения, которое широко используется в Польше: type=person<\/code><\/a>. Оно связывает места рождения и смерти человека, а также место захоронения и памятники. И разумеется, отношения могут быть связаны друг с другом по родству (с закольцовыванием parent-child). Сделан этот пропозал специально для использования на кладбищах, к нему прилагается пресет и плагин<\/a> для JOSM.

Могилы же отмечаются как tomb=*<\/code><\/a> (тоже ссылка на польскую страницу: в английском переводе ограничились общим описанием). Интересно, что их количество в базе не сильно превышает количество отношений person. Возможно, американцы и итальянцы, также детализировавшие несколько кладбищ, удержались от создания отношения на каждого человека.<\/div>", "date_published": "2012-11-14T20:54:58+04:00", "date_modified": "2012-11-14T20:53:12+04:00", "_date_published_rfc2822": "Wed, 14 Nov 2012 20:54:58 +0400", "_rss_guid_is_permalink": "true", "_rss_guid": "https:\/\/shtosm.ru\/2012\/11\/14\/2\/", "_e2_data": { "is_favourite": false, "links_required": null, "og_images": [] } }, { "id": "923", "url": "https:\/\/shtosm.ru\/2012\/10\/14\/1\/", "title": "Пропозал childcare не прошёл, потому что вы все мужчины и не понимаете", "content_html": "