ШТОСМ: заметки с тегом проекты

Overture Maps расправил плечи

Илья Зверев — Tue, 20 Dec 2022 12:15:29 +0400

На этой неделе крупные компании из второго эшелона рынка пользовательских карт — TomTom, AWS, Microsoft, Meta — объявили о запуске фонда Overture Maps Foundation. В комментариях и статьях немедленно начали надеяться на победу над Google Maps и на хороший редактор, чтобы обклацывать тротуары и деревья во славу фейсбука. Кажется, нужно объяснить, что происходит.

Что это

Люди называют картой что угодно. Мы помним, что OSM — не карта, несмотря на «map» в названии. Приложения для отображения карт называют картами, объединяя их с тем, что они показывают. API для поиска и маршрутов — тоже. Нередко этот термин применяют к разным диаграммам или текстам, ведь есть же roadmap, неловко переводимый на русский как «дорожная карта». Наконец, подобно OSM, другие сборники геоданных, даже если там ничего не визуализировано, — тоже карты. Overture Maps — это не карта, а именно такой сборник.

Overture — это открытая инициатива по публикации открытых геоданных в едином формате с единым пространством идентификаторов и контролем ошибок.

Это определение вытекает из анонса Linux Foundation, в котором они очерчивают свои планы: совместно строить карту (которая на самом деле не карта), найти универсальную систему идентификаторов, настроить процесс контроля качества и задокументировать общую схему данных.

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

Можно сказать, что ноги Overture растут из проекта Daylight Map Distribution картографов из фейсбука. В нём публикуют проверенный и почищенный слепок планеты OpenStreetMap с дополнениями в формате osmChange. Можно при желании накатить на OSM домики от Microsoft или дороги от Facebook и Grab. То есть, вот контроль ошибок, вот открытость и вот единые идентификаторы: очевидно, домики не будут дублироваться в дополнениях.

Также другой популярный продукт Meta и Kaart — редактор RapiD — предлагает полуавтоматически импортировать большое количество наборов данных с хаба Esri. Они тоже адаптированы для нашей модели данных. И можно вспомнить ещё много других источников — например, преобразование POI и адресов в моём OSM Conflator — которые используют формат OSM XML для обмена информацией. Случайно мы получили экосистему.

Кто это

Проблема всей этой системы в том, что в её основе — OpenStreetMap. Миллион человек, с которыми невозможно договориться, и дурацкий формат данных. Фонд OSM — неподотчётные добровольцы, то же можно сказать и о Совете. Никто не знает, чего они хотят и какие у них планы. Никто не ждёт, что они сделают что-то полезное для кого-то, помимо редакторов (хотя и тем грустно). Вся система крайне антагонистична. Поэтому возник фонд Overture.

Overture Foundation — это консорциум из корпораций со шкурным интересом в пользовательской картографии, который определяет формат, состав и условия для открытых геоданных.

Такая организация назревала давно. Как сетует Майкл Мигурски, изменения через OSMF проходят годами, как и пул-реквесты в код сайта. Политика OSMF всегда была: «лучше отдельным проектом, чем на openstreetmap.org». Когда отдельные карты делали маргинальные группы, типа FOSM и CommonMap, сообщество смеялось. Теперь же, почему-то, нет.

Среди первоочередных задач — изобретение новой модели данных. По иронии, это ровно то, что наша инженерная рабочая группа поручила Йохену — который пришёл к выводу, что текущий формат не очень удобен для потребителей. В Meta с ним согласны. Проекту Overture не нужно думать о мапперах, поэтому их модель будет практичнее и проще — ближе к GeoPackage, чем к нашей топологической вермишели.

Лицензия уже известна: это CDLA Permissive 2.0: аналог MIT и CC-BY, требующим только указания источника. Почему не ODC-By от OKFN, подарившей нам ODbL? Думаю, из-за сложности последней: сравните их полные тексты. Восемь экранов против одного. Для использования в OSM дадут специальное разрешение. Разумеется, все данные, построенные на основе OSM, опубликуют под ODbL.

В чём угроза

Маловероятно, что Overture создадут свою «живую» базу геоданных, куда перебегут все картографы на зарплате, которые вносят заметную часть правок во многих странах. Это было бы удобно, но осмеры правы в том, что без сообщества добровольцев такой проект не имеет смысла.

Нет, Overture не конкурент OSM. Не конкурируют они и с Google: создать API для крупных компаний — плёвое дело, а вот получить данные для этого сложновато. Верьте заявлениям фонда: они действительно хотят сделать новую картооснову, доступную любому. Это честный и удобный проект, на который в ближайшие пять лет пересядут почти все пользователи геоданных, от сайтов недвижимости до Mapbox и Apple Maps. Мы уже пожинаем плоды межкорпоративного сотрудничества через импорты в RapiD. Скоро польза открытого обмена данными дойдёт до остальных.

Лицензия CDLA Permissive требует указания источника, и все будут её соблюдать, выводя название Overture. А по ссылке можно посмотреть, какие данные входят в эту базовую карту, и где-то там будет OpenStreetMap. Вот она, главная для нас проблема. Мы ныли, что Mapbox прячет атрибуцию под кнопкой, из-за чего все считали, что это их карты, а не наши. Теперь об OSM точно никто не узнает, потому что все будут использовать Overture Maps.

