29 заметок с тегом

wiki

Оценка потерь

Напомню, что в вики есть список реакций разных программ на узлы с идентификаторами от 2³¹. Часть из них сломалась:
  • Osmosis можно использовать любой версии (от 0.36), но для ключей --used-node и --used-way нужно указывать параметр idTrackerType=Dynamic. Со следующей версии (0.42) этот трекер включат по умолчанию, а параметр, скорее всего, уберут.
  • Редактор Vespucci вылетает при скачивании данных с точками, созданными после 9 февраля, а также при загрузке новых точек на сервер. Исправленную версию автор обещал загрузить в Google Play позавчера, но ещё не загрузил.
  • Редактор POI+ (для iOS) некорректно загружает на сервер точки с большими идентификаторами, особенно отредактированные. Исправление выслано в App Store, но пока не опубликовано.
  • Mapnik выдаст неправильный id объекта, если его попросить, но этой функцией почти никто не пользуется, поэтому обычный рендеринг не затронут.
Coastcheck и Osmium были «оперативно» исправлены. Роутинговые библиотеки OSRM и Routino отделались unsigned int, отсрочив проблему на три-четыре года. Osm2pgsql давно компилируется в 64-битном режиме, но свежую версию под Windows собрали только сейчас.

Не надо орден

31 июля 2007 года Стив Кост присудил Лолкота великолепия Тому Хьюзу за запоминание браузером места на карте. Спустя неделю Ник Блэк отдал лолкота Дэвиду Эрлу за Name Finder (который через три года заменили номинатимом). «Должен признаться, пришлось обратиться к википедии за определением „лолкота“», — ответил тот. Первая картинка с котом и подписью облетела интернет всего за полгода до этой награды, в январе.

11 декабря 2012 года лолкот пропал с главной страницы вики. Отчасти потому что он портил впечатление от неё, с каждым месяцем всё более аккуратной и динамичной. Но настоящей причиной было то, что текст на врезке не менялся уже почти год, с 25 января, когда лолкота дали Ричарду Фэйрхэрсту за сайт switch2osm. Гарри Вуд, сожалея об утрате, поделился историей награды:
Изначально лолкот великолепия должен был присуждаться ежеденельно. Это продолжалось всего две недели (пока сообществу хватало сил поддерживать такой проект. Подобное едва ли могло продолжаться еженедельно)! Однако со временем ситуация слегка изменилась: лолкот превратился в высшую награду за вклад в OSM. Что-то вроде георгиевского креста за отвагу. Частота присуждений упала до трёх-четырёх в год.

И вот что странно, ничто не останавливает любого участника от присуждения лолкота кому и когда угодно. Мы не сочиняли никаких правил и не устанавливали выборных процессов. Не знаю, то ли люди в целом не понимали этого, то ли начали слишком уважать лолкота, чтобы им разбрасываться. Но частота в последнее время снизилась ещё больше. Решений два: либо мы присуждаем его кому-нибудь! Либо убираем лолкота со страницы, пока кто-нибудь не захочет его присудить (при этом его, скорее всего, забудут и отправят на пенсию). Не знаю, правда, готовы ли мы проститься с ним навсегда.

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

Недавно 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@ сталкиваются с непониманием и страхом: вдруг откажут? По-моему, это — первый признак того, что вопрос перехода на новую схему вообще не стоит (а не «я выбираю первый вариант»), и что проблема «неактуальной тягомотины» надумана и раздута, не столько ради этой конкретной замены, сколько для оправдания будущих масштабных актов наведения порядка в базе.

Большая битва редакторов

