Избранное

Позднее Ctrl + ↑

Кнопки не нужны

Вчера в телеграме, развивая мысль про интерактивные карты как признак ленивого дизайнера, я написал, что кнопки плюс-минус — худшее, что есть в картах после переключателя слоёв. Кажется, многие читатели восприняли это как шутку, а другие поделились контекстом, когда эти кнопки не заменить. Например, когда нужно управлять телефоном одной рукой, или демонстрировать карту на проекторе с пультом. Все эти проблемы — лишь следствие того, что мы слишком привыкли к плюсу и минусу.

Современные интерактивные карты выглядят гораздо проще классических ГИС: нет панели с полусотней слоёв, нет трёх рядов кнопок управления и панели состояния с рядом загадочных чисел. Мы постепенно избавлялись от лишнего, и теперь карту загораживают только строка поиска и несколько кнопок. К сожалению, для хорошего интерфейса недостаточно убрать лишнее: нужно убрать, а затем переизобрести всё остальное.

Кнопки изменения масштаба появились от свойств тайловой схемы вкупе с линукс-мышлением. Тайлы, из которых состоит карта, устроены просто: на нулевом масштабе один тайл, на первом — четыре (2×2), на втором — шестнадцать (4×4) и так далее, каждый квадратик делится пополам в обоих измерениях. Линукс-мышление требует максимальной конфигурируемости: вдруг пользователь захочет посмотреть на карту конкретно на 13 масштабе, а мы ему не дадим? Поэтому развитие карт идёт увеличением количества уровней масштаба как вглубь, так и вширь, добавлением промежуточных уровней и переходом на векторные тайлы с непрерывным масштабированием. Больше контроля пользователю!

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

Эти кнопки — бич веб-картографии. Как не устаёт напоминать Сергей Голубев, при каждом нажатии на «+» вы видите новую карту, с собственным картостилем и свойствами. На сайте osm.org у нас 20 (двадцать) различных картостилей. Каждое изменение стиля osm-carto затрагивает примерно половину из них, поэтому неудивительно, что дискуссии в репозитории обильно иллюстрированы и могут затягиваться. Но если подумать, действительно ли пользователю нужны все эти карты? Вне компьютера хватает трёх-четырёх: атласа мира, атласа области и карты города. Когда масштабов мало, больше времени остаётся на полировку оформления каждого. А точная настройка интерфейса становится излишней.

Изменить масштаб можно многими способами, в зависимости от устройства и сайта:

  • кнопками плюс-минус на экране;
  • теми же кнопками с зажатым shift для большей скорости;
  • ползунком масштабирования;
  • колёсиком мыши;
  • двойным кликом левой кнопкой;
  • растягиванием прямоугольника мышью с зажатым shift;
  • кнопками «+» и «-» на клавиатуре;
  • перетягиванием двумя пальцами на тачпаде или экране;
  • щипком или расщипком на экране;
  • дважды тыкаешь пальцем, второй раз не отпуская удерживаешь и тянешь вниз или вверх.

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

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

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

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

Вечно ноль шестой

Ровно десять лет назад проект перешёл на API версии 0.6. API, или протокол, — это то, к чему обращаются приложения-редакторы карты для скачивания и загрузки данных на сервер. Как видно, этот протокол менялся пять раз, причём каждый раз серьёзно: то отношения появятся, то сегменты (отрезки между двумя точками) пропадут. Шестая версия API — последняя. Вчера у неё был юбилей.

Зачем мне об этом знать?

API — это не столько протокол обмена информацией, сколько описание модели данных. Именно он определяет, что карта состоит из точек, линий, отношений и тегов, что у объектов есть версии, что в линии не может быть более двух тысяч точек и так далее. Когда менялся протокол, менялась модель данных. Как в реальном мире полезно знать основы физики, в OpenStreetMap полезно знать API.

Насколько всё странно было раньше?