И с чего бы выводить OSM на первое место? Анонс обещает первые слои в Overture до лета. TomTom в ответной статье уточняет, что дороги предоставят они. Здания, очевидно, от Microsoft, административные границы — из Natural Earth. Всё под Permissive, потому что ничего от OpenStreetMap. Наши данные пригодятся на детальных масштабах, но не везде и не всем. Мы там только одни из.

Будущее OSM

Если вы получаете удовольствие от рисования карты, то не заметите никаких изменений. Новички по-прежнему будут ломать мультиполигоны и добавлять караван-сайты. Залётные сотрудники Apple и Kaart удивят выбором тегов для автодорог. DWG будет банить вандалов, а EWG будет оплачивать развитие проектов из позапрошлого десятилетия. OpenStreetMap будет свободным, и несколько чрезмерно активных участников будут пинать вебсайты, чтобы добавили атрибуцию.

Мы даже выигрываем в плане источников: раньше мы предлагали компаниям и государственным органам открыть данные для OpenStreetMap. Это влекло долгие обсуждения, зачем и почему. Теперь все будут открывать данные для солидного проекта с миллионами долларов финансирования и десятками разработчиков в штате, поддерживаемого всем известными компаниями из первых строчек рейтингов. И эти данные все будут в едином формате. Взять их для уточнения OSM будет элементарно.

За последние десять лет видимость OSM для обывателя выросла с нуля до постоянных упоминаний во всех технических блогах. Мы мечтали, что нашу работу увидит каждый — и вот, добились. Но тут подняла голову классическая проблема open source: спасибо вам за ваш код, мы с удовольствием сделаем его основой для всей нашей работы, до свидания. Лицом открытых геоданных станет Overture, а не OpenStreetMap. Денег в OSM не появилось, а теперь и известность уйдёт.

Очевидно, что проблема в OSMF. Большинство активных осмеров чувствовало, что что-то с Советом не так. После пришествия Аллана Мастарда он стал активнее, отчёты о его заседаниях создают ощущение бурной деятельности. Но это всё так же семь неоплачиваемых добровольцев, из которых больше половины — технари. Внутри сообщества, которое для них своё, они всё делают правильно. Но они не те люди, которые наладят и будут поддерживать контакты с высшими менеджерами крупных корпораций. Они говорят на разных языках.

Поэтому орган Advisory Board не работает. Совет не предупредили о фонде Overture Maps, несмотря на то, что половина его основателей состоит в этом органе. Не о чем тут говорить. С рабочими группами ещё можно вести какие-то дела, отдельных участников и местные сообщества приглашают к беседе, а польза Совета неясна. Запрос теперь будет идти в обратную сторону: OSMF попросится войти в фонд Overture на правах НКО, с участием в рабочих группах, но без права голоса. Это довольно странно, если не сказать, унизительно.

Собственно, от Overture нам ни тепло, ни холодно, но есть шанс, что случившийся разрыв в коммуникации заставит Совет — или толпу участников рассылки osmf-talk — начать эволюцию менеджмента OpenStreetMap. Подсмотреть ответы у Гуманитарной команды, у Викимедии. Составить стратегический план, собрать несколько сотрудников, в том числе управляющих менеджеров. И понять, наконец, что «защищать статус-кво» — не лучшая миссия для проекта, который когда-то сам его поменял.

Верни мне мой 2012

Илья Зверев — Mon, 12 Sep 2022 14:05:24 +0400

Для Великих Лук не было хороших спутниковых снимков, но мы примерно зарисовали дома на картовстрече

Ровно десять лет назад данные OpenStreetMap начали публиковать под лицензией Open Database License 1.0. Этому предшествовала длинная эпопея на весь 2012 год с поиском неподписавшихся под новыми условиями участия, слежением за карающим роботом, перекартированием потерянного. Всё это можно почитать в этом блоге по тегу odbl, не буду повторяться. Может, в комментариях старожилы вспомнят свои ощущения по этому поводу.

Новость же проста: на сайте 2012.osmz.ru можно сравнить, как выглядела наша карта в 2012 году и сейчас. Вместо снимков экрана удобнее будет пользоваться сайтом BigMap 2. На нём кнопка Enqueue сделает вам картинку из тайлов. Пользуйтесь тайлами 2012 года как угодно, но не мешайте другим зрителям. В конце октября сайт отключу.

С юбилеем ODbL-планеты!

Микромаппинг улиц

Илья Зверев — Thu, 27 Jan 2022 10:34:52 +0400

Photo by Dario Ayala /Montreal Gazette

Как вы знаете, линии highway в осме нужно нещадно резать. Изменилось количество полос? Остановка запрещена? Пунктирная разделительная сменилась сплошной? Появилась стрелочка «прямо или направо»? Началось место для парковки? Режем и расставляем теги.

Когда я год назад уточнял по панорамам улицы в своём районе, я быстро наткнулся на проблемы такого подхода. Например, parking:lane:*:capacity — количество мест. Звучит разумно, пока с другой стороны дороги не меняются полосы, и дорогу не нужно разбивать прямо по парковке. И пересчитывать capacity. А если на улице ещё есть велополоса, то микромаппинг становится совсем изнурительным.

