20 заметок с тегом

id

Позднее Ctrl + ↑

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

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

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

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

Внезапные панорамы

Месяц назад в репозитории редактора iD неожиданно появился пул-реквест от Джубала Харпстера. В описании он был лаконичен: «интегрирует снимки StreetSide в редактор. На здоровье. —Микрософт». «Но их же нельзя использовать», — сразу ответил Пол Норман.

Мало кто в восточном полушарии знает, что панорамы есть не только у Google, Яндекса и Baidu. Список подобных сервисов в википедии очень длинный, но в разделе всемирного покрытия пока только две компании с проприетарными панорамами. Вторая — это Microsoft Bing. Их StreetSide запущен в 2009 году и покрывает большую часть Соединённых Штатов и крупные города в Великобритании, Франции и Испании. Вы не увидите эти снимки: «Вид с улицы» доступен только жителям городов внутри области покрытия.

Смотрители проекта iD не так въедливы, как у сайта OSM. Брайан просмотрел на эти семь коммитов от Шоны Паради и Лорена Мюллера, нашёл несколько недочётов и то ли помог их исправить, то ли отредактировал код сам — интерфейс гитхаба не дал понять. Так или иначе, неделю назад запрос был принят, и 14 июня выпущена новая версия редактора с панелью StreetSide. Включается она там же, где Mapillary и OpenStreetCam: кнопкой данных карты, справа под кнопкой слоёв.

Что касается лицензии, Пол немного опоздал с заявлением. Как обнаружил Майкл Райхерт, ещё в апреле Микрософт обновил условия использования своих сервисов, явно разрешив подсматривать в StreetSide для уточнения данных. Немцам, впрочем, от этого мало пользы: их соотечественники успешно отразили все попытки Bing Maps отснять их территорию.

Разумеется, разрешение касается не только редактора iD. В том же пул-реквесте Джубал ответил на несколько вопросов насчёт лицензии, подтвердив, что панорамы можно использовать и в настольных редакторах. Несложно найти код модуля для JOSM, на которым последние несколько дней работает Рене Роудс. Полноценной поддержки придётся подождать в обоих редакторах: вон, в модуле для iD уже нашли ошибку при масштабировании снимка.

Как сотрудники Bing Maps напоминают в пресс-релизе, это не первый их подарок сообществу открытых карт. Каждый пользовался снимками Bing для обклацывания домиков и дорог. Из недавнего, год назад они предоставили OpenStreetMap десять миллионов геометрий зданий в 44 штатах Америки вместе с высотами, которые нарисовали самостоятельно по детальным снимкам и ЦМР. Приятно, что Микрософт уже много лет не отворачивается от открытых сообществ. Спасибо им.

Модератор, помоги

В новой версии редактора iD не только добавили снимки от Esri, но и заметно улучшили панель свойств пакета правок, которое вы заполняете при сохранении. Например, видите выпадалку «добавить поле»? Она позволяет в сто кликов указать источник (выбрать из списка «Sources», затем выбрать из списка «survey»...) и добавить хэштеги, не портя ими комментарий. Новые поля заполняют теги source и hashtags соответственно.

Большую часть тегов пакета правок iD заполняет самостоятельно. К обычным created_by, host, locale и imagery_used добавили тег changesets_count с полным количеством ченджсетов, которое возвращает OSM API. По нему можно определить опытность пользователя: когда в теге значение 0, стоит присмотреться. В пакетах правок новичков вы найдёте теги ideditor:walkthrough*=*: из них можно узнать, прошёл ли человек интерактивный учебник в редакторе.

Главное изменение, конечно, — галочка «проверьте мои правки, пожалуйста». Рекомендована всем новичкам и тем, кто не уверен в соответствии местным стандартам картирования. Если её включить, на пакете правок появится тег review_requested=yes. Пакет заметят пользователи сайта для слежения OSMCha: там появится плашка «Review requested». Фильтровать по этому атрибуту OSMCha пока не научился.

josm-tested XXI

Две недели назад вышла очередная версия редактора JOSM, 12450. Он по-прежнему приветствует картографов обвиняющим «нечем заняться?». Прежде, чем объяснить открывающую картинку, перечислим интересные штуки, появившиеся за последние полгода:

  • Автоудаление подложек из списка в марте озадачило некоторых пользователей, которые добавляли слои Bing или OSM вручную.
  • Если в файле osm стоит атрибут upload="never", данные нельзя загрузить в OSM, без вопросов.
  • Можно не приближаться к данным после их загрузки, если снять галочку в окне скачивания.
  • Редактор научился перепроецировать растровые подложки — попробуйте со слоем Bing включить WGS84. Кстати, при перезапуске восстанавливается правильная проекция веб-меркатора.
  • Наконец-то можно загружать аудиофайлы в форматах mp3 и aac.
  • При нажатии на кнопку видимости в панели слоёв выпадает панель конфигурации. Для слоя GPX в этой панели можно поменять цвет — конечно, если там не тепловая карта.
  • Окно поиска стало шире: настройки и справку сгруппировали рамками, а в версии latest добавили выбор заготовки, по которой можно фильтровать.

Увлечённых мапперов ничего из этого не порадует: аудиомаппинг переоценён, проекции достаточно стандартной, а поиском мы пользуемся не глядя. Но если посмотреть в новом редакторе на торговый комплекс «Охотный ряд» в Москве, сразу заметна самая полезная функция. Felis в прошлом мае правил поэтажные планы фильтрами в JOSM, а теперь знать формат фильтров не обязательно: голубенькие кнопки с цифрами помогут быстро переключаться между этажами.