Изменения в четвёртой, пятой и шестой версиях перечислены в вики. Вторая версия API стала работать через ссылки (REST), а не через сложные запросы XML-RPC, и в ней появились теги. В третьей версии теги вынесли из строкового атрибута xml в отдельные элементы <tag>, а сегменты объединили в линии (way).

Что изменилось в версии 0.6?

Появились пакеты правок и номера версий. Раньше объекты загружали по одному, а история адресовалась только по меткам времени. Линии ограничили 2000 точками, пакеты правок — 50 тысячами объектов (позже снизили до десяти тысяч), а члены отношений стали упорядочены (раньше они возвращались в случайном порядке). Кроме того, базу данных перевели с MySQL на PostgreSQL.

Зачем понадобилось менять протокол?

В феврале 2008 года, через четыре с половиной месяца после включения API 0.5, Фредерик Рамм написал пропозал «Пакеты правок и откаты», который поднимает важную проблему проекта: отмену ошибочных правок — и выводит из неё всё, что со временем вошло в API 0.6.

3-4 мая участники из Великобритании, Германии, Австрии и Нидерландов собрались в Лондоне на «Monitoring and Rollback Hack-a-thon», где обсудили новый API, составили его черновик в вики и наметали новые функции в коде.

Кто и как писал новый API?

Короткий ответ: Cloudmade. С 2007 по примерно 2010 годы эта компания была крупнейшей, связанной с OpenStreetMap. Венчурное финансирование помогло фокусироваться не на зарабатывании денег, а на развитии OSM. Среди её сотрудников были известные разработчики Стив Кост, Энди Аллан, Мэтт Эймос, Шон Макдональд и Гарри Вуд. В октябре 2008 они плотно взялись за код Rails Port, оценили фронт работ и разметили задачи. Примерно за две недели большая часть работы была сделана — но было непонятно, где её конец.

Финишный рывок разработчики сделали на неделе 3-9 ноября в лондонском офисе Cloudmade. Присутствовали те же сотрудники плюс Фредерик, Ричард и Грант. Сначала на встрече «APIzza 0.6» участники договорились об окончательном виде API. Затем на хакатоне на выходных они запрограммировали тесты и оставшиеся методы. Немного допилили напильником — и в середине ноября код был готов, а Бретт выпустил Osmosis с полной поддержкой нового API. Напомним, что Osmosis до сих пор является центральным инструментом в OSM: на нём работает репликация, а в то время только эта программа умела вырезать куски из карты и фильтровать по тегам.

Как переход проходил для пользователей?

11 декабря Шон Макдональд объявил о публичном тестировании нового API. На временный сервер загрузили карту Лондона и предлагали пользоваться Potlatch, JOSM, Merkaartor и Osmosis, чтобы отловить все возможные ошибки перед окончательной миграцией.

В конце января Стив Кост объявил о переходе на новый протокол через два месяца. Новая база данных должна была встать на новый сервер, но его не привезли вовремя: переход отложили на 17-20 апреля 2009 года. За день до назначенного времени Энди Робинсон предоставил официальную информацию о переходе. 21 апреля в 9:43 UTC Ричард Фэйрхёрст объявил: «Мы вернулись — с API 0.6, постгресом и новым сервером».

Так что, отменять правки теперь легко?

Впервые этот вопрос задали через три часа после включения API 0.6. Тогда был ответ «нет», и сейчас он тоже «нет». Но, по крайней мере, нынче есть выбор инструментов разной степени сложности. До кнопки отмены в интерфейсе а-ля википедия нам ещё очень далеко.

Отлично, а когда перейдём на API 0.7?

Теперь уже очевидно, что никогда.

Почему?

Протокол и модель данных достаточно хороши. Участники проекта накидывали идеи для следующей версии в эту вики-страницу; в её разделе «See Also» вы найдёте ещё несколько списков. Но не встретилось ничего настолько важного, что могло бы сподвигнуть сообщество взяться за написание API 0.7. Ни один человек самостоятельно не сможет улучшить протокол, потому что в OpenStreetMap слишком много несущих систем и участников, с которыми нужно договариваться.