Об этом в 2019 году писала Эмили из команды SharedStreets. Они занимались картированием условий вдоль тротуаров: разрешений на остановку и стоянку, мест для разгрузки, и тому подобного. В Северной Америке любят понаставить знаков — и наслаивающиеся теги ограничений на линиях улиц начинают угрожающе трещать. Страшно двигать точки, того и гляди, сломаешь.

Для решения предложили мапить ограничения косвенно, через знаки. Ставишь для знака точку со всеми нужными тегами, при желании связываешь с внешней базой. Когда приложению нужно узнать, что там с парковкой, оно проецирует эти точки на улицы и вычисляет применимые ограничения. Сразу понятна сторона улицы, и двигать геометрию не так страшно. Примерно так у нас картируют знаки «уступите дорогу»: недалеко от перекрёстка, чтобы было понятно, к чему относятся.

Увы, предложенный в статье тег никак не продвигали, и taginfo не может найти ни одного примера. Кто знает — идея разделить геометрию и атрибутику не так плоха. Может быть, мы бы и запреты обгона бы сейчас картировали через расположение знаков, а точек traffic_sign=city_limit хватило бы для неявного ограничения скорости в населённых пунктах.

Резать незачем

Год назад Алексу Сайделу (Supaplex030 в осме) понадобилось посчитать парковочные места в берлинском районе Нойкёльне. Для этого он разметил его весь (по снимкам, конечно) тегами parking:lane=*. Обработав данные в QGIS и посчитав отношение количества мест к зарегистрированным автомобилям, он сделал наглядную картинку. Для нас же важно то, как именно он рисовал эти места.

Он не отлавливал знаки на панорамах и не отмерял метры, чтобы поставить теги ровно на нужные отрезки дорог. Он не добавлял числа в capacity. Если посмотреть на район в OSM, удивляет, что свойства парковок стоят на целиковых отрезках от перекрёстка до перекрёстка. Алекс же в своём скрипте предобработки вырезает пять метров до перекрёстков, 15 м до автобусных остановок и прочие препятствия, а затем считает, сколько машин поместится с выбранным видом парковки (например, перпендикулярным).

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

Не остановиться

Почуствовав мощь предобработки и похожесть отрисованной карты на спутниковый снимок, Алекс продолжил. Как правильно показать велодорожки? Можно связать их с улицей через cycleway=lane и дополнительно описать в тегах bicycle:lanes и предложенном cycleway:separation. Несложно нарисовать стрелочки на полосах из значений turn:lanes.

Где этому предел? OpenStreetMap бесконечно глубок: можно мапить люки и уличные фонари. Автор выгреб из тегов и геометрии почти всё возможное. Особенно впечатлило, как он рисовал полосы вокруг островков безопасности: две линии проезжих частей превращал в один визуальный объект. А сам островок детально отрисовывал полигоном traffic_calming=island.

И это, конечно, микромапинг. Для нужного уровня детализации он оказался неизбежен. Всплыли и полигоны area:highway, которые не совсем про картографию. С их помощью отрисовываются стоп-линии на перекрёстках. А машинки вдоль дорог примыкают к поребрикам barrier=kerb. На эти линии предобработка полагается во многом — но, например, когда я вижу их в Москве, я вздыхаю и предпочитаю не смотреть. Ведь абсолютная практическая точность данных OSM не ниже полуметра и сопоставлять поребрики с другими объектами, часто нарисованными по разным источникам, больно.

Превосходство предобработки

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

Обработав OSM и наложив сверху немного местных открытых данных, Дастин Карлино сделал гениальный инструмент для дорожного планирования, симулятор трафика A/B Street. Машинки и велосипедисты ездят по правильным полосам, создают пробки, паркуются где надо. Даже и не скажешь, что это та же карта, что и у Mapbox, где одна линия на экране для дороги — уже достижение. Про A/B Street автор рассказал на SotM 2021, в том числе и про главную его проблему — отсутствие пользователей.

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

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

Natural Earth v5

Илья Зверев — Thu, 16 Dec 2021 10:54:06 +0400

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

На прошлой неделе вышла версия 5.0.0 этого набора. Это довольно примечательное событие: до этого три с половиной года данные не обновлялись. В моей ленте обновление прошло одним твитом — внимания этому уделяют не больше, чем выходу ядра linux 5.0, или LibreOffice 7.0. Базовая инфраструктура, работу выполняет, надёжно и просто.

В списке изменений сплошная рутина, если не считать долгожданной поддержки спорных территорий:

Добавили точки зрения на административные границы. Теперь можно скачать слой ne_10m_admin_0 таким, как его видят в России, Украине, Польше или Японии — всего 31 страна. Или воспользоваться полями fclass_* в общем слое.
Перевели названия на 26 языков (ранее было 21), включая украинский. Переводы подтягивают через викиданные, идентификаторы которых массово раставляют в таблицах.
Обновили все границы и населённые пункты, переименовали Северную Македонию и Эсватини, пару островов и аэропортов.
Добавили слои admin-2 с американскими counties.
Разбили Аральское море на три поменьше, уточнили геометрию ещё нескольких озёр и название Псковского озера.
Восстановили 136 озёр, которые потеряли в четвёртой версии и добавили слои с гидрографией Австралии.

