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.

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

С этого дня поисковик 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 для подготовки данных. В документации дописали большой раздел про настройку движка. И теперь можно подключить базу почтовых индексов для любой страны, а не только для США и Великобритании, как раньше.

Сегодня у сайта osm.org появился свой выделенный сервер для запросов к Overpass API. Он не публичный (и пожалуйста, не надо добавлять его себе в зеркала) и предназначен только для одного: поиска объектов вокруг заданной точки. Когда вы выбираете на сайте инструмент «Что здесь?» со стрелочкой и знаком вопроса и тыкаете в карту, сайт запрашивает список у Overpass API (потому что OSM API этого не умеет). Раньше это был сторонний сервер overpass-api.de, теперь — свой.

Эта новость порадует всех, кто пользуется инструментом «что здесь». Как узнать, что стало лучше? Тыкните в любое место три раза подряд. Из-за драконовских ограничений сервера раньше вы гарантированно получили бы ошибку: слишком много запросов. Теперь и на десятый клик сайт стабильно показывает объекты рядом и полигоны, содержащие заданное место. Видеть, как Overpass API работает без сбоев, умилительно: будто вернулся на пять лет назад.

Кажется, это была единственная часть сайта, которая работала нестабильно. После перехода с тайлового CDN (тридцать серверов которого так и стоят без дела) на Fastly ушли проблемы с медленными тайлами. Удивительно, но когда платишь людям за работу, эта работа оказывается сделанной хорошо. Построение маршрутов обеспечивают немецкий сервер OSRM (оплачен FOSSGIS) и немецкий же GraphHopper (витрина их бизнеса), оба стабильные. Чужие тайловые слои работают как часы, включая добавленные за пандемию французский велосипедный и немецкий общественного транспорта.

Но этот переход напоминает, что на самом деле стабильность стоит очень больших денег. Восьмиядерные серверы со ста гигабайтами памяти и терабайтом диска для Overpass API на дороге не валяются. Прокладка маршрута будет вам стоить от 50$ в месяц. Чуть меньше, если поднимете сервер на амазоне сами. Геокодирование платное. Тайлы платные. Кэширующий CDN тоже дорогой. А если хочется бесплатно и по-быстрому, то ограничения делают открытые сервисы бесполезными для публичных проектов.

OpenStreetMap — это открытые и бесплатные карты для каждого. Для каждого человека. Но когда нашими сервисами начинают пользоваться компании, оказывается, что стоимость этого пользования слишком велика. Раньше мы могли банить проблемных пользователей по-одиночке, но теперь их слишком много. Карты нужны всем. И либо ты строишь забор, который мешает и тем, кто растит в саду яблони, либо каждый день будешь видеть длинную очередь людей в костюмах и с пустыми мешками.

В начале мая Ньёлл Доусон показал, что свежий QGIS при выборе системы координат EPSG:4326 (или любой другой, основанной на датуме WGS-84, включая 3857) предупреждает: эта СК опасна для точности ваших данных.

*я иногда путаю датум (параметры эллипсоида, как WGS-84), системы координат (как на этот эллипсоид натянуты широта и долгота, как 4326) и проекции (отображение эллипсоида на плоскость, как 3857).

Неужели всё настолько плохо, что WGS-84 нужно отменить? Напомню, эта система координат используется почти везде: в GeoJSON, в приёмниках GPS, в данных OpenStreetMap. Мы рисуем в этой системе поребрики и балконы на домах, пользуясь пучками GPS-треков и RTK для достижения сантиметровой точности.

Проблема в том, как позже разъяснил Ньёлл и ранее — этот отчёт 2019 года, что местные (статические) СК привязаны к земле, а глобальные (динамические) — к общим параметрам земного шара. Австралия, например, медленно плывёт: с 1994 года она сместилась на 1,8 метра на северо-восток. Динамичность WGS-84 означает, что то, что единожны нарисовано в СК на её основе, каждый год нужно сдвигать.

В качестве местных в Австралии используются «слепки» WGS-84: система координат GDA94 была определена в 94 году как «эквивалентная WGS-84». А GDA2020 в прошлом году определили точно так же. Получается, можно преобразовать координаты без пересчитывания GDA94 → WGS-84 → GDA2020 и получить ответ, отличный от преобразования GDA94 → GDA2020.

Земная кора двигается и под остальными континентами, пусть и с меньшей скоростью. WGS-84 — динамическая СК: чтобы точно отражать физические координаты, к широте и долготе в ней нужно добавлять время наблюдений. Иначе, как пишет ИКАО в разделе 3.3.1 инструкции по WGS-84, даже учитывая теоретическую сантиметровую точность GPS-приёмников, точность данных в этой СК не превышает одного метра по горизонтали. То есть, пять знаков после запятой — предел точности для широты и долготы в WGS-84.

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

GeoJSON и KML неисправимы, шейпфайлы и PostGIS тоже, соответствующее поле WKT CRS не поддерживает даже Proj 8. А вот в OpenStreetMap... формально, все объекты имеют дату создания, которую с натяжкой можно считать нужной меткой времени. Но кто в здравом уме использует OSM как формат для обмена геоданными? А при конвертации информация о времени теряется.

Обойти эту проблему легко: используйте местные, или хотя бы статические, системы координат. GDA2020 (EPSG:7844) для Австралии, ETRS89 (EPSG:4258) для Европы, ГСК-2011 (EPSG:7683) для России. Но скорее всего (ролик с ржущим фермером) у вас нет таких вариантов, и остаётся ждать, когда боги геоджейсона придумают решение. Глобальных СК лучше 4236 нет, поэтому последний QGIS 3.10 по умолчанию всё ещё предлагает эту систему для новых проектов.