82 заметки с тегом

osm.org

Быстрее загружай

Возможно, вы заметили, что правки передаются на сервер быстрее. Или не заметили, потому что это не особенно тормозило и раньше. На прошлой неделе код сайта osm.org, Rails Port, отстранили от ещё одной части API: загрузки пакетов правок. Ваши пакеты теперь обрабатывает Cgimap.

Cgimap — это программа на C++, которая обрабатывает часть запросов к OSM API. Сайт написан на Ruby on Rails, поэтому каждый запрос к нему проходит через длинную цепочку обработчиков, не всегда оптимальную. Кроме того, передача данных от базы к клиенту в Rails требует много памяти и задействует сборщик мусора, который напрягает систему. Поэтому запрос /map на скачивание данных был переписан на C++ ещё в 2009 году.

Предполагается, что если появится API 0.7, то он целиком будет сделан внутри Cgimap. Мы давно хотим отвязать API от кода сайта, чтобы дневнички и интерактивная карта остались в Rails Port, а запросы к базе были отдельно. Но работа не кипит, скрипт обрабатывает лишь малую часть запросов. Сложным барьером была поддержка авторизации OAuth, но в 2016 году Мэтт Эймос, главный разработчик Cgimap, её сделал. В мае 2018 Mmd приступил и написал обработчик второго по количеству перекачиваемых данных запроса: /upload для отправки пакетов правок на сервер. Только в начале этого года у разработчиков дошли руки подчистить концы, отрефакторить и приступить к тестированию.

Второго марта бета-версию Cgimap 0.7.0 (это версия программы, не API) подключили к dev.osm.org, 28 марта тестирование закончилось и версию отправили в репозитории. Но у Тома, как водится, руки дошли подключить только после третьего напоминания. Пара дней ушла на настройку доступа к базе данных, и с 28 мая пакеты правок обрабатываются сервером быстрее, особенно большие. Поскольку это первый запрос, на котором Cgimap требует аутентификации, в ней нашлись несколько проблем, которые поправили в трёх версиях Cgimap за три дня.

7 июня   osm.org

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

Ровно десять лет назад проект перешёл на 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

«Этот пользователь является вандалом»

Вчера на нашем сайте появились многословные ссылки «сообщить об этой ...». Их можно найти у каждой статьи в дневнике и комментариев к ней, у пользователей и у заметок на карте. При нажатии вы получите форму жалобы модератору, где нужно оценить содержимое текста или профиля (спам, непристойности, угрозы). Со страницы заметки на карте можно пожаловаться на раскрытие личных данных, а у пользователя — пожаловаться на вандала. Жалоба попадёт в ленту, доступную модераторам сайта OSM, которые решат проблему.

Автором этого улучшения можно считать Энди Аллана, который работал над пул-реквестом с июля прошлого года. Но его история куда длиннее. Идея появилась в сентябре 2014 после очередной волны спама в дневничках. Том Хьюз тогда написал, что планирует добавить кнопку модерации к объектам сайта. Но ничего не произошло.

Далее, в 2015 году Shrey Bagroy предложил поработать на модерацией в рамках Google Summer of Code. Под руководством Серге Вроцлавского он программировал всё лето. Ветка была готова, но из-за каких-то разногласий Shrey не создал пул-реквест, ветка начала стареть, а студент, как водится, исчез сразу после получения денег.

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

Этот проект был в числе десяти важнейших задач, список которых в феврале этого года обновила рабочая группа по разработке. Теперь задач осталось девять. Среди них есть как технически простые, вроде списка комментариев к пакетам правок для пользователя, так и сложные, вроде типа area или наследника OWL. Если решитесь помочь сообществу, взявшись за одну из задач, то там же найдёте ссылки на работы на ту же тему и людей, к которым можно обратиться за помощью и руководством.

2018   osm.org

GDPR и мы

Регламент по защите данных GDPR обязывает юрлица, владеющие интернет-сервисами, получать согласие на обработку персональных данных, выдавать собранные данные субъекту и удалять их по первому требованию, и следить, чтобы данные обрабатывались только в соответствии с целями, которые подтверждены пользователем. Всё это работает уже два года, но через три недели включат санкции за неисполнение. А это, на минуточку, 20 млн евро или 4% от годового оборота, смотря что больше. Именно поэтому вы в апреле получили тонну почтовых уведомлений от твитера, гугля, фейсбука и других популярных сервисов.

Бдительные немцы начали обсуждать применимость регламента к OpenStreetMap ещё в марте прошлого года. Тогда на немецкой конференции внезапно всплыла тема приватности в контексте сайта «How Did You Contribute» Паскаля Найса. Мол, все эти пакеты правок и даты в открытом доступе — хорошо, но если их анализировать, можно вытащить слишком многое. Например, сайт Паскаля довольно точно отображает ваш район, часы активности и интересы. Из-за этого автор даже получал угрозы с требованием удалить личные данные.

Результатом стало требование залогиниться для просмотра профилей HDYC. Последовавшие споры в почтовой рассылке talk@ разбились о твёрдость немцев. Но спустя полгода Паскаль, всё-таки, позволил открывать свои профили.