Савёловские Мнёвники на Кушелевке под Семково

Илья Зверев — Wed, 03 Nov 2021 22:37:03 +0400

С этого дня поисковик Nominatim на главной osm.org по запросу «Савёловский» возвращает точно такие же результаты, как по «Савеловский», без «ё». Сара Хоффманн встроила в обработчик данных токенизатор ICU, благодаря которому взаимозаменяемые буквы можно заменять. Это требовало перезаливки данных в базу, которую приурочили к выходу Nominatim 4.0.0.

Действию, очевидному для любого, кто владеет русским языком, Nominatim просили научить с 2018 года. Было два способа: воспользоваться новым токенизатором, добавленным в PostgreSQL за пару месяцев до просьбы, или поправить таблицу автозамены в Nominatim. Последнее K Rahul Reddy сделал слишком поздно: его пул-реквест отклонили, потому что таблицу планировали убрать.

Русскоязычным сервисам было бы разумно забыть о номинатиме и воспользоваться альтернативными поисковыми движками: Pelias или Gazetteer. Не Photon — тот работает на данных Nominatim и пока различает эти буквы. К сожалению, размер имеет значение: несмотря на проблемы с поиском и сложный процесс установки, люди предпочитают пользоваться движками из списка Top 1.

В этом году разработка Nominatim набрала невиданную скорость: релизы выходили один за другим, а Саре постоянно находила что-то новое, о чём рассказать на конференциях или в блоге проекта. Причина — в деньгах. Движок останется открытым на 100%, но это не означает, что разработчики будут голодать. На сайте упомянуты несколько спонсоров — NLNet, OpenCage, GraphHopper, Komoot и другие. Судя по их количеству и по тому, что OSMF, чей грант запустил ускорение проекта, упомянут последним, денег там достаточно, чтобы Сара не занималась ничем другим. Это обнадёживает: может, скоро движок научится другим полезным эвристикам, типа учёта дефисов, пробелов и литер в номерах домов.

Помимо замены самопального токенизатора на стандартный ICU от ассоциации Unicode, в четвёртой версии убрали скрипты командной строки на PHP в пользу единого инструмента на Python. Этот инструмент помогает во всём, от подготовки базы данных до её обновления и администрирования. То есть, кажется, теперь не нужно устанавливать PHP для подготовки данных. В документации дописали большой раздел про настройку движка. И теперь можно подключить базу почтовых индексов для любой страны, а не только для США и Великобритании, как раньше.

Районный бот

Илья Зверев — Sat, 23 Jan 2021 20:38:20 +0400

Я живу в классическом районе новостроек: широкие проспекты или лес по краям, десятки высоток внутри, и всё в пешей доступности. Застройщик не знал меры с торговыми площадями: у нас три ТЦ и офисные помещения в подвалах почти каждого дома. Короче, столько магазинов и заведений вокруг, что запомнить невозможно, поэтому хочется нарисовать карту.

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

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

Поле ввода и ряд кнопок под ним — это всё, что есть. Нечего таскать, некуда кликать. Бот простой и умеет только отвечать на вопросы. Но знает многое:

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

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

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

Каждый вечер я возвращался домой и дописывал бота, чтобы переложить с себя на него все сложности. Вводить «https://» муторно — пусть бот сам превращает «Ttn. By» в «https://ttn.by». Не ждём точек с запятой и дефисов, позволяем пробелы и запятые. Вместо ввода номера дома предлагаем выбор из ближайших адресов. Ну и так далее: не нужно заставлять человека делать работу, с которой справится машина.

Так я собирал по 60-100 заведений в день, около 15 в час. Это включало в себя не только списывание данных, но и иногда разговоры с сотрудниками, которым я раздавал визитки бота. На районе около полутысячи заведений — знай я это заранее, дважды бы подумал, запуская проект. Но теперь он почти завершён, и я готовлю доклад на FOSDEM и приглашения для СМИ.

Уверен, эта новость вызовет три вопроса:

Кто будет обновлять данные, когда я съеду с Маяка Минска?

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

Где тут OpenStreetMap?

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

Как мне поднять такого же бота для своего района?

Самый главный вопрос! Бот опубликован на гитхабе, рядом с ним лежит огромная документация в пяти частях на русском языке. В ней я описал весь процесс, от обхода подъездов и установки бота до сбора заведений и администрирования. Если не считать русского языка, сообщения на котором разбросаны по коду, бот не привязан ни к каким атрибутам моего района. Хотите потратить неделю на обход каждого здания и потом поднять полезный сервис для всех соседей — буду рад помочь!

Приложение пилят — опенсорсные щепки летят. Пока готовил данные и писал бота, разочаровался в сложности базовых операций в вебе. Например, получить числа координат для прямоугольника можно на нескольких сайтах (например), и довольно удобно. А вот скопировать координаты одной точки — непросто. Специальные сайты писались семь-восемь лет назад и все сломались. А использовать для этого osm.org, где нужно открывать панель, ставить галочку, нажимать Ctrl+C... Линукс-версия телеграма не позволяет прикреплять координаты, поэтому пришлось писать свой сайт на замену. Очень простой: двигаешь карту, нажимаешь кнопку, вставляешь куда нужно.

