Позавчера Mapillary неловко объявили, что их купил Facebook. Из размеров компаний уже понятно, что это большие новости: не зря они пролетели по всем технологическим блогам и телеграм-каналам про данные.

Хранить и обрабатывать миллионы фоточек для картографических нужд сложно. В 2009 году Джон Маккеррел сделал проект OpenStreetView, куда люди загружали снимки по одному через веб-интерфейс или пакетом через ftp. Модерировать их было скучно, законы на съёмку публичных пространств слишком ограничивали, а стоимость хранения данных не падала. Казалось, сделать открытую альтернативу Google Street View было технически невозможно.

Спустя пять лет шведский стартап Mapillary доказал обратное. Они не распространялись про источники финансирования, но кажется, среди коммерческих компаний был огромный запрос на хранение и обработку частных панорамных снимков. Для OpenStreetMap в компании за следующие шесть лет сделали очень много: собрали и опубликовали более миллиарда фотографий, встроили слои в iD и JOSM, автоматизировали распознавание дорожных знаков и прочих объектов. Mapillary ощущается такой же частью инфраструктуры открытых карт, как, например, Overpass API. Он полезен не только для OSM: муниципалитеты и министерства разных стран публикуют в нём снимки для отслеживания состояния улиц.

Для всех пользователей Mapillary эта покупка — отличная новость:

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

Последний пункт особенно удивляет, если не понимать, для чего фейсбуку Mapillary. Купили проект не за перспективную бизнес-модель: в сравнении с Facebook их прибыль ничтожна. Это не случай maps.me, когда после года бесплатного развития mail.ru потребовал от проекта прибыли. Технологические гиганты покупают стартап, если а) он решает какую-то проблему компании, б) у него исключительно талантливая команда. В последнем мы не сомневаемся.

Зарабатывать на Mapillary фейсбук не планирует, и конкуренции он тоже не боится. Полгода назад Grab купил OpenStreetCam — альтернативу Mapillary с 2016 года. Это был более гиковский проект, ориентированный только на снимки с автомобилей. Разработчики Telenav, владельца OSC, даже сделали интеграцию со сканерами OBD2: знание скорости и угла поворота машины помогает улучшать координаты с GPS. Увы, после покупки сервис долго не прожил: загрузка треков начала барахлить, ответственных не найти. Мы считаем, что OSC теперь решает внутренние задачи Grab, а для публики он умер.

OpenStreetCam создавали, потому что универсальный контракт с Mapillary был бы слишком дорогим, и перекупили его по той же причине. Сложно представить, что условный Uber сможет получить все фотографии от нынешнего владельца OpenStreetCam, их азиатского конкурента. Но Uber и Grab не конкуренты фейсбуку, а другие социальные сети едва ли могут получить преимущество от фотографий улиц. Поэтому открывая снимки Mapillary для коммерческого использования, Facebook ничем не рискует.

С покупкой Mapillary фейсбук получает миллиард фотографий и двадцать магистров и кандидатов наук с кучей опубликованных статей, патентов и алгоритмов. Зачем им? Ответ неожиданен и прост: пока мы не смотрели, Facebook превратился в главную технологическую компанию в OpenStreetMap, оставив окуклившийся Mapbox позади. Видимо, кто-то убедил Цукерберга, что на рынках Азии и Африки можно заработать больше, если в приложениях жители городов смогут найти свои улицы. А поскольку свою карту фейсбуку делать не резон, а готовые сложно подбирать и дорого покупать, то компания обратилась к OpenStreetMap.

Facebook известен в проекте тем, что с помощью нейросеточек находит на спутниковых снимках дороги, векторизует их, сравнивает с дорогами в OSM и помогает картографам быстро дорисовать недостающее. Первые их попытки добавлять дороги в Египте и Таиланде поссорили их с местными сообществами, но спустя три года все рады нажимать на кнопки в RapiD, вместо того, чтобы отрисовывать дороги руками. У фейсбука, разумеется, есть скрытая армия картографов, но главное в OpenStreetMap — одобрение сообщества.

А теперь представьте, что вдобавок к снимкам и данным OSM фейсбук получил фотографии Mapillary. Как тут развернутся их инженеры! Со спутника видна дорога, с камеры — её покрытие, разметка и знаки. Со спутника видим дом, с камеры — его высоту, материал, вывеску магазина. Берём заведения из OSM, сопоставляем с фотографиями, отмечаем вероятно устаревшие, передаём армии картографов. Считаем количество машин на фотографиях, выводим классификацию дорог. Несмотря на достижения команды Mapillary, они едва-едва вошли в океан способов использовать свои фотографии для улучшения карты. Взять тот же редактор Deriviste Ричарда Фейрхёрста: видишь скамейку на фото, кликаешь в неё, вводишь «скамейка», сохраняешь. Но в Mapillary уже умеют определять, что за объект на фото!

При всём этом ликовании некоторые осмеры в комментариях к новости настроены скептически, выкачивают свои снимки из Mapillary и закрывают аккаунты. Никто не любит фейсбук — и заслуженно. Я сам сократил посещение их сайта до пяти минут в день и не трогаю RapiD. Несмотря на заслуги Google и Microsoft, именно Facebook сегодня — технологическая корпорация зла. Проблема фейсбука не в технологиях, а в этике: едва ли Mapillary закроют или обвесят рекламой. Но кто знает, как именно компания воспользуется оригиналами фотографий со всего земного шара, чтобы пополнить свою базу данных о жителях (включая авторов снимков), их привычках, координатах и социальных связях?

