В официальном блоге появилась невзрачная заметка: институт открытых данных спонсировал две управы в Великобритании, чтобы они посмотрели на OpenStreetMap. В рамках этой работы Ричард Фэйрхёрст подготовил документ, объясняющий основные вопросы проекта и подсказывающий способы интеграции данных.

Я прочитал все двадцать три страницы, и ребята, это он. Документ, каждая страница которого сочится пользой и правдой об OpenStreetMap. Каждые три страницы я порывался переключиться на вкладку штосма и начать восторгаться, но заставил себя досидеть до конца. Ричард не зря двадцать лет работает писателем: короткие абзацы по три-четыре строки исчерпывающе формулируют основные принципы нашего проекта, от «никакой организации в OSM нет» до «виртуальные объекты не мапим, но для административных границ делаем исключение, потому что это удобно».

Хватит объяснять каждой новой организации основы OpenStreetMap сызнова, теперь достаточно отослать им руководство Ричарда. Там есть всё, о чём можно подумать. Зовут в компанию рассказать про OSM? Берёте этот документ и нарезаете на слайды. Не нужно вспомнинать, не нужно вообще думать. Вопрос регулирования импортов закрыт. Осталось, наверное, написать всё то же самое на русском языке.

На прошлом 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 недель. Объявим о результатах, пожалуй, в новой теме, а не в обсуждении импорта.

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

Вы помните о проблеме 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 откатила правку. По техническим причинам, так как формальности были соблюдены и скоро, видимо, точки вернут.

Знаете, бывает иногда: договорились с какой-нибудь «Пятёрочкой», что они откроют данные для загрузки в OpenStreetMap, месяц пробирались сквозь бюрократию, получили заветный файл в формате CSV... И что? Допустим, сделали из него OSM XML и открыли в JOSM. Там восемь тысяч точек, которые нельзя просто взять и загрузить: в OpenStreetMap половина уже отмечена, часть — полигонами или отношениями, ещё минимум тысяча не подписана. Перелопачивать весь массив долго, монотонно и уныло. А на подходе уже «Магнит», который прознал про нашу лучшую в мире карту и готовит свои девять тысяч точек. И через месяц — обновление.

Пока в MAPS.ME обращались небольшие компании с сотней-другой точек, мы махали рукой и просили либо разобраться в OSM самостоятельно, либо подождать, пока кто-нибудь напишет скрипт. Но вы знаете основной принцип открытого проекта, так что теперь такой инструмент есть. Задачу из первого абзаца легко решит OSM Conflator.

Это скрипт на Python 3, который принимает профиль с настройками импорта и функцией подготовки данных. Он скачивает свежий набор, запрашивает у Overpass API подходящие объекты из OpenStreetMap и сопоставляет точки из обоих наборов. Геометрия из OSM считается эталонной, как и все теги, кроме заранее определённого набора (например, времени работы, которое поставщику данных лучше знать). Существующим объектам скрипт досыпает тегов, добавляет новые точки туда, где в OSM ничего нет, и выдаёт файл osmChange.

Дальше его можно напрямую загрузить в OpenStreetMap, но это нехорошо, противоречит руководству по импортам. Правильнее будет открыть файл в JOSM, проверить глазами, что ничего не сломалось и теги правильные, а затем выдать профиль и файл на обсуждение сообществу. Именно это я проделал со списоком паркоматов Москвы, полученных с портала открытых данных: до пятницы можно поискать ошибки в файле osc и профиле, после чего паркоматов в OSM станет на 765 больше.

Если не хочется импортировать, или владелец данных не дал явного разрешения, можно обойтись валидатором CupIvan. Он примерно так же сравнивает данные OSM и официального источника, но вместо загрузки выводит таблицу, где видны неправильные значения тегов, лишние и отсутствующие объекты. Исправлять приходится по одному объекту за раз, зато нет головной боли с обсуждением импорта в сообществе. Иван давно не обновляет валидатор, эстафету за последние три года перехватывали dndred, KoolRu и Avlaak. Последние два даже обновляют данные.

В сентябре 2013 года адресные точки и контуры зданий Нью-Йорка были выложены в public domain. Компания MapBox, большинство клиентов которой — американцы, немедленно взялась их импортировать в OpenStreetMap. Но поскольку они не французы и понимают, что нельзя просто взять и скопировать, процесс затянулся на год и затронул около 20 сотрудников. После десятков обсуждений, документирования, написания кода, обработки и постобработки данных, в Нью-Йорке появился миллион зданий и 900 тысяч адресных точек. Для сравнения, в России нарисовано всего 7 млн зданий. Алекс Барт рассказал об исходных данных, результатах и выводах. Исходные коды всех инструментов опубликованы на GitHub.

В похожей заметке блога MapBox Алекс поведал решение проблемы обновления исходного набора данных на сайте города. Наша лицензия не позволяет напрямую копировать обновления в базу под public domain, поэтому нью-йоркский отдел ГИС получает ежедневную сводку с изменениями в адресации и контурах домов в OSM. Увы, перевести наши данные под PD для упрощения транзакций у компании не получилось.

Этим летом команда переключилась на другие города США. В июле импортировали 150 тысяч домов в Сан-Франциско. Сейчас идёт импорт трёх миллионов домов в Лос-Анджелесе (фрагмент — на картинке выше, из твита Эрика Фишера). Также обнаружил, что Ian Dees в марте 2013 года импортировал 300 тысяч домов в Чикаго — правда, более простым способом, без лишних дискуссий.

В нашем сообществе никто, кроме отдельных программистов, не любит импорты. По разным причинам, но чаще всего — потому что они делаются тяп-ляп, и результат ни поправить, ни откатить. С 2008 года длинная инструкция в вики описывает, какие шаги должен пройти идеальный импорт. Правда, мало кто ей следует. MapBox же обещает соответствовать не только этим требованиям, но и собственным правилам, которые сводятся к одному: «мы уважаем сообщество и учитываем его на всех этапах импортирования». Кажется очевидным, но пойди найди какого-нибудь другого импортёра, который подпишется под таким. Мы уже рады, когда уважение к работе других участников OSM проявляют обычные мапперы, редактирующие карту вручную.