Ещё я горжусь редактором точек в GeoJSON, которым пользуюсь для причёсывания базы заведений бота. Классические редакторы типа geojson.io, uMap, QGIS не катят: чтобы отредактировать точку, нужно ползать по таблицам, двигать мышкой, нажимать «сохранить». Здесь же всё супер-просто: двойной клик для создания точки, все свойства — простым текстом типа «name Название», по примеру Level0. Поэтому копипаст пачки атрибутов вообще не проблема. Есть фильтр а-ля поиск в JOSM, всё сохраняется автоматически и можно восстановить, если закроешь вкладку. Никаких меню и не больше шести кнопок на экране.

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

Mapillary in 2020 will now have stories

Илья Зверев — Sat, 20 Jun 2020 19:21:06 +0400

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

Vision of a Future

Илья Зверев — Fri, 03 May 2019 12:57:46 +0400

Вы наверняка знаете про Mapbox Vision SDK. Удивительная библиотека, которая прямо на устройстве прогоняет видео с телефонной камеры через нейронную сеть. Ищет в кадре машины, пешеходов и знаки, размечает кадр попиксельно, рисует на экране маршрут и напоминает об ограничениях. Продвинутый видеорегистратор. Видеоролик лучше любого описания: да, техника дошла, будущее уже в телефоне и почти не тормозит.

Его проблема в том, что он не нужен водителям. Несомненно, эта разработка на порядок интереснее самодвижущихся машин, которыми прожужжали все новости: такие машины купят несколько тысяч человек, а телефоны есть у миллионов водителей. Но авторы, как это часто бывает с технарями, для гениального ядра придумали яркий, но совершенно бесполезный обвес. Забыли одно из главных правил вождения: не отвлекаться. Все их линии и напоминания на практике не нужны.

Когда я за рулём, экран моего телефона выключен. Там работает навигатор и в правильные моменты он подсказывает: «поверните налево», «через триста метров направо». Никогда не удавалось оценить, сколько это — триста метров; порой приходилось резко тормозить и сдавать назад. Если прикрепить телефон к приборной панели, я начинаю его палить: контролировать скорость и время по GPS, смотреть на окрестности на карте. Читать уведомления из мессенджеров.

Поэтому AR, дополненная реальность, не нужна. Остальные части презентации тоже по-своему бесполезны. Предупреждения, например, либо избыточны и их игнорируешь — вспомните «динь» о превышении скорости в яндекс-картах, — либо редки и слишком неожиданны, чтобы вовремя среагировать. Картинки на сайте Vision SDK предлагают и третий вид уведомлений: слишком ярких и перегруженных, чтобы читать за рулём. Последний слайд в «Use Cases» особенно зловещ: внедрение системы приведёт к штрафам за то, что водители не роботы.

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

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

Главное в разработке — заткнуть внутреннего технаря и решать проблемы, а не предоставлять возможности. Например, не показывать, а говорить. Не «триста метров», а «перед забором». «Две минуты до съезда, перестройся вправо». Или «десять секунд», если машин вокруг мало. Это всё базовые улучшения, для которых не нужно камер. Vision SDK позволяет оценивать окружающую обстановку так, как не сможет никакой водитель, особенно усталый или в сумерках. «Впереди пешеход, притормози».

Обучение привычкам водителя, плюс данные с камер и автомобильных датчиков, плюс картография решат все затруднения, знакомые каждому водителю. Стоит ли разгоняться, или всё равно на светофоре стоять? Безопасно ли обгонять таз с прицепом, когда встречка далеко, но слепит фарами? Прервать обгон и встроиться между фурами? Быстрее ли соседняя полоса и точно ли там сейчас никого нет в слепой зоне? Сколько на этой дороге полос, не стоит ли принять чуть вправо? Тормозить или резко свернуть перед препятствием? Не влетит ли в меня обгоняющий, если я поверну налево?

Нужно не вываливать всё, что вычислили, а ненавязчиво подсказывать и, возможно, светить крупными, понятными индикаторами. Знаю, что превышаю скорость, но пора бы понять, что я люблю ездить плюс пять к ограничению, за которые не штрафуют. Если я в правой полосе, то зачем предлагать держаться правее? Линия маршрута нафиг не нужна, когда о повороте можно сказать голосом, а вот индикатор «можно обгонять» очень бы пригодился. Как и индикаторы безопасности перестроения на левом и правом боковых зеркалах.

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

Будущее вождения может быть построено на Vision SDK, если не произойдёт неминуемого. Я жду традиционного: Mapbox выпустит SDK и со временем переключит разработчиков на другие задачи. Несколько стартапов вырастут вокруг этой библиотеки и каждый запилит свою часть головоломки. Будут несколько приложений с платными подписками (потому что использование SDK стоит по доллару за человека), которые почти, но не совсем, помогают водителю, каждое по-своему. Пазл из них не сложится в идеального помощника. И в финале, как недавно нейронные сети для определения и маскировки лиц, технология обработки автомобильного видео станет ещё одним не взлетевшим технологическим прорывом.

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

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

Илья Зверев — Sat, 13 Oct 2018 13:17:27 +0400

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

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

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