Нельзя ли как-нибудь изменить по мелочам?

Современный API 0.6 заметно отличается от того, что мы получили десять лет назад. Примерно с 2012 года к нему начали прикручивать дополнительные функции, не затрагивающие модель данных. В мае 2012 приложения смогли узнать, какие у них права. В августе для перелицензирования в API добавили скрытие версий объектов. В апреле 2013 появились заметки. В ноябре 2014 пакетам правок добавили комментарии. Последний раз протокол улучшали полгода назад, когда улучшили поиск заметок через /notes/search.

Перелицензирование?

Забавный факт: 27 февраля 2009 года, в разгар подготовки к замене сервера и протокола, рабочая группа по юридическим вопросам предоставила план перехода на ODbL. По нему, весь процесс должен был занять всего три-четыре месяца — именно во столько поначалу Фредерик оценивал время на переход на API 0.6.

Скованные одним слоем

В прошлой заметке мы узнали, что осмеры рисуют карту для себя и поэтому препятствуют внесению большого количества данных. Кроме того, свежесть данных почти невозможно проконтролировать, поэтому лучше сдаться заранее. Откуда взялись эти проблемы — модель данных же предполагает бесконечное расширение? Может быть, это не проблемы, а всего лишь задачи для нынешнего поколения картографов и разработчиков?

Клубок данных

Шесть лет назад слои были у всех на устах. «Какие слои в вашем проекте закончены?» — спрашивали на конференциях. «Рано или поздно придётся внести понятие слоёв», — комментировали в штосме. И вот мы в 2018, как успехи в этом направлении?

У нас были сайт Ito Map и панель фильтров в JOSM: ввела highway=* и получила слой дорог и связанных с ними POI. Теперь к ним добавились тематические сайты на основе Overpass API — например, редакторы полос от Almaz. Это круто, конечно, но не решает общую проблему OpenStreetMap.

Проблема с нашими данными в том, что они неделимы. Это хуже, чем топология (когда объекты собираются из частей): связи в данных невероятно прочны и непредсказуемы. Точка лежачего полицейского в составе линии дороги, территория школы и забор вокруг неё в одном объекте, остров-лес... Мрак для человека, всю жизнь работавшего с шейпфайлами. Добавим сюда отношения с сотнями автобусных маршрутов поверх одних и тех же дорог, административные границы по рекам и прочие радости типа type=person — и трогать данные становится страшновато.

Спрятать лишнее фильтрами? Не только потеряем некоторые сильные связи (см. границы по дорогам), но и наткнёмся на распространённые слабые связи: когда кажется, что объекты не связаны, но их взаимное расположение или общие элементы важны. Например, многие проспекты разбиты на сегменты, которые объединяет только тег name (да и то не всегда). Магазины нередко находятся внутри здания с shop=mall (или без этого тега, но с названием вида «ТЦ Скрытный»). Как узнать адрес кафе? Ищете дом, содержащий кафе, затем точку с адресом, лежащую внутри контура дома, ближайшую к кафе.

Зато модель данных простая!

OpenStreetMap с самого начала был не про дороги. Это много карт в одной: города и административное деление, леса и поля, гидрография, дорожный граф и запреты поворота, улицы и адреса, каталог заведений, схемы общественного транспорта, база объёмных моделей зданий. Классические ГИС позволяют включать и выключать тематические слои, чтобы они не мешали работать. Классические ГИС умерли, потому что слои — слишком сложно. Единственный крестик в OSM — на вкладке браузера.

Справочник

Мы хотим, чтобы наша карта работала в качестве справочника заведений, и в этом не уступала коммерческим альтернативам — от странного Here до агрессивного 2ГИС. Разве не за этим вы старательно вводите часы работы магазина во время стоянки в путешествии? Не для этого удаляете с карты закрытое кафе по пути на работу? Как приятно в незнакомом городе найти хорошее кафе или неочевидную детскую площадку в OsmAnd! Сразу чувствуешь, что картографы-любители работают не зря.

