На прошлом State of the Map US сотрудники Facebook рассказали о том, как они натравили алгоритмы машинного обучения на спутниковые снимки, чтобы найти на них дороги. Затем люди проверяют эти дороги и склеивают их с данными OpenStreetMap. Поразительно по двум причинам: Facebook дорисовывает OSM! И скоро никому не нужно будет обклацывать спутниковые снимки!

Правки сотрудников фейсбука начали появляться в Египте и Таиланде и их, конечно, быстро удалили. Как это обычно бывает с автоматическими массовыми правками: вместо улучшения геометрии удаляли нарисованное и заливали заново, причём с косяками (оставались узлы); качество было сомнительным, особенно на дефектах снимков, которые определялись как дороги; классы дорог очищали и тегировали всё как residential. Причём это началось ещё в мае, последующие попытки мы замечали в июле и августе. Откатили почти всё, фейсбук затаился.

В феврале тайские мапперы нашли страницу в вики, которая документирует процесс автоматического распознавания дорог фейсбуком. Неужели они решили соблюсти инструкцию по импорту и автоматическим правкам? Увы: на форуме быстро заметили, что сотрудники компании продолжают портить данные в Таиланде. Способы разнообразны и всегда печальны, тема читается как история неудач, «33 несчастья» по-осмерски. В субботу осмеры и фейсбуковцы в Таиланде встретились за чашкой чая и договорились об открытости процесса.

Иллюстрации из письма Facebook в рассылку imports@.

Главное, впрочем, в мелочах: немногие, кто возмущался новой попыткой фейсбука импортировать нам дороги, прочитали их вики-страницу до конца. Во-первых, фейсбук классифицирует снимки DigitalGlobe. Но не те обрезки, что доступны нам из Bing и Mapbox, а улучшенное покрытие +Vivid без облаков и стыков. А в конце они приводят разрешение DG на импорт производных от снимков данных в OSM и ссылки на тайлы с классифицированными дорогами, которые можно сравнить со спутниковой подложкой, где она есть.

Осмеры, конечно, спросили: а нельзя ли нам заодно и исходные спутниковые снимки? Вы знаете, как оно бывает: спросили, вместе посмеялись, вздохнули и разошлись. Но не в этот раз: Кевин Баллок из DigitalGlobe 16 марта ответил:

Рад сообщить, что мы приближаемся к отличному решению, которое позволит DG опубликовать спутниковый слой специально для трассировки в OpenStreetMap. Эту работу спонсируют несколько организаций, и она сделает слой +Vivid доступным для зарегистрированных редакторов OSM. Надеюсь, это позволит вам проверить импорт команды Facebook. Срок — примерно 4-8 недель. Объявим о результатах, пожалуй, в новой теме, а не в обсуждении импорта.

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

Шейдеры с отражениями для OSM2World сделал Зак Андерсон в рамках GSoC 2016

Ближайший важный дедлайн — это закрытие приёма заявок на доклады для State of the Map в Японии, второго апреля. Учитывая дороговизну полётов, билеты на самолёт и гостиницу лучше забронировать тоже до этого времени. Третьего же апреля другой дедлайн: для студентов-участников Google Summer of Code.

Проект OpenStreetMap участвует в GSoC в том или ином качестве с 2006 года. За это время студенты сделали немало заметных улучшений — правда, всё чаще в сопутствующих программах. Например, «испортили» картостиль или провели крупный рефакторинг ядра JOSM. Честно говоря, в списке законченных проектов я нашёл не устаревшие только с 2012 года, когда Ян плотно поработал над функциональностью редактора Vespucci. Но с каждым годом мы всё успешнее наставляем студентов, и их работа всё заметнее. Как редактор полосности дорог в iD, автора которого быстро замели в Mapbox.

Так что участие в Google Summer of Code не только помогает финансово (хотя в этом году доход будет чуть меньше прежних пяти тысяч долларов), но и ставит студента под прицел крупных компаний вроде Mapbox и Carto. Будьте осторожны — и выбирайте: в списке идей для проектов за двадцать предложений. Если вы осмер, то у вас, наверное, есть и свои. Напишите о своём желании в почтовую рассылку dev@ и до понедельника успейте составить формальную заявку для сайта GSoC 2017.

Если вы не студент, то айда в менторы. Почувствуете себя учителем, поможете студенту быстрее понять OpenStreetMap и направите его разработку в полезное русло. Всё, что нужно, — пара обязательных часов в неделю и письмо Петеру Барту с информацией о себе и своим e-mail. Координацией менторов в этом году занимается не он один, а целая рабочая группа EWG. Мы возродили её из пепла разработчиков и не допустим в ней прежних ошибок, то есть, разработки. Теперь EWG занимается исключительно управлением и координацией, помощью владельцам проектов и начинающим разработчикам. Во вторник в 23:00 по Москве её члены в третий раз созвонятся в Mumble, чтобы обсудить две насущные задачи: GSoC и список Top Ten Tasks.

Недавно картинкой недели в вики выбрали скриншот коллекции OSMvis, где собраны визуализации данных OpenStreetMap и нашей вики. Все их создал Франц-Бенджамин Мокник, постдок на той же кафедре гейдельбергского университета, откуда вышли MapSurfer и OpenRouteService.