Пакет не нужен

Илья Зверев — Thu, 27 Apr 2017 13:40:20 +0400

«Нельзя ли при отправке изменений из 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. Неидеально — но пока мы не избавились от концепции пакетов правок, ничего лучше не сделать.

Не только 64 бита

Илья Зверев — Mon, 13 Mar 2017 16:17:32 +0400

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

Атласы на выбор

Илья Зверев — Thu, 26 Jan 2017 01:47:44 +0400

Первые две ссылки на вики-странице про печать карт ведут на хорошо известные сервисы. Field Papers похорошел за прошлый год: регион для атласа выбирают теперь на полноэкранной карте, и не нужно думать над лишними настройками. Два клика, час ожидания (как можно так долго склеивать тайлы, не понимаю) — и pdf ваш. На нём традиционно расставлены точки и QR-код: исписанные листы можно отсканировать и загрузить подложкой в JOSM с помощью одноимённого плагина. Единственное, что стало хуже, — перевод. «Полевые материалы создан в Дизайн Stamen».

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

Свежий еженедельник OSM обратил внимание на альтернативный сайт MapOSMatic, который в мае поднял Хартмут Хольцгреф. С октября он залил в базу всю планету, и сайт затмил оригинал. Стилей на выбор там не два, как в исходном сервисе, а двенадцать, каждый их них в атласе выглядит лучше, чем склеенные тайлы. К сожалению, процесс создания атласа неочевиден: поиск работает через раз (зато позволяет атласы с непрямоугольными границами области), рисование прямоугольника пугает внезапными масштабированиями, в важных параметрах — размере бумаги, отображаемых сведениях — выбора почти нет. Зато ждать всего пару минут.

Всем привет

Илья Зверев — Sun, 27 Nov 2016 01:05:17 +0400

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

Список обновляется каждое утро. Увидели человека со словом «no» в колонке «welcomed» — жмите на него, и затем на кнопку «Welcome now». Там при нажатии Ctrl+C текст копируется в буфер обмена и открывается страница отправки сообщения с osm.org. Возможно, понадобится разрешить всплывающие окна в браузере. Вставляете текст в поле сообщения, при желании вырезаете строки со звёздочками из конца. Вторую строку, «добро пожаловать в OpenStreetMap», переносите в заголовок. И, возможно, убираете фамилию из приветствия, оставляя только имя. Всё, посылайте, закрывайте вкладку и жмите кнопку «I have sent this message» внизу страницы. Следующий!

Для эксперимента я отправил приветствие примерно тридцати мапперам, кто появился в пятницу. Планирую продолжить каждым утром будущей недели. Интересно, насколько это повысит вовлечённость пользователей maps.me или мою фрустрацию от странных вопросов новичков. Если новичок ответил — не забудьте записать это в его карточку на сайте. Также там есть кнопки для комментария («портит названия») и описания правок («добавил POI через maps.me»). Если кому-то не лень заполнить хотя бы описание, можно получить картину вклада новичков.

Всё на эмодзиях

Илья Зверев — Tue, 28 Jun 2016 21:09:12 +0400

Хорошие значки — один из признаков качественной карты, поэтому в Mapbox не довольствуются открытым набором SJJB, а сделали свой открытый набор Maki: 144 значка в public domain на гитхабе. Недавно компания написала обширный дизайн-док для тех, кто хочет дополнить набор значков, и открыла редактор оформления Maki. Теперь не нужно в Inkscape дорисовывать фон или перекрашивать методом изменения чисел в скрипте, достаточно выбрать параметры в веб-интерфейсе и нажать кнопку «скачать». Ещё бы такое для SJJB — вариантов Maki иногда не хватает.

Впрочем, у невзыскательных картографов, или которым хочется праздника, есть ещё вариант: воспользоваться общедоступным огромным наборов значков, который встроен прямо в систему. Emoji Map Мертена Пеетца удивляет не только яркостью при тёмном фоне, но и плотностью заведений.

Было-стало

Илья Зверев — Thu, 12 May 2016 20:44:18 +0400

То, чего так долго ждал любой участник, отдыхающий после обклацывания тысяч домиков, появилось благодаря гранту от Knight Foundation: теперь можно посмотреть и продемонстрировать родным, как за несколько дней изменилось количество домов и длина дорог в заданном регионе. Веб-сервис OSM Analytics очень прост и фокусируется на одной задаче: выбираете город, подгоняете контур и временные рамки и смотрите, сколько и где нарисовано. Информация обновляется ежедневно. Теперь не нужно поднимать собственные счётчики статистики для картовстреч: достаточно зайти на OSM Analytics и порадовать участников числами и скриншотами.

Из викимедии с любовью

Илья Зверев — Mon, 09 Nov 2015 00:24:47 +0400

Вот викимедия. Вот отдел связности внутри викимедии. Вот направление карт внутри отдела связности внутри викимедии. А вот Kartotherian со странным названьем, что в направлении карт создали, что внутри отдела связности, что внутри викимедии. Это движок карт, соединяющий инфраструктуру векторных тайлов Mapbox, сервисы викимедии, и добавляющий несколько полезных инструментов. Он работает уже несколько месяцев на maps.wikimedia.org.