«Смотри-ка, люди пользуются OpenStreetMap» — удивляются владельцы крупных организаций и просят своих менеджеров добавить все заведения сети на карту. Иногда срабатывает: когда заведений немного и их можно добавить руками. Иногда они обращаются к тем же компаниям, что добавляют их в коммерческие справочники — и вы знаете, что происходит. Картографы не хотят, чтобы на карте были все объекты. И не только потому что они будут мешать картированию — а они будут, своей неидеальностью, — но и потому что начнётся неявное соревнование человека и «машины». Бездушной капиталистической машины.

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

Естественная реакция на подобную задачу — выделить слой справочника в отдельный проект. Тоже открытые данные, но с более жёстким классификатором и более дружелюбный к организациям и импортам. Перенести все POI из OpenStreetMap и установить правило: справочник → там. Короче, предложить OpenCorporates двухсторонний обмен информацией.

Разумеется, это не сработает: OpenCorporates — это коммерческая компания, а одно из главных достоинств OSM — что наши данные ни от кого не зависят. Как и другие достоинства, с другого ракурса оно скорее походит на недостаток. Но чинить, что не сломано, — не наша задача. Поэтому наш справочник — это OpenStreetMap. У нас есть база заведений, мы умеем отделять её от других данных. Насколько эта база хороша?

Доверия к заведениям в OSM нет даже у опытных осмеров. От моего дома до ближайшего неотмеченного на карте заведения двести метров. Уверен, это расстояние не превысит полукилометра для значительной части активных редакторов. Когда нужно найти кафе, я открываю foursquare, когда ищу автосервис — карты яндекса. Чем больше POI на карте, тем меньше уверенности в их актуальности. Точки вполне могли нарисовать несколько лет назад. А когда фрагмент карты выглядит относительно полным, осмеры перестают его замечать. Наши инструменты не делают удобным обновление данных. Приятно отметить новый магазин. Удалить закрытый сложно.

Будущее

«Участвовать в проекте легко — достаточно зарегистрироваться и нажать кнопку „Правка“». Нажимаем, видим мешанину как на рисунке ниже. Как здесь найти магазин, который нужно поправить, или как тыкнуть в парк, чтобы его обвести, или как проложить тротуар и не зацепить ничего лишнего? Любой опытный осмер, запомнивший, какой кнопкой расцеплять линии, ответит, что это почти невозможно. И мы даже не упоминаем отношения. Постепенно территории, где опасно орудовать в iD и неудобно в JOSM, расширяются. Когда-нибудь такой плотной станет вся карта — и это не будет поводом для радости.

Могли бы помочь автофильтры, вот только за полтора года мы не увидели работ в этом направлении. Да и нынешние их воплощения не сильно отличаются от обычных фильтров, проблема которых описана выше. Нет, дополнительной функциональностью существующие редакторы не поправишь. Пора признать, что в OpenStreetMap у стандартного подхода «скачать всё и потом редактировать» нет будущего. Ни JOSM, ни iD, ни Vespucci, ни Go Map не посоветуют новичкам через десять лет.

Что же посоветуют? Другие редакторы, эксперименты в которых мы видим в последние годы. Прежде всего, это Maps.Me и StreetComplete. Несмотря на технические недостатки, ими пользуются десятки тысяч пользователей. Их особенность — они тематические. Не пытаясь обрабатывать весь клубок данных, они вытаскивают и пришивают только интересные им ниточки: POI и дополнительные атрибуты. Пользоваться ими легко, и для работы с этими слоями даже опытные осмеры предпочитают достать телефон, а не запускать редактор на компьютере.

Именно это и произойдёт в будущем: редакторы всё-в-одном расслоятся на низкоуровневые, типа Level0, и тематические. На мобильных устройствах последние уже победили, теперь дело за настольными редакторами. Вдохновляющие заметки о первых попытках их сделать только начинают появляться в ленте. Например, Deriviste от Ричарда: простая (и очень сырая) страничка с фотографией из Mapillary, картой и поиском по заготовкам тегов. Дважды кликаешь на магазин на фотографии, корректируешь его расположение, вводишь «фрукты» и идёшь дальше. Обработка фотографий из картографической прогулки раньше была невыносимо сложной, а теперь это игра. Гениально.