Новые данные огорчат осмеров и новыми стычками с компанией. Facebook уже высказывал заинтересованность в импортах заведений и зданий. Усиленные распознанными фотографиями, коммерческие данные уверят сотрудников в том, что картографы-любители рядом не стояли с результатами работы их нейросеточек. Повторится Египет, только уже ближе к «первому миру». Компания извинится раз, извинится другой, а затем её инженеры найдут подход, чтобы убедить сообщество в том, что оно контролирует ситуацию. И в этот момент ещё часть контроля над данными уйдёт фейсбуку.

Уходить от Mapillary некуда: OpenStreetCam умер, остался... OpenTrailView 360 Ника Уайтлегга. Полностью открытый код, поддержка панорам, внимание на пешеходные маршруты. Достойное начинание — пока в проекте участвуют пара человек. Но стоит ему привлечь публику, как потребуется финансирование для хранения терабайтов фотографий и для разработки средств защиты личной информации, как то замыливания лиц и автомобильных номеров. Подобный проект может быть открытым в теории или в личном использовании, но масштабировать его можно только при поддержке крупной компании. Единственная альтернатива — каталог с геопривязанными фоточками на своём компьютере.

Facebook купил Mapillary, и это хорошая новость для фейсбука, для команды Mapillary, для жителей стран с плохими картами и для осмеров. Не терпится увидеть, как их разработчики придумают улучшать OpenStreetMap с новыми ресурсами и знаниями. Печально лишь то, что теперь, отправляя свежие снимки в Mapillary, нельзя не думать, что отправляешь свой маршрут и всё, что ты видел по пути, не в дружелюбную шведскую компанию, а в фейсбук.

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

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

Шесть лет назад слои были у всех на устах. «Какие слои в вашем проекте закончены?» — спрашивали на конференциях. «Рано или поздно придётся внести понятие слоёв», — комментировали в штосме. И вот мы в 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, алгоримов модерации, интерфейса «народных карт»... Да, подвох тут очевиден. Продолжение следует.

«Нельзя ли при отправке изменений из maps.me разделять объекты по континентам?» — в очередной раз спрашивают на форуме. А то bbox (ограничительный прямоугольник) слишком большой, неудобно. OpenStreetMap был зачат тысячу лет назад программистом, и это лезет изо всех щелей: удивительно, как самые бессмысленные атрибуты становятся мерилом качества.

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

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

То есть, единственная польза от пакета правок — это посмотреть, каким редактором сделаны правки. Все остальные атрибуты: даты, bbox, список объектов — только отвлекают, создавая ложное впечатление группировки и упорядоченности. Которых нет, потому что техническое воплощение API не обещает порядка и не подразумевает удобства. Так, для правок maps.me я игнорирую пакеты и рассматриваю каждую правку отдельно. Правки на mmwatch — это поток объектов, у которых номер ченджсета лишь бесполезный атрибут. Увы, для сложных правок со взаимосвязанными изменениями (таких как сдвиг линии) такой подход не сработает.

Примерно об этом я говорил на схемотехнике год назад. О bbox нужно просто забыть: область применения этих прямоугольников ограничена и точно не касается ваших задач. А проблему пакетирования нужно как-то решать. Развязать топологические структуры, группировать по времени и географии, не давать пользователям и приложениям свободы в объединении правок. Это настоящая тема для какого-нибудь будущего API 0.8. А пока приходится работать с тем, что есть.

Следить за изменениями в регионе можно (нужно!) через WhoDidIt, искать их — в его более быстром форке. Пакет правок из интерфейса этого сайта можно открыть в Achavi, но иногда может не повезти. Если bbox окажется слишком велик, загрузки правок вы можете не дождаться. Потому что даже лучшие инструменты полагаются на bbox, который, повторюсь, плох примерно для всего.

Загружать геометрию ченджсетов часто приходится команде по работе с данными в Mapbox. Для этого они сделали и постоянно улучшают сайт OSM Changeset Analyzer, где есть фильтры по любому атрибуту, вплоть до причины для подозрений. Но самые подозрительные пакеты накрывают весь мир, Achavi тут бессилен. Поэтому в этом месяце они сделали то, что давно было пора: кэширование ченджсетов.

Каждую минуту скрипт скачивает свежие дополненные диффы и складывает их в хранилище Amazon S3. Затем он раздербанивает эти диффы на пакеты правок и результат тоже загружает туда же. И теперь сервис визуализации Changeset Map, встроенный в OSMCHA, загружает пакеты мгновенно. Обновите ваши букмарклеты: Changeset (перетащите в закладки).

Проблемы, конечно, есть, но с ними борются. Например, дополненные диффы не окончательны из-за чехарды с транзакциями в базе данных OSM. Их приходится обновлять и обновлять. То же касается и пакетов правок, которые возможно держать открытыми целые сутки, понемногу доливая в них новые объекты. Наконец, история там только новейшая: пакеты старее марта этого года можно не найти. Их загружают, но медленно. Проблему поиска по региону архив тоже не решает, как показывает опыт фильтрации на сайте OSMCHA. Поэтому пользуйтесь им для просмотра недавних правок, а историю ищите на WhoDidIt и Achavi. Неидеально — но пока мы не избавились от концепции пакетов правок, ничего лучше не сделать.