Главный разработчик Kartoterian предложил, заодно, перевести на него и osm.org. Админы, разумеется, повторились, что рано или поздно все там будем, но давайте попридержим коней. А следующим выступил Кристоф Хорманн с общей критикой векторных тайлов: конечно, они быстрые, и позволяют бесплатные вариации стилей (например, для «ретины»), но прежде всего, векторные тайлы ограничивают дизайнера стилей. Он сослался на статью в своём блоге и заметил, что все карты на векторных тайлах нынче выглядят одинаково, без изюминки.

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

Одни и те же данные для разных стилей. Примеры — векторные тайлы Mapbox Streets, или что использует Энди Аллан для своих карт Thunderforest, две из которых есть на osm.org.
Разные форматы файлов для одной карты. Пример — Mapbox Vector Tiles, когда уже подготовленные и готовые к рендерингу данные сохраняются в отдельный файл, и затем на лету превращаются в растр. Не особо отличается от SVG, но и не слишком гибко. (Замечу, что я немного отстал от «паровоза», и настолько жёсткого формата, может, на самом деле нет).

Если разрезать на тайлы все данные, возникает куча проблем. Самая большая — потеря контекста. Нужны окружающие данные и наивысшая точность, т. е. в идеале — одна картинка на весь мир, сделанная из сырых данных. Для эффективности эту задачу упрощают: например, отрисовывают мир метатайлами, и делят данные на слои. Возникают граничные случаи, от чего, например, появились буферные зоны (по полтайла с каждой стороны метатайла). Так вот, в векторных тайлах после обработки остаются отдельные тайлы с буфером, и непонятно, например, куда ставить значки и подписи у больших или длинных объектов. Вместо того, чтобы решать самую сложную проблему картографии, векторные тайлы её усугубляют. Как с этим справиться, пока никто не знает, хотя Mapbox придумал пару обходных финтов, вроде предвычисления расположения подписей.

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

Поспорить с Юрием Астраханом, который с группой помощников разрабатывает Kartotherian, можно будет 21-22 ноября в Москве на конференции «Открытые ГИС».

Свобода выбора

Илья Зверев — Thu, 04 Sep 2014 14:34:20 +0400

Google открыл для России сервис «Map Maker», под впечатлением от которого Яндекс когда-то сделал НЯК. Учитывая запоздание, сложно понять, зачем, хотя возгласы «здорово» и «будем рисовать» под новостями лишают остатков надежды на светлое будущее OSM. Как поясняет менеджер сервиса карт в интервью Вестям.Хайтек, главная цель Map Maker — «дать людям инструмент, позволяющий добавлять информацию самостоятельно, <...> дополнить работу картографов, исправить их ошибки». Те, кто помнит косяки гугля с Рыбинским водохранилищем, Невским проспектом, дырявыми федеральными трассами, призрачными станциями метро, домами посреди проспектов и прочим, могут представить фронт работ перед народными картографами.

Кажется, развитие любительской картографии идёт в обратную сторону. Сначала был OpenStreetMap со сложной структурой и открытыми данными. Затем появился НЯК, где участников постоянно шлёпают по рукам, избегают серьёзных вопросов и не дают ни программистов, ни интерфейсов. Теперь GMM, который даже администрируют, как показал белорусский опыт, индиффирентные люди из Индии, которые умеют два ответа: «разбирайтесь сами» и «забаним». Но люди идут — почему? В то время, как OSM держится на двух столпах: геоданных и сообществе, — коммерческие альтернативы предпочитают заменить один или даже два из них громким названием (хотел добавить «и пиаром», но когда вы последний раз видели рекламу НЯК?). Взлетит ли GMM, где вы никто, ваши данные вам не отдадут, и единственная перспектива роста — стать модератором? Конечно, это же Google.

Хотя технически Map Maker похож на НЯК, его modus operandi существенно иной: участникам предлагают не создавать карту заново, а редактировать ту, что уже есть в Google Maps. То есть, открыв сайт проекта, вы можете получить сведения о любом отрезке любой дороги в России: ограничение скорости, количество полос, покрытие и его качество, ограничения проезда. Отредактированные или добавленные данные, следовательно, значительно проще интегрировать в основные карты. Это даёт участникам Map Maker то, чего тщетно добивались от Яндекса участники НЯК и сочувствующие: смысл работы.

Кстати, насчёт гуглокарт. Вместе с открытием Map Maker Google объявил о сотнях новых и обновлённых карт городов, немало из которых лежат за полярным кругом. Конечно, обрисовывать или таскать названия оттуда нельзя, но Стефан Кнаус нашёл остроумный способ выудить из их карт пользу. Он навеян английскими сайтами валидации по картам Ordnance Survey. Зачем срисовывать, когда можно просто сравнить? Сайт compare.osm-tools.org фильтрует данные OpenStreetMap и карту Google, оставляя только дороги, реки и озёра. И затем показывает разницу. Найдя недостающую дорогу или озеро, можно открыть редактор и дорисовать их по разрешённым снимкам (не забывайте про IRS сканэкса). Конечно, на крупных масштабах могут ошибочно отмечаться существующие в OSM дороги: точностью привязки коммерческие карты в России не блещут.

Новые печатные карты