Пока что у нас нет ни единого законченного тематического редактора, которым хотелось бы пользоваться вместо обычных. Близки к таким редакторы полос, упомянутые выше. Может, ещё Conflation Audit для подтверждения изменений при импортах POI. Логичным развитием его будет помощь при загрузке любых пакетных точечных данных — так что видя страницу магазина с пятью адресами, захочется открыть этот редактор, а не JOSM или iD, потому что он удобнее и гарантирует обновление данных, когда обновится сайт.

Чудесные тематические редакторы будущего обойдут все проблемы, которые описаны ранее:

  • Они очевидным образом решают вопрос слоёв, работая только со срезом данных. Например, вы указываете автобусные остановки по маршруту, а редактор сам прокладывает маршрут по ближайшим улицам и после проверки правильно разрезает их и собирает отношения route. Связи между слоями станут не случайными, а осмысленными и одобренными пользователем.
  • Они автоматизируют редактирование: заботы об обновлении данных лягут не на супер-картографов, коих сейчас один человек на миллион жителей, а на машину. Она сама скачает данные из того же источника и сама напомнит, когда ваш вклад начнёт выглядеть устаревшим. Хранение жизненного цикла внутри OSM не работает, в отличие от сторонних сервисов, которые знают, что делать со всеми этими датами.
  • Они дают уверенность в качестве данных, потому что валидируют не только геометрическую и техническую корректность, но и источник, и взаимосвязь объектов внутри темы, и возраст данных. Импорты станут умнее, потому что у импортированных объектов будет история. Авторы редакторов будут писать валидаторы не вширь, как в JOSM, а вглубь, находя новые неочевидные способы убедиться в правильности изменений.

В мире, где люди открывают редактор карты, чтобы поправить время работы или чтобы нарисовать новый маршрут автобуса или вырубку, а не тупо покопаться в месиве из данных, OpenStreetMap будут воспринимать тем, чем он является: множеством разных карт в одной. Которые в сумме больше и полезнее, чем по-отдельности.

Дело за малым: придумать и написать. Авторы потенциальных редакторов-хитов должны не только хорошо разбираться в OpenStreetMap и уметь программировать, но и иметь опыт в проектировании хорошего UX. Знать все примеры хорошего пользовательского дизайна в картографии: сайта Moovit, редактора запретов поворотов в iD, алгоримов модерации, интерфейса «народных карт»... Да, подвох тут очевиден. Продолжение следует.

Агентам справочника вход воспрещён

Анна из «народной карты» расписала в их блоге, откуда берутся заведения на картах яндекса. В компании ведут два набора данных: «справочник» и «народная карта». Копирование данных налажено пока только из карты, скоро будет и обратное. И этот поток автоматических правок будет куда сильнее: ведь доля пользовательских данных в наполнении справочника очень мала.

Здесь всплывают две темы: постепенное замещение картографов-любителей роботами на «народных картах» под безграничное терпение первых и приоритеты в картографировании заведений. Обе темы подчёркивают радикальное отличие и «народных карт», и просто карт Яндекса от OpenStreetMap во всех своих ипостасях.

Приоритеты

В заметке перечислены восемь источников данных о заведениях, которые склеиваются и доступны из поиска на карте: правки народных картографов, сообщения из разных видов обратной связи, информация от организаций и от оплачиваемых сборщиков данных. Сколько из них есть в OSM? Только два: правки осмеров и заметки на сайте. Хотя, честно говоря, заметками владельцы заведений не пользуются, потому что их почти невозможно найти.

Где всё остальное? Ладно, у нас нет службы поддержки и сотрудников, обзванивающих организации. Но многие компании специально платят, чтобы их филиалы наносили на карты — и мы осознанно сопротивляемся этим «импортам». Что хорошо для всех популярных карт, оказывается плохо для OpenStreetMap. Как же так?