Этот сайт напомнил мне про See, also: тоже коллекцию визуализаций, но по данным википедии. Как и полагается более старому и более популярному проекту, в этой коллекции на порядок больше ссылок, но и авторы разные. Если посмотреть на темы работ в обеих коллекциях, налицо одно важное отличие.

Предметом визуализаций по OpenStreetMap почти всегда является OSM. А то и не почти. Распределение тегов, распределение правок, плотность данных, белые пятна, реки, «как мы хорошо помапили Африку». Все популярные в сообществе визуализации — а это и ResultMaps Паскаля, и видеоистории правок, и ITO Map, — сделаны только для осмеров. В See, also часто визуализируют не саму википедию, а содержание статей. Например, популярность музыкальных жанров в разные годы или распределение некрологов по полам.

Встречаются красивые картинки на основе OSM: Sorted Cities, Interchange Choreography, Roads to Rome, Smelly Maps. Почти все они сделаны дизайнерами «со стороны», упомянуты в одном твите или картинке в OSM и забыты. «Прикольно, но не про нас».

Города, заканчивающиеся на -ск* (темнее — больше доля): визуализация Places!

Мы много говорим о пользе OpenStreetMap и постоянно чувствуем тягу к картам. Хотя не каждый сможет описать, чем так хорошо рисование или просмотр карт. Это же не только поиск маршрута к магазину и не только обклацывание домиков для координации гуманитарной помощи. Хорошая карта не только точно отражает состояние местности. Но и даёт лучше понять окружающий мир, показывает неожиданные закономерности в сетке улиц или парков вокруг твоего дома. Карта может быть книгой, вчитываясь в которую узнаёшь об истории, геометрии, градостроительстве, дизайне, лингвистике, о привычках и обычаях жителей. Можешь увидеть схожесть и различия в жизни своего города и европейского, и даже между своим и соседним кварталами.

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

Вы помните о проблеме 2013 года, когда идентификаторы узлов в OpenStreetMap превысили 2³¹. Те, кто держит регулярно обновляемый сервер тайлов, вчера вечером могли заметить ошибку в логе osm2pgsql:

Osm2pgsql failed due to ERROR: insert_rel failed: ERROR: value «37945» is out of range for type smallint

Да, программа не ожидала, что на хранение количества членов отношения может не хватить двух байтов. Чтобы восстановить обновление, нужно откатить состояние до этого state.txt и убедиться, что osmosis скачивает диффов минимум на два часа. На гитхабе разработчики osm2pgsql обсуждают, как и где лучше ограничить размеры отношений.

Откуда взялось такое большое отношение? Это, слава богу, не мультиполигон. В Бразилии кто-то решил импортировать геодезические сети: 7700 точек плановой сети (для определения координат) и 38 тысяч — высотной (для определения высот). Не очень понятно, зачем в OSM последние: снимки по ним не привяжешь, а ЦМР по осму нормальные люди не корректируют. Но обсуждение импорта в почтовой рассылке не завязалось, а бразильскую группу в телеграме, куда сбежали осмеры, читать сложно.

Проблема оказалась в том, что все импортированные точки люди решили объединить в отношения. В вики с 2008 года предупреждают: отношения — не категории, не создавайте их для облегчения выкачивания данных. Есть же Overpass API, есть osmfilter. «Но мне же надо» — и получилось отношение из 38 тысяч точек. В течение пары минут после его загрузки у многих обвалился osm2pgsql и через полтора часа DWG откатила правку. По техническим причинам, так как формальности были соблюдены и скоро, видимо, точки вернут.

Мультиполигон — это отношение с тегом type=multipolygon, содержащее линии в ролях inner и outer, образующие один или несколько замкнутых контуров. Их используют, чтобы нарисовать полигон с дыркой (например, дом со двором-колодцем) или не рисовать смежные полигоны по одним и тем же точкам. В принципе, если взять любой обычный полигон и навесить на него отношение с тегом type, он превратится в мультиполигон. Но так делать не стоит.

Если поставить теги на внешний контур, а не на отношение, такой мультиполигон будет считаться нарисованным в «старом стиле». Рендерер или osm2pgsql должны будут просмотреть все линии с ролью outer, убедиться, что теги совпадают, и использовать их для отрисовки. Теги на линиях внутренних контуров относятся к содержимому дырок, хотя иногда там можно встретить те же теги, что на внешнем контуре. Обрабатывать старые мультиполигоны сложно и долго.

«Новый» стиль тегирования мультиполигонов — это когда все теги на отношении. Что там висит на линиях контура — не важно. Рендерер сразу видит, что к чему, и не обязан просматривать каждый член отношения. Мультиполигоны в новом стиле нравятся всем, поэтому технари ратуют за истребление старых. Нужно перетегировать «всего» около 250 тысяч отношений, из 13 миллионов.

Йохен Топф предлагает делать это по ходу исправления сотен тысяч более важных ошибок в полигонах и мультиполигонах. К этому можно было приступить и раньше, взяв в помощь OSM Inspector, но планомерное истребление — не для всех. Иногда проще не видеть фронт работ, исправляя по ошибке за раз и имея выбор: нажать «следующая» или закрыть вкладку браузера. То есть, пойти в MapRoulette.

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