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

javascript

Прощай, Mapbox, и удачи

Иллюстрация с сайта библиотеки react-map-gl © Urbica

Mapbox вчера выпустил вторую версию своей библиотеки для векторных карт GL JS. С одной стороны, выглядит круто: трёхмерный ландшафт, небо, свободная камера, и всё стало в полтора раза быстрее. С другой — и это всколыхнуло твитер — новая версия выбросила открытую лицензию BSD, и каждое использование библиотеки теперь идёт через кассу. Код можно смотреть, но нельзя копировать.

Последнюю свободную версию Mapbox GL JS 1.13 немедленно форкнули тысячу раз. Главной ветвью будет MapLibre GL, которая объединила Юру Астрахана из Elastic, Klokan Tech, Stadia Maps, MapTiler, Where Group и других. Благодаря Люку из Stadia, мы избежали раздробления сообщества, собрали руководящую группу и даже набросали меморандум. Самое время переименовать зависимости в модулях npm и следить за новым проектом.

Есть и альтернативы: например, легендарный ГИС-комбайн OpenLayers (уже шестой версии!) умеет показывать векторные тайлы, правда, без WebGL. В твитере и Hacker News советуют попробовать:

  • Tangram — библиотека от Mapzen, 2D и 3D карты как плагин для Leaflet. То есть, привычный обвес на javascript и управление слоями и отображением через файл yaml. Её дополняет Tangram ES для того же самого, но на C++.
  • CesiumJS — гигантская библиотека, чтобы нарисовать глобус с объёмными модельками на нём. Написал бы больше, но их сайт не разрешает доступ из Беларуси.
  • Deck.gl — для визуализации огромных наборов данных на карте. От Uber, для которых гео — не главное направление бизнеса, поэтому не закроют.
  • Harp.gl — примерно то же от Here, чуть медленнее и неудобнее.
  • Procedural GL JS — простые 3D-карты из рельефа на основе Three.js.
  • WhirlyGlobe — на замену закрытого полгода назад Mapbox GL Native, SDK для айфонов и андроидов.

Или забить и вернуться к старому надёжному Leaflet: спасибо Ивану, Андрею и другим, что бесконечно полируют и обновляют эту библиотеку. В отличие от древнего форка от Mapbox, который удобнее для быстрого старта, но мёртв уже полтора года.

Есть ощущение провала: такую популярную библиотеку спрятали под пейволл. На основе GL JS выстроены многие другие открытые проекты, и их владельцы сейчас чешут репу. Но это ощущение непросто обосновать: люди оперативно организовали поддержку, смерть от смены технологий библиотеке не грозит, всё штатно. Mapbox как будто запустил новую библиотеку B2B, которую все забудут через неделю, как забыли Vision SDK. Как мы раньше ушли на OpenMapTiles и Kosmtik, так и теперь в этот стек векторных тайлов добавим MapLibre GL, поблагодарив Mapbox за шесть лет поддержки.

Фрагмент старой страницы сайта Mapbox

Эту заметку я хотел написать в духе «смотрите, какие Mapbox плохиши» со ссылками на Mapnik, OSRM, TileMill, Studio Classic, iD, GL Native. Но если серьёзно, они закрыли всего ничего, какие-то большие проекты, которые либо перестали быть актуальными, либо имеют хорошие альтернативы. При этом, как замечают Брэндон Лиу и Владимир Агафонкин на Hacker News, эти большие проекты построены из десятков, если не сотен, маленьких, которые были и будут открытыми. Именно в них главные инженерные достижения, которые стоит брать и переиспользовать.

Откуда же ощущение? Может быть, из-за OpenStreetMap? Компания Mapbox начиналась как осмерская и они наняли толпу разработчиков, близких к проекту. Затем они догадались, что в OSM денег нет, а есть в конкуренции сервисами с Google Maps. Закрыли всю непрофильную разработку и стали околоосмерской: поддерживали пару библиотек, помогали снимками, но не закладывались. Mapbox GL JS был какой-то тонкой, последней связью с сообществом открытой картографии. И теперь её оборвали.

Компания Mapbox так далеко ушла от нашего проекта, что теперь даже Apple и Facebook искушённее в OpenStreetMap, тратят на него больше денег и получают более впечатляющий и более открытый результат — см., например, Daylight Map Distribution. Можно сказать, что эпоха Mapbox как открытой компании вчера завершилась. Остались только щепки из отличных технических библиотечек — ничего особенного, у каждой организации такие летят. Разве что эти чаще касаются картографии.