Дело в целевой аудитории. Кто адресат нашей карты, для кого мы рисуем? На сайте и в вики про это ни слова. «OSM предоставляет данные тысячам сайтов» — ничего не значащее утверждение, этот блог тоже предоставляет. А если OSMF и администраторы сайта отказываются ограничить ЦА карты, за них это сделают сами картографы. Самым очевидным способом.

OpenStreetMap — это карта для картографов под открытой лицензией. Два тезиса, которые определяют все решения в проекте. Открытая лицензия регулирует отношения со внешним миром: запрет на нелегальные данные и обклацывание гугля, публикацию планеты под ODbL, экосистему открытого кода. А первый тезис, что целевая аудитория — это картографы, регулирует все вопросы внутри сообщества. Прежде всего, конечно, тегирование, требования к редакторам и выбор допустимых слоёв для импортирования.

Самое неочевидное, что следует из ориентированности на редакторов карты, — это ограничение на размер данных. Когда их становится слишком много (например, после массового импорта «зелёнки»), сообщество бунтует и заводит reverter. OSM состоит из одного слоя, который непросто разделить по типам объектов, поэтому один перегруженный слой затрудняет редактирование остальных. Нарисовали схему помещений — контур здания теперь не улучшить. Импортировали Corine — проще закрыть редактор, чем обозначить вырубку. Обозначили каждый лоток на рынке — никто не будет обновлять информацию, да и проходы трогать побоятся.

Поэтому участники неодобрительно смотрят на импорты заведений. С одной стороны, пользователям карты хорошо: можно найти в любимом Maps.Me или OsmAnd заправку по пути и кафе у гостиницы. С другой, мы рисуем OSM не для пользователей: сотни тысяч, если не миллионы, импортируемых точек нужно проверять, поддерживать, обновлять. Никто этим не будет заниматься, а потому они не должны быть частью карты. Карта — для того, что интересно рисовать и несложно поддерживать.

Роботы

Задачу поддержки заведений из сторонних источников решить несложно: периодически проверять и импортировать заново. От картографов ничего не понадобится, только верить и не мешать. Разумеется, правки импортированных данных сохранятся после обновления — или нет, смотря сколько времени прошло. В перспективе это можно распространить на «зелёнку» и адреса.

Получится, что за существенную часть данных OpenStreetMap — сотни миллионов объектов — будут отвечать роботы, пусть и курируемые людьми. Медленно процесс поддержки данных OSM будет мигрировать к модели википедии, когда в истории правок любой статьи минимум 10% правок идут от роботов, следящих за порядком. Потому что если можно импортировать, то почему нельзя автоматически amenity=sauna заменять на leisure=sauna? Логично же это поручить роботу и спать спокойно, зная, что база консистентна?

В народных картах Яндекса это само собой разумеется. Там автоматизировано всё: импортирование данных в новых странах, сдвиг объектов при обновлении снимков, обновление данных из справочника. Роботам помогают сотрудники на зарплате и участники «Толоки», которых всё больше. Когда нужна актуальная и полная карта, полагаться на добровольных картографов-любителей недостаточно — это очевидно примерно всем. Поэтому народная карта мигрирует влево по шкале свободы картографии, усиливая контроль над содержимым карты.

Активным участникам сообщества НЯК это, конечно, не нравится. Данные от людей на зарплате предсказуемо хуже работы любителей — по всем показателям, кроме тех, что входят в ТЗ. «Теперь я не слежу за порядком. Спасибо яндексу за это», — хлопают дверью модераторы. Да и под заметкой про интеграцию справочника немало недоумённых комментариев. Это всё люди, которые не успели перестроиться три года назад и не поняли, что «народная карта» больше не самостоятельная песочница, где можно в одиночку нарисовать и поддерживать город, а инструмент обратной связи к картам Яндекса. Народные картографы теперь не столько правят карту, сколько корректируют импортированное и нарисованное профессионалами.

