Позднее Ctrl + ↑

Онлайн плюс офлайн

Через три месяца молчания блог OSMF оживили обычные оживляторы: рабочая группа конференции State of the Map. Следующая сходка осмеров пройдёт в Италии 19-21 августа, сразу перед FOSS4G там же. Вживую, на этот раз. Но вместе с тем, онлайн. Это будет мой первый опыт конференции, которая проходит одновременно тут и там.

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

  • большой экран с видеочатом, где люди в Италии машут руками остальным;
  • текстовый чат комментариев во время докладов — возможно, транслируемый прямо в зал, с большим QR-кодом в зале, чтобы все могли поучаствовать;
  • обычная тема с трансляцией хэштега из твитера;
  • видеотрансляция во время перерывов (самое сложное: как, вообще, транслируют видео с переносной камеры?);
  • полные доклады из записей мы не будем показывать, но короткие вполне подойдут, особенно если чередовать, чтобы следующий докладчик успел подключить ноутбук;
  • ещё было бы классно собрать у людей со всего мира видеоролики по пять-десять минут с улицы, чтобы крутить на экранах, и было ощущение, что мы не только в Италии;
  • нужно будет узнать, насколько сложно нанять стенографистов, чтобы текстовые трансляции не только были, но ещё чтобы их можно было пропускать через переводчик.

Короче, хочется переплести людей в итальянских залах и тех, кто смотрит за событием дома. Умные люди говорят, что сработает это только по принципу «remote first». Вот вы сейчас сидите за экраном. Представьте, что с другой стороны экрана идёт трёхдневная конференция. Как бы вам было интересно участвовать?

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

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

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

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

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

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

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

Перевыбрали

14 декабря 2019 года в IRC-канале #osmf-gm объявили итога голосования за правки в устав OSMF. Семь правок прошли с 83% и более голосов «за», одна — не прошла. 130 человек (33%) проголосовали против ограничения службы в Совете OSMF тремя сроками. Две других правки ввели более слабые ограничения: один срок теперь ограничен двумя годами (ранее мог длиться до четырёх), и нельзя выбираться четыре раза подряд.

Эту непрошедшую поправку Кристоф Хорманн назвал «законом Микеля». В 2019 году Микеля Мэрона выбрали в Совет OSMF в шестой раз. Вчера его перевыбрали в седьмой. Он отслужил 11 лет с одним перерывом в три года, и впереди у него ещё два года. Другими словами, Совет без Микеля у нас существовал только три года из четырнадцати.

Для сравнения, Фредерик Рамм и Хэнк Хофф отслужили по семь лет, Кейт Чепмэн и Пол Норман — по шесть, а Стив Кост и Оливер Кун — по пять. При этом я помню, как сетовали в кулуарах на Хэнка, который тормозил Совет, но при этом его стабильно переизбирали участники OSMF.

Проблема здесь именно в перевыборах. С 2010 года не было ни разу, чтобы член Совета пошёл на переизбрание и его не выбрали. «Борозды не испортит» — думали участники, и голосовали за тех же самых. Как в правительствах многих государств, знакомая история. Новые люди же не могут показать свои заслуги на подобных постах. Если ты был в Совете — значит, чем-то достоин, а если нет — поди убеди.

Год от года нам предлагают побороться за два-четыре освободившихся места в Совете. Это отличные цифры: в теории, треть состава обновляется каждый год, приходят новые люди с новыми опытом и идеями. На практике, как сетует Саймон Пул, мест меньше. Если учесть, что перевыборы всегда успешны, мест в этом году было не четыре, а одно. Лучше, чем в 2016 году, конечно, но неидеально.

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

На единственное свободное место выбрали Роланда Олбрихта. Мои поздравления! Люди смотрели на список из немцев и американцев и выбрали того, кто ближе к коду. Роланд десять лет сидит на одном проекте: Overpass API. Проект поистине волшебный, я не понимаю, как он настолько эффективен, и восхищаюсь им. Но что Роланд привнесёт в Совет, в котором уже есть Аманда из Geofabrik и Тобиас из EWG?

Можно понять, почему голосовали против Брайана Хаузела (бывшего автора iD) и Майкла Мигурски (автора Field Papers). Они оба прямо или косвенно работают на фейсбук. То, что эта компания делает в OSM, сомнительно — как и в других областях. Но, во-первых, я работал в больших корпорациях и знаю, насколько там боятся сделать в открытом проекте хоть что-то не так. А во-вторых, эти двое были нашим лучшим шансом вернуть Совет обратно в сообщество.

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