Пол Рамси копнул чуть глубже в это ощущение конца. Вчерашнее событие было предсказуемо почти для каждого: когда в открытом проекте участвуют почти исключительно сотрудники одной и той же компании, ничего хорошего не жди. Однако главный нюанс с Mapbox в том, что эта компания — главный конкурент Google Maps на поле открытых технологий. И если компания больше не может поддерживать былую оперсорсную удаль, то это может быть грустным сигналом насчёт финансирования и торжества проприетарных карт. Пожелаем удачи в борьбе.

4 мес   javascript   mapbox

Кнопки не нужны

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

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

Кнопки изменения масштаба появились от свойств тайловой схемы вкупе с линукс-мышлением. Тайлы, из которых состоит карта, устроены просто: на нулевом масштабе один тайл, на первом — четыре (2×2), на втором — шестнадцать (4×4) и так далее, каждый квадратик делится пополам в обоих измерениях. Линукс-мышление требует максимальной конфигурируемости: вдруг пользователь захочет посмотреть на карту конкретно на 13 масштабе, а мы ему не дадим? Поэтому развитие карт идёт увеличением количества уровней масштаба как вглубь, так и вширь, добавлением промежуточных уровней и переходом на векторные тайлы с непрерывным масштабированием. Больше контроля пользователю!

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

Эти кнопки — бич веб-картографии. Как не устаёт напоминать Сергей Голубев, при каждом нажатии на «+» вы видите новую карту, с собственным картостилем и свойствами. На сайте osm.org у нас 20 (двадцать) различных картостилей. Каждое изменение стиля osm-carto затрагивает примерно половину из них, поэтому неудивительно, что дискуссии в репозитории обильно иллюстрированы и могут затягиваться. Но если подумать, действительно ли пользователю нужны все эти карты? Вне компьютера хватает трёх-четырёх: атласа мира, атласа области и карты города. Когда масштабов мало, больше времени остаётся на полировку оформления каждого. А точная настройка интерфейса становится излишней.

Изменить масштаб можно многими способами, в зависимости от устройства и сайта:

  • кнопками плюс-минус на экране;
  • теми же кнопками с зажатым shift для большей скорости;
  • ползунком масштабирования;
  • колёсиком мыши;
  • двойным кликом левой кнопкой;
  • растягиванием прямоугольника мышью с зажатым shift;
  • кнопками «+» и «-» на клавиатуре;
  • перетягиванием двумя пальцами на тачпаде или экране;
  • щипком или расщипком на экране;
  • дважды тыкаешь пальцем, второй раз не отпуская удерживаешь и тянешь вниз или вверх.

Почему так много? Потому что у каждого из этих способов есть недостатки: от сложности обнаружения (последний пункт от Сергея Синицына удивил многих в чате) и отсутствия технической возможности (клавиатура есть не у всех) до неудобства, неточности или низкой скорости отклика.

Но пользователи обычно приходят к вам не для того, чтобы масштабировать карту. Им все эти способы нафиг не нужны. Они хотят посмотреть на данные или понять взаимоотношение географических объектов. Если остановиться и подумать, что нужно пользователю, может оказаться, что либо не нужна интерактивность целиком, либо не нужно масштабирование, либо не нужны двадцать карт и сложные способы переключения между ними.

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

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

Пакет не нужен

«Нельзя ли при отправке изменений из maps.me разделять объекты по континентам?» — в очередной раз спрашивают на форуме. А то bbox (ограничительный прямоугольник) слишком большой, неудобно. OpenStreetMap был зачат тысячу лет назад программистом, и это лезет изо всех щелей: удивительно, как самые бессмысленные атрибуты становятся мерилом качества.

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

Но даже когда найдёшь нужный пакет правок, останется только бессильно смотреть на его bbox. И на стастраничный список точек, линий и отношений, каждая строчка которого по-своему бесполезна. Ченджсеты — это псевдоупорядочивание. Кажется, что они полезны присвоением метаданных группе объектов, своего рода над-отношения, но на самом деле — метки времени произвольны, их порядок не зависит от номера пакета, комментарии никто не пишет, источник часто врёт, географически, как видим, тоже никто не группирует. Остаётся один полезный атрибут: created_by. Всему остальному верить нельзя.