Очевидно, что автоматические правки противоречат целям сообщества OpenStreetMap: иметь карту, которую весело редактировать. Картограф с опытом всегда найдёт, какую претензию предъявить оператору любого скрипта. Данные плохо привязаны. Теги неправильные, но замена неравнозначна. Формат телефонного номера не тот. Это дискриминация против малого бизнеса. Хорошо, но проверяй каждый объект вручную. Этим атрибутам не место в OSM. Посмотрите на TIGER, хотите повторения? Любой импорт или автоматическая правка должны пройти через болото уныния, и редкий энтузиаст доползёт до его середины.

Мы говорим «карту может поправить каждый», но мы же и говорим «карта для любителей, а не корпораций». Мы ратуем за карту без дискриминации, но в то же время рисуем таблички про вход воспрещён. Открытый проект, но пожалуйста, не надо. Решить это противоречие может сильная структура, наделённая правом окончательного голоса. Но в нынешней парадигме «Совет + рабочие группы» такая структура невозможна. Тут либо делать альтернативный проект, либо повторить то, что Стив Кост сделал четырнадцать лет назад: выкручиваться малыми силами, находя новые смыслы в существующих структурах. И не сказать, что это невозможно. Продолжение.

OpenStreetMap не ваш

На волне новостей от Google Том Чедвин напомнил о преимуществах открытого софта и закончил заметку словами: «теперь у вас есть железный аргумент для тех, кто спрашивает, почему бы просто не взять Google Maps».

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

Разумеется, это преувеличение. У нас замечательная, красивая карта, которой во многих областях нет не то, что равных, — нет альтернатив. Ниоткуда вы больше не возьмёте в меру корректный граф дорог. Ни по одной другой карте не прикинете плотность населения. Никто не даст вам данные, чтобы установить копию сервиса в закрытой сети.

Но нельзя не заметить, что OpenStreetMap загибается. Не потому, что у нас база данных вместо карты, или модераторов нет, или данные не разделены на слои, как придирался Серж. Для технически подкованного человека поверить в упадок OSM невозможно: это же децентрализованные данные, они по определению вечны. Кроме того, они бесплатны и наполняются миллионом редакторов по всему миру: почему их не использует каждый первый сайт?

А дело в том, что невозможно нас использовать. OSM проигрывает любой альтернативе по одной причине: нет контроля. Ни у кого. Ни над чем. OpenStreetMap примерно с 2012 года на автопилоте летит в бездну, и редкие попытки выправить курс наталкиваются на хмурых амбалов, защищающих ручки управления со словами «не позволим захватить власть» и «у нас саморегулирующийся проект». Сила проекта оказалась его слабостью — и, кажется, фатальной.

Над картой нет контроля. Хотите импортировать сеть своих магазинов? Фигушки, ваше качество данных не отвечает нашим критериям. Хотите порисовать свой посёлок? Познакомьтесь с местным вахтёром, который сначала поругает вас за выбор классов дорог, а затем пропадёт, потому что вы невыносимы. А вахтёрам, кстати, тоже несладко: четырнадцатый год проекту, а лучшее, что мы смогли сделать для контроля качества, — OSMCha. Пользователи которого до сих пор стонут от диаметров больших, но худых пакетов правок. Автора OWL мы успешно потеряли. Члены DWG до сих пор для работы пользуются скриптами на Perl из прошлого десятилетия.

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

Над моделью данных нет контроля. В последний раз для изменения API потребовались деньги и усилия целой компании Cloudmade, десятка осмеров, работавших за венчурные инвестиции несколько недель. Надежда на тип area или другие изменения тлела лет пять назад, но теперь об изменениях перестали думать даже самые оптимистичные осмеры. Единственное, что нас ждёт в API, — это огораживание личных данных для GDPR, да и то потому что штраф платить никто не хочет.