Если бы их выбрали (в идеале, обоих), то у нас было бы не автоматическое одобрение фейсбучных инициатив. А было бы заметное движение в сторону приятного сообщества — не только для технарей, которые считают, что в интернете нормально ругаться на знакомых и незнакомых like it’s 1999. Вы знаете таких людей — они есть и на нашем форуме, и в телеграм-группе. Они — проблема современных сообществ: умные и опытные, но отпугивают новичков.

Да, у нас есть подкомитет по модерации, прямое следствие того призыва (Майкл в нём состоит). Подкомитет работает, в прошлом месяце они отчитались перед Советом по внедрению модерации в рассылках. Но они ограничены традиционными каналами общения и не лезут туда, куда боится лезть и сам Совет: например, на гитхаб. Они пока не могут пожурить Совет как часть сообщества OpenStreetMap.

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

Что же такое Совет, по мнению участников OSMF? Похоже, награда за известность. Люди выбирают тех, о ком слышали, чтобы они посидели в каком-то непонятном формальном органе. Что делает Совет? Несмотря на супер-детальные отчёты Доротеи, всем пофиг. Совет никогда не воспринимали частью OpenStreetMap, поэтому противились любым изменениям — Совет научился работать тихо. «Направлять, не управлять» — девиз Совета, поэтому мапперы спокойны за схемы тегирования и модели данных, и делают выбор спустя рукава.

Но за последние четыре года Совет OSMF заметно изменился: стал опытнее, влиятельнее. Теперь ваши декабрьские решения имеют долгосрочные последствия. Важно донести это до осмеров. Важно сделать Совет частью сообщества OSM. То есть, чтобы он отвечал не только на формальные запросы длинными резолюциями, но вообще. «Почему ты удалил этот парк?», метафорически. Чтобы мы понимали, зачем он работает, а он понимал, зачем мапим, пишем и говорим мы.

Кажется, что набрав в Совет политиков и программистов, мы упустили этот момент. И именно поэтому хорошо было бы вчера отдать голос за тех, кто склонил бы интересы Совета в сторону сообщества. Тех, кто мог бы проложить мостик между Советом OSMF и всеми остальными в OpenStreetMap.

Миллиард

Аманда обратила внимание, что в субботу американский картограф залил в базу линию с круглым номером — 1 000 000 000.

Практического смысла в таких событиях нет, зато это повод отметить рост OpenStreetMap. Как в феврале можно было отпраздновать стамиллионный пакет правок, в апреле — точку 2³³, а скоро мы увидим десятимиллиардную точку.

Таких ошибок, как восемь лет назад, когда номера точек перевалили за 32-битный лимит, и многие приложения сломались, мы уже не допускаем. Или..? Что произойдёт через пару лет, когда номера линий тоже выйдут за 2³², требуя другого типа данных для их хранения? Когда чинили типы для точек, все ли попутно увеличили лимит для линий?

Некоторые готовятся уже сегодня. Например, Overpass API. В нём есть отдельный тип данных, area (области). Его идентификаторы генерируются из идентификатора линий или отношений, добавлением фиксированного очень большого числа. Но что выглядело большим десять лет назад, теперь пугающе близко к настоящим номерам. Для линий выделено окошко всего в 1,2 миллиарда значений. В следующем году нумерация area на замкнутых линиях в Overpass API начнёт пересекаться с областями на отношениях.

В версии 0.7.57 Overpass API, вышедшей в октябре, такая нумерация областей больше не поддерживается. Автор переписал обработку замкнутых линий, и теперь нужно пользоваться либо запросами на поиск области по названию и местоположению, либо кодом way(1234567); map_to_area;.

Хитрости с числами рано или поздно выходят боком. Вспомним проблему 2000 или даты в GPS. Хочется сказать: не делайте так. Но такие оптимизации помогают сделать алгоритмы быстрее и уменьшить их требования к памяти. Аккуратное отношение к типам данных помогло, например, когда-то запихнуть движок OSRM внутрь мобильного приложения MAPS.ME.

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

1 год   api   статистика
Ранее Ctrl + ↓

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