Илья Зверев — Sat, 28 Jun 2014 14:57:59 +0400

Заявки на новые печатные карты мы ждем от вас в комментариях к посту про печатные карты, в котором указаны критерии для их создания... Секунду, у нас же не НЯК.

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

До сих пор просто нарисовать маршрут на карте было нетривиально: люди либо снимали проприетарную карту с линейкой вычисления расстояний, либо рисовали линии в пэинте поверх склеенных тайлов OSM, либо фотографировали OziExplorer с треком. Всё это ненормально и извращение. Особенно когда карта нужна для печати, и обычного разрешения в 90 точек на дюйм недостаточно. Что ж, с этого дня получить кусок карты для печати стало проще: теперь есть сервис «Get Veloroad».

Он работает на основе Nik4: указываете размеры бумаги, растягиваете прямоугольник границ печатаемой области, выбираете формат (png, svg или pdf) — и картинка в 300 dpi у вас в кармане. Поверх можно наложить GPX-трек и линейный масштаб. Векторные файлы SVG обрабатываются скриптом склейки букв в слова: их можно загрузить в Inkscape и сместить надписи от маршрута. Наконец, вместо стиля Veloroad можно выбрать «стандартный» стиль osm.org: хватит уже склеивать его тайлы, когда можно получить нужный кусок в 300 dpi (или в обычном разрешении, если указать пиксели).

Единственный недочёт — данные всё так же доступны только для части России и Прибалтики. Граница загруженной области отображена, поэтому даже на слое osm.org вы не останетесь неожиданно с синим квадратом. Сервис не даст создать несколько карт одновременно, поэтому если не получилось — попробуйте через пару минут. Всё лучше, чем вкладка экспорта на osm.org, непредсказуемая и вечно занятая.

Рецепт успеха

Илья Зверев — Tue, 10 Jun 2014 10:23:22 +0400

Adam Jordanek на своём сайте делает запрос к Overpass API, получает все кафе и рестораны (или другие точки, см. вкладку «Eat») и отображает их на карте. К каждой точке прикручена обсуждалка Disqus. Результат, конечно, не заменит форсквер, но очень удобен для поиска ближайших заведений: на форуме не замедлили похвалить.

Но подобные сайты можно слепить за день, и для непосвящённого посетителя они выглядят коряво. Чего уже не скажешь об отображении POI в openstreetmap.ru: две недели назад, вдохновившись новыми всплывающими панельками в 2ГИС, Felis Pimeja и ErshKUS улучшили дизайн наших: теперь карточки не выглядят набором тегов, переведённых на русский.

Инструментарий картопечатника

Илья Зверев — Thu, 29 May 2014 11:25:10 +0400

Как только я начал готовить печатный вариант карты маршрута на основе своего стиля, я обнаружил, что инструментов-то и нет. Вернее, есть, но не те. Например, подвинуть надпись в векторном изображении, выданном мапником, нетривиально: нужно выделить все буквы надписи, затем все элементы её полупрозрачного фона. Это нелёгкий процесс, с тщательным прицеливанием и нецензурными репликами, когда выделение теряется. Не двигать нельзя: алгоритм расстановки надписей в мапнике ужасен. Движок Cairo, используемый мапником, не позволяет объединять элементы слоёв в группы. Поэтому месяц назад я опубликовал скрипт mapnik-group-text, который объединяет буквы во фразы. Из параметров важен только -d, который определяет максимальное расстояние между буквами.

Затем мне понадобилось сделать выгрузки огромных территорий для OziExplorer (велосипедисты, почему-то, любят этот дорогой артефакт истории). Из существующих скриптов — только nik2img, который щеголяет несколькими десятками опций (но треть из них к делу не относится). Попробовал для проверки получить картинку как на osm.org, задав центр, масштаб и размер картинки в пикселях. Скрипт разочаровал: масштаб съехал на полделения. Как получить картинку в 300 dpi, вообще непонятно: при указании scale_factor лишь все линии зачем-то становятся толще. Что делать — пришлось писать самому.

Nik4 отрендерит вам мапником картинку именно так, как нужно. Без сюрпризов. Хотите эквивалент скриншота osm.org в нужной точке? Запускайте с параметрами -c LON LAT -x 800 600 -z 13. Распечатать прямоугольник в 300 dpi на листе A5? -a 5 --ppi 300 --bbox X1 Y1 X2 Y2 — и не нужно знать, что такое scale_factor, или какое там разрешение по умолчанию. Подготовить огромный фрагмент для Ozi? --tiles 4 склеит большую картинку из 16 маленьких (чтобы не вылететь по нехватке памяти), а --ozi output.map создаст файл привязки. Подробные примеры с картинками смотрите на гитхабе, а для установки достаточно набрать pip install nik4.

Первой задачей, с которой сталкиваются установившие мапник, остаётся генерация тайлов. Для этого я много лет назад написал скрипт polytiles.py, который не только делает эти тайлы в несколько потоков, но умеет собирать их в mbtiles и фильтровать как по файлу poly, так и по произвольному полигону в базе PostGIS (например, по городу). Недавно открылось ещё одно применение скрипта: им элементарно делать списки для renderd, чтобы обновлять тайлы в заданном регионе.