ШТОСМ

Vision of a Future

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

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

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

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

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

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

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

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

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

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

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

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

Ничей OSRM

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

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

Не удивительно, что спустя год его автора, Денниса Люксена, завербовали в Mapbox — сразу после защиты диплома в университете Карлсруэ. В то время это было позитивной новостью: OSRM не откладывался на полку отработанных дипломных проектов, как это случилось, например, с MapSurfer, а получал поддержку деньгами и коллегами от крупной компании. С тех пор OSRM становился всё умнее, получая полезные на практике функции, вроде улучшенных пошаговых инструкций, поддержки полос и restriction:conditional.

Всё поменялось в январе 2018 года. Именно тогда Mapzen объявил о закрытии всех своих сервисов, включая движок роутинга Valhalla. Его особенностью была разбивка данных по тайлам, что предположительно помогало обновлять данные и загружать их в память фрагментами. В то время (да и в это) векторные тайлы захватили воображение руководства Mapbox, поэтому не очень удивляет, что всего через три дня все пять разработчиков присоединились к компании. Спустя месяц Valhalla уже строила маршруты по пробкам на сотнях серверов Mapbox.

А что OSRM? В апреле 2018 активность главного репозитория проекта внезапно снизилась на два порядка: с двадцати коммитов в день до пары коммитов в неделю. Деннис ушёл ещё в начале 2015. Часть разработчиков перевели на другие проекты, но большинство, судя по слухам и активности на GitHub, просто уволили. Из верхних десяти участников проекта (одиннадцатый — Лев из Juno) активность после того апреля проявлял только сотрудник Mapbox Дэниел Паттерсон. Да и то — он лишь проверял и принимал пул-реквесты от пользователей библиотеки, не тратя много времени на разработку. По косвенным признакам ощущалось, что изменения даже не тестировались как следует.

«Линия жизни» репозитория, график коммитов, дважды за последний год прерывалась на месяц: в августе и в декабре. Когда я залил очередной несложный пул-реквест, я ожидал, что нынешний перерыв тоже скоро закончится. Но с последней правки кода прошло уже больше двух месяцев. Дэниела, судя по строчкам вида «42 contributions in private repositories», загрузили работой в Mapbox, и OSRM остался без мейнтейнера. Некому даже нажимать на кнопку принятия пул-реквестов. Другими словами, проект мёртв.

Почему так получилось? У всех всё работает. OSRM как-то страхует Valhalla на серверах Mapbox, но в нём ничего не изменится, потому что вся работа теперь в векторных тайлах. Maps.Me, который когда-то удивил работой движка на смартфонах, пару лет как выкорчевал OSRM из кода, заменив своей, более гибкой навигацией. Для публичных серверов, типа недавно добавленного на глагне роутинга от немецкого FOSSGIS, достаточно старых версий. Вероятно, OSRM просто исчерпал возможности для развития, а отсутствие даже теоретической возможности поддержать различные профили, пробки и прочие динамические ограничения толкают корпоративных пользователей к разработке альтернативных решений. Если энтузиастов не найдётся и среди сообщества OpenStreetMap, проекту крышка.

Не сказать, что это плохо: GraphHopper ещё жив. Разработка движка Valhalla, разумеется, очень активна, но как и другие проекты Mapbox, поднять его на своём сервере будет непросто. А в недрах Гейдельбергского университета Амандус Бутцер и Тим Макколи растят достойную смену: OpenRouteService.

30 апреля   роутинг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему?

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

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

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

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

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

22 апреля   osm.org

Что произойдёт завтра с GPS?

Короткий ответ — ничего.

Вы уже слышали эту историю: приёмники хранят номер недели в десятибитном поле, и раз в двадцать лет оно переполняется. Завтра те устройства, которые давно не обновлялись, могут начать party like it’s 1999. Ошибка не повлияет на позиционирование, потому что внутренние вычисления всегда консистентны. Секунды и минуты тоже будут правильны. Сломаться могут только метки дня, месяца и года.

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

Пользовательские навигаторы, которые могут быть обновлены, уже обновлены. Обычное решение — запрограммировать дату отсечки: например, если год внезапно получается меньше 2015, то прибавить двадцать лет. Многие так и латают дыру: очевидно, этот способ только отсрочивает ошибку, что и сломало даты в некоторых навигаторах в 2016-2017 годах.

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

Трёх других спутниковых систем — ГЛОНАСС, BeiDou и Galileo — проблема не касается. Всю информацию я вытащил из этой презентации 2017 года для американского совета по позиционированию и замерам времени, и из позавчерашней статьи в Nature.

5 апреля   навигаторы

Конференций псто

В этом году нас ждут много конференций про OpenStreetMap и картографии в целом. Готовиться к ним нужно заранее. Эти конференции сейчас ждут от вас заявок на доклады, и негоже их разочаровывать. Пройдите по списку и порадуйте организаторов каждой:

  • State of the Map 2019 в Гейдельберге 21-23 сентября: главная конференция нашего проекта снова рядом, в Западной Европе — грех не съездить. Присылайте доклады до 25 апреля. Лучше раньше.
  • HOT Summit 2019 там же 19-20 сентября: главная конференция Гуманитарной команды выросла до двух дней, прикрепилась к SotM как три года назад в Брюсселе, и тоже ждёт ваших историй, включая «5-minute failures». Срок — до 30 апреля.
  • FOSS4G 2019 в Бухаресте 26-30 августа: самая главная ГИС-конференция с недешёвым входным билетом (330 евро без мастер-классов) и количеством треков как на Московском вокзале. Присылайте заявки до 15 апреля и потом помогайте выбрать триста достойнейших.
  • State of the Map US 2019 в Миннеаполисе 5-8 сентября: крупнейшая региональная конференция про OSM уютненько втиснулась между международными. Если можете позволить себе билет в город на полпути из Чикаго в Фарго, заявляйте доклад до 1 июня и ждите тёплого приёма.
  • State of the Map France 2019 в Монпелье 14-16 июня: прибрежный французский город недалеко от Марселя в середине лета — сам по себе хороший повод для поездки, а если вы знаете язык, то встретиться с местными осмерами сам Кост велел. Вписывайтесь в докладчики до 15 апреля и готовьте купальник.
  • State of the Map Africa 2019 в Гран-Басаме, Кот-д’Ивуар 22-24 ноября: доклады они пока не собирают, но язык ожидается французский, океан тоже рядом, так что это неплохое продолжение французской осмерской конференции. Фоточку и новостные каналы смотрите в вики.
  • OSCAL 2019 в Тиране, Албания 18-19 мая: ежегодная конференция касается всего открытого, и докладам про OSM они тоже будут рады. Тема этого года — этика в технологиях.
  • «Цифровые геотехнологии» 20 апреля (суббота) в Петербурге: очередная регулярная встреча любителей картографии, каждая из которых имела свою направленность. В этом месяце обсудят открытые ДЗЗ: если у вас есть мысль доклада, зарегистрируйте её на сайте.

Кроме того, прямо завтра в Москве, в четверг в 19:00 сотрудники «Урбики» бесплатно расскажут про дизайн картографических сервисов — скорее записывайтесь, таких знаний вы больше нигде не найдёте. И 16 апреля команда NextGIS покажет, что они нового придумали за полтора года с прошлого их Demo Day: регистрируйтесь и готовьтесь удивляться.

3 апреля   конференции
Ранее Ctrl + ↓