То есть, единственная польза от пакета правок — это посмотреть, каким редактором сделаны правки. Все остальные атрибуты: даты, bbox, список объектов — только отвлекают, создавая ложное впечатление группировки и упорядоченности. Которых нет, потому что техническое воплощение API не обещает порядка и не подразумевает удобства. Так, для правок maps.me я игнорирую пакеты и рассматриваю каждую правку отдельно. Правки на mmwatch — это поток объектов, у которых номер ченджсета лишь бесполезный атрибут. Увы, для сложных правок со взаимосвязанными изменениями (таких как сдвиг линии) такой подход не сработает.

Примерно об этом я говорил на схемотехнике год назад. О bbox нужно просто забыть: область применения этих прямоугольников ограничена и точно не касается ваших задач. А проблему пакетирования нужно как-то решать. Развязать топологические структуры, группировать по времени и географии, не давать пользователям и приложениям свободы в объединении правок. Это настоящая тема для какого-нибудь будущего API 0.8. А пока приходится работать с тем, что есть.

Следить за изменениями в регионе можно (нужно!) через WhoDidIt, искать их — в его более быстром форке. Пакет правок из интерфейса этого сайта можно открыть в Achavi, но иногда может не повезти. Если bbox окажется слишком велик, загрузки правок вы можете не дождаться. Потому что даже лучшие инструменты полагаются на bbox, который, повторюсь, плох примерно для всего.

Загружать геометрию ченджсетов часто приходится команде по работе с данными в Mapbox. Для этого они сделали и постоянно улучшают сайт OSM Changeset Analyzer, где есть фильтры по любому атрибуту, вплоть до причины для подозрений. Но самые подозрительные пакеты накрывают весь мир, Achavi тут бессилен. Поэтому в этом месяце они сделали то, что давно было пора: кэширование ченджсетов.

Каждую минуту скрипт скачивает свежие дополненные диффы и складывает их в хранилище Amazon S3. Затем он раздербанивает эти диффы на пакеты правок и результат тоже загружает туда же. И теперь сервис визуализации Changeset Map, встроенный в OSMCHA, загружает пакеты мгновенно. Обновите ваши букмарклеты: Changeset (перетащите в закладки).

Проблемы, конечно, есть, но с ними борются. Например, дополненные диффы не окончательны из-за чехарды с транзакциями в базе данных OSM. Их приходится обновлять и обновлять. То же касается и пакетов правок, которые возможно держать открытыми целые сутки, понемногу доливая в них новые объекты. Наконец, история там только новейшая: пакеты старее марта этого года можно не найти. Их загружают, но медленно. Проблему поиска по региону архив тоже не решает, как показывает опыт фильтрации на сайте OSMCHA. Поэтому пользуйтесь им для просмотра недавних правок, а историю ищите на WhoDidIt и Achavi. Неидеально — но пока мы не избавились от концепции пакетов правок, ничего лучше не сделать.

Leaflet 1.0

Мы уже не чаяли: 27 сентября, наконец, опубликован релиз библиотеки Leaflet 1.0.0. Спустя целых три года после выхода 0.7 и всего год после объявления «мы на финишной прямой к релизу».

Основным изменением, как всегда, стала скорость: многие функции переписали чуть ли не с нуля. Особенно заметна скорость отрисовки векторных слоёв. Появилась функция flyTo(), анимированными гифками которой когда-то рекламировали эту версию, и дробные уровни масштаба. Плагин Leaflet.label больше не нужен: вместо него в ядро добавили класс L.Tooltip. Ну и взаимодействие между кучей слоёв разных типов теперь должно быть предсказуемее.

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

2016   javascript

Разделяй и оптимизируй

Владимир Агафонкин давно рассказывает про библиотеку geojson-vt: она нарезает большие файлы GeoJSON на векторные тайлы прямо в браузере (или на сервере, или в нативном коде для смартфонов). Это часть большого стека отрисовки всего в виде векторных тайлов (Mapbox GL JS), про который автор делал много одинаковых докладов в первой половине года.

Что он сейчас сделал впервые — это написал статью про то, какие алгоритмы и решения делают geojson-vt таким быстрым. Вдумчивого чтения там на полчаса, хотя суть укладывается в список в середине: искать подходящие алгоритмы, не делать ненужного, лишнее удалять, и самое главное — профилировать каждую операцию. По сути, то же, что было в Leaflet, но результат куда эффектнее: сотни мегабайт данных обрабатываются пару секунд и отображаются почти мгновенно. Правда, видеозаписи этого чуда найти проще работающих примеров.

 2 комментария   2015   javascript
Ранее Ctrl + ↓

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