Pull to refresh

Leaflet 1.x.x vs Openlayers 4.x.x. Часть 1. Исходный код

Reading time 3 min
Views 8.3K
Хочу поделиться опытом работы с данными JS-картографическими фреймворками, надеюсь материалы помогут сделать выбор в вопросе: какую библиотеку использовать именно в вашем проекте. Чтобы не утомлять, разобью его на несколько логических частей. Начнем с основного и исходного — кода.


Мне всегда нравился код Openlayers 2, он был максимально академично написан и документирован, разобраться в его коде и стать соавтором или написать плагин было достаточно легко.

Код 3-й версии и последующих также хорошо написан и документирован, но есть одно «но» — написан с использованием Google Closure Compiler и без использования ES6. Это весьма занятная штука, вот, например, размер самих библиотек:
Фреймворк Сборка Исходные файлы
Leaflet 1.0.3 144 кб 410 кб (90 файлов)
Openlayers 4.1.1 511 кб 3.1 мб (300 файлов)

Видно, что Сlosure Сompiler в 2+ раза эффективней сжимает исходные файлы, чем механизм Leaflet. Также предоставляет удобный механизм использования пространств имен при разработке, а не «эти ваши» import ‘../../../../src’ в ES6.

На этом все преимущества Google Closure заканчиваются (мое субъективное мнение). Дальше начинаются некоторые страдания, связаны они в основном с тем, что в сборках имена всех членов класса кроме публичных «оптимизируются» до 1-2 букв. Например, вам нужно написать потомок класса ol.source.Image под ваш источник данных, и вы можете работать только с публичными свойствами и методами. Достучаться до приватных членов класса, как и до абстрактных классов родителей, будет проблематично. Есть только один внятный вариант — делать свои сборки Openlayers (авторы OL предлагают использовать именно этот вариант), а делать плагины «рядом», не влезая в основную библиотеку, получится не очень удобно. Однако, внутри сборки Openlayers есть почти все что нужно для создания гис, даже сторонние провайдеры векторных и растровых данных (Esri например), и вероятность написания чего-либо самому или поиск плагина для большинства систем достаточно мала.

Leaflet изначально задумывался по другому принципу. В самой библиотеке есть необходимый минимум, для всего остального — плагины. Код следует этому принципу. В начале он был правда не очень документирован, комментариев не было совсем, потом появились заглавия в каждом классе, сейчас уже для всех публичных методов и свойств класса есть образцово-показательные описания и примеры использования. Код написан с использованием ES6 (пока используется только модульная система). Соответсвенно максимально удобно как создавать свои сборки Leaflet, так и писать расширения для него, авторы рекомендуют последнее.

В статье хотел показать простой пример доработки одного и второго фреймоворка на примере создания тайлового слоя с нестандартной тайловой сеткой, точка отсчета тайлов не в левом-верхнем углу, а посередине сетки (да, и такое встречается). Для Leaflet плагин выглядел примерно бы так:

export var CenterOriginTileLayer = TileLayer.extend({
  getTileUrl: function (coords) {
    // здесь идут простые математические действия по сдвигу координат тайла в центр сетки
    // и возвращание URL для данного тайла
  }
});

Но тут я внезапно понял, что для тайлового источника (ol.source.XYZ) в Openlayers есть свойство типа ol.tilegrid.TileGrid, в котором, в свою очередь, есть свойство origin — те самые координаты центра сетки. Короче говоря, в Openlayers есть все, и кодить даже не пришлось бы.

Итак, если оценивать с точки зрения кода, при прочих равных, что выбрать? Если вы понимаете, что и в Openlayers и в Leaflet (+плагины) нет готового, нужного вам функционала и придется засучив рукава писать дополнения или даже делать кастомную сборку — выбирайте Leaflet. Он проще и его легче интегрировать в ваш проект. Если функционала и там и там вам хватает, то в вопросе выбора надо руководствоваться другими условиями.

В следующей статье разберу сообщества разработчиков и расширения для данных фреймворков.
Tags:
Hubs:
+10
Comments 16
Comments Comments 16

Articles