Над тегированием нет контроля. Главное отличие и достоинство OpenStreetMap — свободная атрибутивная модель — настолько разрослась, что никому, даже ветеранам проекта, не под силу выбрать правильные теги. Форумы полнятся шутками про вереск, лес и пространства имён. Пропозалы — смех: с одной стороны изобретают инопланетные схемы на полсотни килобайт, с другой изворачиваются в попытках потопить каждое предложение. Новички не офигевают только потому, что все редакторы, даже мобильные, заменили таблицы тегов заготовками.

Над картостилем нет контроля. Когда-то основной стиль был настолько сложен, что все боялись к нему притронуться. Потом его перевели на CartoCSS, навели порядок, и сразу потянулись участники, пошла работа. Несколько лет улучшали значки и цвета, поменяли структуру базы данных, причесали шрифты — карта стала выглядить прилично, как у людей. Такая же блёклая.

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

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

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

Наша лицензия запрещает всё это, от чего третьи стороны не особо страдают — у них уже есть достаточно данных. Страдаем мы, потому что не можем адекватно ни с кем договориться. Участники сообщества зорко следят, чтобы никто не проскочил. Даже с тривиальными случаями использования у нас проблема. Я только за этот год видел полдюжины вопросов насчёт использования карты в телепередачах, и каждый раз на одинаковые вопросы им выдавали разные ответы. Никто, даже юридическая рабочая группа, не понимает ODbL. Но это статус кво, в OpenStreetMap он тут власть.

Как вы знаете, в этом мире чтобы оставаться на месте, нужно быстро бежать. Я читаю новости 2ГИС, Яндекс.Карт, Google Maps и вижу, что они пробуют новые алгоритмы, новые точки зрения. Меняют интерфейсы, постоянно дополняют модели данных, учатся по-новому взаимодействовать с сообществом. Реагируют на проблемы структурными изменениями. В их возможностях всё поменять — или наоборот, причесать данные, сгладить углы, сделать удобно. Они могут купить и продать, чтобы сделать свою карту лучше.

Всё, что на сегодня способно сообщество OpenStreetMap, — сообща за выходные нарисовать домики ещё в одном городе. Поэтому главными применениями проекту остаются гуманитарные инициативы, да использование в качестве подложки, когда не хватило денег на нормальную карту. Вспомните, что у нас такого происходило за последний год, достойного заметок в главных технологических журналах? Новую версию JOSM выпустили с обрезанием пробелов в тегах?

Да, полагаться на проприетарную карту — значит, отдавать часть контроля корпорации. Но вы уверены, что хотите иметь контроль над каждой частью картографического стека? Вам точно хватит денег? Коммерческая компания может изменить условия и поставить вас в неловкое положение, но от OSM её отличает договороспособность. Там работают живые люди и у них есть все рычаги: можно позвонить и сторговать лимиты, или попросить помочь с картографическими данными. Для них вы — клиент; для OSM вы, если чего-то хотите от карты для бизнеса, хуже чем никто.

Поэтому OpenStreetMap не растёт. Если приглядеться, на графиках намечаются негативные тренды. Как викимапия около 2011 года, наш проект выбрал большую часть своих смыслов. С нынешним направлением у нас ещё лет десять, после которых мы будем выглядеть как викимапия сейчас: с кучей данных и без сообщества, разбежавшегося по альтернативным проектам. И тогда уже люди, выбравшие OSM как замену Google Maps, задумаются.

Именно сейчас, в ближайшие два года, нужно найти для проекта новые векторы развития. Риторика «а зато у нас бесплатно», неизменная на протяжении десяти лет, превратилась из прогрессивной в жалкую. Главный вопрос — зачем вам OpenStreetMap, когда есть много альтернативных картографических сервисов, каждый из которых в чём-то его превосходит (и не надо тут про качество отрисовки вашего двора)? Может, мы собираемся перевернуть обучение географии, или стать новой универсальной базовой картой, или заделаться фреймворком для экспериментов в новой картографии. Любой ответ хорош, если вы готовы подкрепить его делом.

А пока что для многих организаций проще взять Google Maps.

Ранее Ctrl + ↓

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