Долгое время на странице статистики по редакторам велась история количества пользователей и количества ченджсетов для каждой из программ загрузки данных в OpenStreetMap. В июле Oli-Wan выкинул весь этот пыльный хлам и заменил его наглядной таблицей и графиком. Потом добавил ещё график, и ещё... В итоге, через месяц страница выросла вдвое, и теперь содержит около десятка таблиц с графиками и развёрнутыми пояснениями к ним. Оттуда можно узнать, что:
  • количество пользователей JOSM растёт незначительно: большинство новых пользователей предпочитает Potlatch;
  • но потлатч не может соперничать с JOSM по количеству редактируемых объектов: разница примерно пятикратная;
  • при этом средний размер ченджсета JOSM всего вдвое превосходит таковой у Potlatch 2 — но хотя у JOSM примерно поровну маленьких и больших ченджсетов, пакеты правок от 10 тысяч объектов, созданные в Potlatch 2, можно пересчитать по пальцам;
  • версии JOSM у его пользователей отстают в среднем на три месяца от текущей;
  • Merkaartor-ом пользуются меньше участников, нежели первым потлатчем, хотя и эффективнее: разница в числе правок обратна разнице в пользователях;
  • растёт популярность мобильных редакторов: iLOE (iPhone), Vespucci, OsmAnd (Android);
  • редактор OpenStreetMap в ArcGIS уже опробовали примерно двести человек.

ONW: OpenStreetMap is Not Wikipedia

Stephen Heuel ставит под сомнение титул OSM как «википедии, только про карты». Нарисовав большую круговую диаграмму, он делает вывод, что хотя проекты схожи, в деталях они различаются, поскольку работают с разными уровнями информации. Далее он перечисляет сходства:
  • И осм, и вики — краудсорсинговые проекты, эксплуатирующие эффект «длинного хвоста» (внимание к не-мэйнстримовым объектам).
  • Поэтому оба проекта удивляют экспертов: как получается, что неопытные интернет-пользователи могут соперничать с профессиональными энциклопедистами или картографами?
  • По поводу часто критикуемого качества материалов книга «Мудрость толпы» отмечает, что хотя качество википедии как целого очень высоко, этого нельзя сказать в отношении отдельных статей. Контроль качества — важная тема как в википедии, так и в OSM.
  • Неоспоримое преимущество обоих проектов — постоянное обновление: открытые дороги появляются в OpenStreetMap почти мгновенно, в отличие от коммерческих карт.
  • Обоими проектами заправляют фонды: Wikimedia Foundation и OSMF соответственно. Источник доходов в обоих случаях — пожертвования.
  • Полные данные обоих проектов доступны всегда и бесплатно.
  • Технические сложности свойственны и википедии, и OSM: даже вики-синтаксис понятен немногим гуманитариям, что уж говорить о сборе и заливке GPS-треков, или обклацывании снимков.
  • Модель тегов OSM и вики-синтаксис — примеры неструктурированного хранения информации. Конечно, обе базы можно привести к удобной форме (экспорт в шейпы или DBpedia), но в общем случае нельзя ожидать, что данные обоих проектов будут удовлетворять какой-то схеме.
И различия:
  • Википедия предоставляет готовые к использованию материалы (текст, картинки), а OpenStreetMap — только данные, на базе которых пользователи строят сервисы. Эта разница очень существенна, поскольку для использования данных OSM требуются недюжинные технические способности.
  • Оригинальные исследования явным образом запрещены в википедии, но миссия OSM — именно сбор новой информации. Для рисующих карту даже требуется знать отмечаемые POI или дороги, чтобы вносить их в базу. Если бы у нас был такой же запрет на уникальную информацию, OSM бы превратился в импортосборник.
  • Данные википедии распространяются под лицензией CC-BY-SA, у нас же вот-вот будет ODbL, потому что первая лицензия не подходит для баз данных.
  • Википедия ставила целью, и для многих уже заменила обычные энциклопедии. OSM, однако, никак не может служить заменой официальным геоданным, разве что дополнять их (в серьёзных применениях, вроде планирования и строительства).
  • Отслеживание правок в википедии несоизмеримо проще мониторинга данных OpenStreetMap. С другой стороны, у нас и спама значительно меньше.
  • Наконец, википедия гораздо старше, и если спросить на улице первого встречного, вероятность, что он знает о википедии, значительно выше вероятности узнавания OpenStreetMap.
Странным образом у нас на форуме тоже начали сравнивать эти два проекта, и об одном из различий здорово написал Тарзан:
Что касается статей... А вы не читайте. Я, например, сам обращал внимание на хорошие советы, как реально можно использовать Википедию, пока она не так хороша: как стартовую точку в поиске информации, как источник ссылок и как список ключевых слов. Уже очень неплохо. А единственный в принципе пригодный для использования раздел — это немецкий, как был, так и остался.
Ранее Ctrl + ↓

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