Наступил апрель

Две недели назад Саймон Пул опубликовал 24-страничную резолюцию LWG по GDPR, результат полугода работы активистов OSMF с привлечением внешних консультантов. Зная принципы работы Совета, рекомендации юридической рабочей группы, скорее всего, будут приняты без изменений. Вот что советуют в техническом плане:

  • убрать метаданные из выгрузок данных (планеты), диффов и вывода OSM API для незарегистрированных пользователей;
  • под метаданными понимаются логин и числовой идентификатор пользователя, номер и атрибуты пакетов правок, и вероятно — метки времени у объектов;
  • сделать кнопку для полного удаления профиля (без геоданных) и предоставлять список удалённых пользователей сторонним обработчикам данных;
  • обновить и заставить пользователей подписать условия использования, ограничивающие способы обработки данных;
  • авторы сервисов, анализирующих данные, должны будут подписать договор с OSMF, либо самостоятельно разбираться с еврокомиссией.

Фредерик Рамм подготовил список изменений для каждого метода OSM API. Как видно, незарегистрированные пользователи не смогут получать информацию о пакетах правок, пользователях, заметках, GPS-треках и блокировках. Кроме того, придётся прикрутить авторизацию к сайту planet.osm.org, чтобы разделить его на две части: публичную с обрезанными данными и приватную с полным содержимым.

Запрос /map к OSM API традиционно используется для получения данных в заданной области. В 2016 году этот и другие запросы стало можно делать, передавая заголовки аутентификации: в этом случае не применятся ограничения по частоте запросов. После внедрения вышеупомянутых изменений разница будет более существенной, так как данные начнут разниться в зависимости от наличия аутентификации. Один из авторов Overpass API заметил, что сайт OpenStreetMap не передаёт эти заголовки при экспорте данных. Очевидно, похожие задачи придётся решать и авторам других веб-приложений для работы с данными OSM. Редактор iD уже готов.

Как готовятся другие

Роланд, автор Overpass API, бунтует: в мае прошлого года он написал заметку с фразами, апеллирующими к «1984» и «451°F»: мол, переписывание истории — это подрыв доверия к данным. Он считает, что пользователей с данными связывают только идентификаторы и логины: так давайте не прятать метаданные пакетов правок, а защищать пользователей. То есть, позволять им плодить сколько угодно новых user id, вручную или автоматически, чтобы размыть свой след в базе. Хотя едва ли это поможет тем 99% пользователей, которые не задумываются о приватности.

Сервис Overpass API работает без регистрации, и многие картографы пользуются им для редактирования карты. В будущем релизе 0.7.55 нет ограничений на метаданные.

Компания Geofabrik разделила свой сервер с выгрузками на два: для получения полных данных нужно зарегистрироваться на «osm-internal» и качать файлы из браузера, а на старом сервере пропали исторические дампы (*.osh.pbf) и вырезаны метаданные из обычных выгрузок. Там нет логинов и идентификаторов пользователей и пакетов правок, но метки времени сохранены. От этого файлы pbf похудели примерно на 10%.

Выгрузки от BBBike не содержат никаких метаданных, даже меток времени. «Идите на osm.org или заплатите 99 евро в месяц». Остальные сервисы регулярных выгрузок, включая французский, швейцарский или наш гис-лаб, не вносили никаких изменений в процесс: метаданные как были, так и остались.

Сервисы для анализа правок и поведения пользователей OpenStreetMap, не считая HDYC, всё ещё не требуют входа через OSM и не планируют сделать его обязательным. Как я понимаю, частных лиц регламент GDPR не касается, поэтому сервисы типа Who’s That, явно нарушающие приватность пользователей, не пострадают. Разве что придётся их подкрутить, чтобы скачивать диффы с сервера OSM под логином автора.

2018   osm.org   osmf   закон

Overpass кладёт в OSM

Этой ночью Мартин Райфер научил Overpass Turbo сохранять запросы не только в локальное хранилище браузера, но и прямо в OSM API, после авторизации. Вы увидите свои запросы на всех компьютерах и на любой копии сервиса.

Кажется, это второй случай использования Preferences API популярным приложением. Первым был редактор Merkaartor, который задействовал эти функции, когда версия API была ещё 0.5, и наткнулся на ограничение в 150 тегов. Потому что теги и настройки обрабатывались одним и тем же кодом. Были предложения сохранять настройки в OSM и другим редакторам — JOSM и iD, но забылись за отсутствием интереса.

Кроме ста пятидесяти настроек за раз, у API есть ещё ограничение: не больше 255 символов на строку. Длинные запросы Overpass Turbo сохраняет в несколько ключей и склеивает их при загрузке.

Наконец, API не решает задачу публикации кода запроса. Пусть сервис сам по себе — библиотека запросов с удобным интерфейсом, было бы здорово отвязаться от неё и загружать код в GitHub Gist вместе с коротким примером использования в Leaflet. Ровно как это делает Geojson.io при нажатии кнопки «Share».

2017   osm.org   overpass
Ранее Ctrl + ↓