Новые автофильтры работают не только с тегом level. В настройках, во вкладке «данные OSM», можно выбрать нужное числовое свойство: layer, maxspeed или voltage. Впрочем, сложно представить, зачем могут пригодиться фильтры по значениям этих тегов. Создавать объекты при включенном фильтре сложно: новые точки и линии мгновенно пропадают, так как нужного тега на них, конечно, нет.

Редактор iD недавно получил всплывающие панели (Ctrl+I), показывает кнопки по «?» и знаки из Mapillary, но не научился ничему, связанному с поэтажными планами. Хотя... Адриен Пави, автор карты OpenLevelUp, добавил кнопки выбора этажей в этот редактор. Демо-версия показывает только один перекрёсток в центре Парижа и не обновлялась уже ровно год. Также год назад Pavel Zbytovský предложил пул-реквест в iD, добавляющий кнопку «Indoor» справа вверху с фильтром по этажам. Примеры есть по ссылке: эта версия редактора установлена на чешском сайте OSM и умеет работать с любым местом карты.

Фильтры в обоих редакторах пока выглядят кривовато, но из этих новостей уже хочется сделать вывод. Простая схема тегирования поэтажных планов прижилась: в базе 130 тысяч тегов indoor=* и 400 тысяч тегов level=*, из которых четверть стоит на линиях highway. Пока что этажи разрисовывают энтузиасты, умеющие настроить фильтры и мыслить трёхмерно на плоскости базы OpenStreetMap. Но как когда-то с мультиполигонами и отношениями запретов поворотов, авторы главных редакторов пытаются упростить рисование поэтажных планов.

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

Два два ноль и три три ноль

В рассылке dev@ с разницей в один день опубликовали два важных анонса новых версий. Во-первых, Брайан выпустил iD 2.2.0. Вторая версия вышла в ноябре, но там не было заметных внешних изменений: повинуясь требованиям Semantic Versioning, первую цифру увеличили из-за несовместимых изменений API. В 2.1.0 добавили поддержку GeoJSON с KML и красивые плавные изменения.

Новый iD больше не рисует меню полукругом при выборе объекта. Столько раз из-за него случайно удаляли дороги или округляли здания! Теперь меню спрятано под правую кнопку мыши, что позволит расширять его неограниченно, а не пока есть места в круге. В теории звучит хорошо, на практике столбик непонятных значков озадачивает. Ждём следующего шага: понятных слов вместо пиктограмм.

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

Разумеется, в релизе много других мелких улучшений. Например, последний комментарий к пакету правок сохраняется (привет всем, кто пишет «fix» или «мелкие правки»), но очищается через два дня. Мультиполигоны в старом стиле выглядят страшно и на них ругается валидатор: хотя из OpenStreetMap их недавно вычистили, пользователь может нарисовать такой случайно. Многие увидят красную коробочку при запуске: там список изменений в версии. Наконец, удалить объект можно только тогда, когда видно не менее 80% его поверхности.

Также вчера Пол Норман объявил о выходе версии 3.3.0 нашего картостиля osm-carto. В нём всё в порядке. То есть, авторы провели несколько рефакторингов, вынеся шрифты в отдельных файл, написав несколько инструкций. Самое заметное изменение — магазины на 17 масштабе рисуются точками, чтобы не отвлекать от других заведений. В репозитории на GitHub осталось всего шесть открытых пул-реквестов. Все они меняют отображение элементов карты (обводки дорог, паромных терминалов, грунтовок и т. п.), и поэтому отложены.

Самое важное в свежем релизе стиля — что он последний в ветке 3.x. Пул-реквесты почистили, страницу со сравнением 3.x и 4.x обновили, стиль 3.3.0 выпустили, временный запрет на визуальные изменения наложили. Следующим шагом в программе будет смёржить ветку lua в master и объявить о выходе версии 4.0.0. После этого в 3.3.x будут только чинить неприятности, да и то недолго.

Что такое ветка lua? Это переработка стиля с условием полной перезаливки базы данных. Подробность Пол расписал в пул-реквесте, а коротко:

  • Колонка типа hstore для каждого объекта. Она даст доступ ко всем тегам, пусть и без индексов. То есть, можно будет обозначить дороги с плохим покрытием или заведения, доступные людям на колясках. Колонка увеличивает размер базы всего на 10%, но позволяет убрать сотню других колонок, выгадав 5%.
  • Мультиполигоны. По умолчанию osm2pgsql разделяет мультиполигоны на отдельные полигоны: так те из них, что пересекают 180 меридиан, не накрывают bbox-ом весь мир. С ключом —multi-geometry мультиполигоны из OSM остаются мультиполигонами в базе. Это удобнее: не нужно собирать государства и острова из тысячу частей с ST_Collect, подписи национальных парков не множатся. К сожалению, это изменение замедлит рендеринг примерно на 5%, сильнее на близких масштабах.
  • Преобразования в lua. Lua — это несложный язык, часто используемый для настроечных скриптов. Предобработка тегов с его помощью в osm2pgsql позволяет указать численный тип для колонок типа population и layer, написать сложные правила построения z_order и отсортировать значения highway и place. Кроме того, скрипт будет отличать замкнутые линии от областей не только по тегам и собирать линии в мультиполигоны. Разумеется, старый стиль мультиполигонов он не поддержит.

Версию 4.0.0 выпустят в этом месяце. В течение пары месяцев ветки 4.0.x и 3.3.x будут развиваться параллельно, чтобы базу можно было перезаливать поэтапно. Следить за подготовкой к перезаливке можно в тикете OWG, пользоваться новым стилем — уже сейчас: пул-реквест приняли в master вчера.

Ранее Ctrl + ↓

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