Форматы из систем управления базами данных

Библиотека Kepler.gl предназначена для визуализации и анализа геопространственных данных, однако сама по себе не взаимодействует напрямую с системами управления базами данных. Источником данных для визуализации выступают наборы данных, предварительно извлечённые из СУБД и преобразованные в форматы, понятные JavaScript-приложению.

Практически любой проект, использующий Kepler.gl, строится по следующей схеме:

  1. Данные хранятся в СУБД.
  2. Выполняются SQL-запросы или пространственные запросы.
  3. Результаты экспортируются в промежуточный формат.
  4. JavaScript-приложение загружает этот формат в Kepler.gl.
  5. Пользователь получает интерактивную карту и инструменты анализа.

По этой причине понимание форматов обмена между СУБД и Kepler.gl является важной частью разработки геоаналитических систем.

Требования Kepler.gl к данным

Независимо от исходной базы данных, Kepler.gl ожидает табличную структуру данных.

Каждая запись должна содержать:

  • координаты объекта;
  • геометрию;
  • атрибуты объекта;
  • временные метки (при необходимости).

Например:

id name latitude longitude population
1 City A 51.1694 71.4491 1200000
2 City B 43.2389 76.8897 2000000

После загрузки Kepler.gl автоматически определяет поля координат и позволяет строить слои визуализации.

JSON как базовый формат обмена

Наиболее распространённым форматом передачи данных из СУБД в JavaScript является JSON.

Пример записи:

{
  "id": 1,
  "name": "Astana",
  "latitude": 51.1694,
  "longitude": 71.4491,
  "population": 1200000
}

Многие серверные приложения формируют JSON непосредственно из результатов SQL-запросов.

Пример получения данных из PostgreSQL через Node.js:

const result = await client.query(`
    SEL ECT
        id,
        name,
        latitude,
        longitude,
        population
    FR OM cities
`);

res.json(result.rows);

Загрузка в Kepler.gl:

import {processCsvData} fr om '@kepler.gl/processors';

fetch('/api/cities')
  .then(response => response.json())
  .then(data => {
      console.log(data);
  });

Преимущества JSON:

  • естественно интегрируется с JavaScript;
  • поддерживается всеми современными СУБД;
  • легко передаётся через REST API;
  • подходит для потоковой передачи данных.

Недостатки:

  • большой объём при крупных выборках;
  • высокая нагрузка на память браузера;
  • отсутствие специализированных геометрических структур.

GeoJSON

Для геопространственных приложений стандартным форматом считается GeoJSON.

Он поддерживается большинством географических СУБД:

  • PostgreSQL/PostGIS;
  • MongoDB;
  • MySQL Spatial;
  • Oracle Spatial;
  • SQL Server Spatial.

Пример объекта:

{
  "type": "Feature",
  "properties": {
    "name": "Astana"
  },
  "geometry": {
    "type": "Point",
    "coordinates": [71.4491, 51.1694]
  }
}

Полная коллекция:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {
        "name": "Astana"
      },
      "geometry": {
        "type": "Point",
        "coordinates": [71.4491, 51.1694]
      }
    }
  ]
}

Экспорт GeoJSON из PostGIS

PostGIS предоставляет встроенные функции формирования GeoJSON.

Пример:

SEL ECT json_build_object(
    'type', 'FeatureCollection',
    'features', json_agg(
        json_build_object(
            'type', 'Feature',
            'geometry', ST_AsGeoJSON(geom)::json,
            'properties', to_jsonb(row) - 'geom'
        )
    )
)
FR OM (
    SEL ECT *
    FR OM cities
) row;

Полученный результат может быть сразу отправлен клиенту.

Node.js:

const result = await client.query(sql);

res.json(result.rows[0].json_build_object);

WKT (Well-Known Text)

Многие СУБД поддерживают текстовое представление геометрии.

Пример точки:

POINT(71.4491 51.1694)

Пример линии:

LINESTRING(
    71.4 51.1,
    71.5 51.2,
    71.7 51.3
)

Пример полигона:

POLYGON(
(
71.1 51.1,
71.4 51.1,
71.4 51.4,
71.1 51.4,
71.1 51.1
)
)

Получение WKT из PostGIS:

SEL ECT
    id,
    name,
    ST_AsText(geom) AS geometry
FR OM cities;

В JavaScript такие данные обычно преобразуются в GeoJSON перед загрузкой в Kepler.gl.

Использование библиотеки Terraformer:

import {WKT} fr om 'terraformer-wkt-parser';

const geojson = WKT.parse(
    'POINT(71.4491 51.1694)'
);

WKB (Well-Known Binary)

WKB представляет геометрию в бинарном формате.

Получение из PostGIS:

SEL ECT
    ST_AsBinary(geom)
FR OM roads;

Преимущества:

  • компактность;
  • высокая скорость передачи;
  • минимальный объём сетевого трафика.

Недостатки:

  • неудобен для отладки;
  • требует декодирования.

Преобразование осуществляется специализированными библиотеками:

import wkx from 'wkx';

const geometry = wkx.Geometry.parse(buffer);

const geojson = geometry.toGeoJSON();

CSV из реляционных СУБД

CSV остаётся одним из наиболее популярных способов передачи данных в Kepler.gl.

Пример:

id,name,latitude,longitude
1,Astana,51.1694,71.4491
2,Almaty,43.2389,76.8897

Экспорт из PostgreSQL:

COPY (
    SEL ECT
        id,
        name,
        latitude,
        longitude
    FR OM cities
)
TO '/tmp/cities.csv'
CSV HEADER;

Экспорт через psql:

\copy cities TO 'cities.csv' CSV HEADER

Загрузка CSV в Kepler.gl

Используется процессор данных:

import {
  processCsvData
} from '@kepler.gl/processors';

const csv = await fetch('/cities.csv')
    .then(r => r.text());

const dataset = processCsvData(csv);

Передача в хранилище:

dispatch(
  addDataToMap({
      datasets: dataset
  })
);

CSV подходит для:

  • точечных объектов;
  • статистических данных;
  • временных рядов;
  • демографической информации.

SQL-результаты через REST API

На практике Kepler.gl редко работает с экспортированными файлами. Чаще используются API.

Пример маршрута Express:

app.get('/api/cities', async (req, res) => {
    const result = await client.query(`
        SEL ECT
            id,
            city_name,
            latitude,
            longitude
        FR OM cities
    `);

    res.json(result.rows);
});

Клиент:

const rows = await fetch('/api/cities')
    .then(r => r.json());

Затем данные преобразуются в формат набора данных Kepler.gl.

PostgreSQL и PostGIS

Наиболее распространённая связка для работы с Kepler.gl.

Типичные пространственные типы:

POINT
LINESTRING
POLYGON
MULTIPOINT
MULTILINESTRING
MULTIPOLYGON
GEOMETRYCOLLECTION

Создание таблицы:

CRE ATE   TABLE cities (
    id SERIAL PRIMARY KEY,
    name TEXT,
    geom GEOMETRY(Point, 4326)
);

Добавление записи:

INS ERT INTO cities(name, geom)
VALUES (
    'Astana',
    ST_Point(71.4491, 51.1694)
);

Получение GeoJSON:

SEL ECT
    id,
    name,
    ST_AsGeoJSON(geom)
FR OM cities;

MySQL Spatial

MySQL поддерживает пространственные типы начиная с современных версий.

Создание таблицы:

CRE ATE   TABLE cities (
    id INT PRIMARY KEY,
    name VARCHAR(255),
    location POINT SRID 4326
);

Получение GeoJSON:

SEL ECT
    id,
    name,
    ST_AsGeoJSON(location) AS geometry
FR OM cities;

Результат может напрямую использоваться серверным приложением.

Microsoft SQL Server

SQL Server содержит типы:

geometry
geography

Пример:

SEL ECT
    Id,
    Name,
    Location.STAsText() AS WKT
FR OM Cities;

GeoJSON формируется на уровне приложения:

const geojson = {
    type: 'Feature',
    geometry: parseWKT(row.WKT),
    properties: {
        name: row.Name
    }
};

Oracle Spatial

Oracle использует тип:

SDO_GEOMETRY

Экспорт геометрии:

SEL ECT
    id,
    SDO_UTIL.TO_WKTGEOMETRY(shape)
FR OM roads;

Далее WKT преобразуется в GeoJSON.

MongoDB

MongoDB хранит геометрию практически в формате GeoJSON.

Пример документа:

{
  name: "Astana",
  location: {
      type: "Point",
      coordinates: [
          71.4491,
          51.1694
      ]
  }
}

Запрос:

db.cities.find()

Node.js:

const cities =
    await db.collection('cities')
        .find()
        .toArray();

Полученные данные почти не требуют дополнительной обработки.

Apache Parquet

При работе с большими объёмами данных используются колоночные форматы.

Одним из наиболее распространённых является Parquet.

Преимущества:

  • высокая степень сжатия;
  • быстрое чтение отдельных колонок;
  • эффективная аналитика.

Типичный сценарий:

Data Warehouse
        ↓
Apache Spark
        ↓
Parquet
        ↓
API
        ↓
Kepler.gl

Особенно актуален при работе с миллионами записей GPS-трекинга.

Apache Arrow

Arrow обеспечивает высокопроизводительный обмен данными между системами аналитики и JavaScript-приложениями.

Особенности:

  • колоночное хранение;
  • минимальное копирование памяти;
  • высокая скорость обработки.

Загрузка:

import {tableFromIPC} from 'apache-arrow';

const response =
    await fetch('/dataset.arrow');

const buffer =
    await response.arrayBuffer();

const table =
    tableFromIPC(buffer);

После преобразования данные могут быть переданы в Kepler.gl.

Формат H3 из аналитических хранилищ

Современные аналитические БД часто работают с индексами H3.

Пример результата запроса:

{
  "hex_id": "8928308280fffff",
  "count": 1245
}

Kepler.gl умеет визуализировать H3 напрямую.

Пример структуры:

[
  {
    hex_id: '8928308280fffff',
    count: 1245
  },
  {
    hex_id: '89283082813ffff',
    count: 963
  }
]

После загрузки создаётся слой H3 Layer.

Это позволяет отображать:

  • плотность населения;
  • транспортные потоки;
  • распределение заказов;
  • телеметрию устройств.

Формат Quadbin

Новые версии Kepler.gl поддерживают пространственные индексы Quadbin.

Пример:

[
  {
      quadbin: '5207251884775047167',
      val ue: 120
  }
]

Преимущества:

  • компактность;
  • масштабируемость;
  • интеграция с облачными аналитическими платформами.

Подготовка данных перед экспортом

Перед передачей данных в Kepler.gl обычно выполняются следующие операции:

Фильтрация

SEL ECT *
FROM trips
WH ERE trip_date >= CURRENT_DATE - INTERVAL '30 days';

Агрегация

SELECT
    city,
    COUNT(*) AS total
FR OM orders
GROUP BY city;

Упрощение геометрии

SEL ECT
    ST_Simplify(
        geom,
        0.001
    )
FR OM regions;

Ограничение набора данных

SEL ECT *
FR OM gps_tracks
LIM IT 100000;

Эти операции существенно уменьшают нагрузку на браузер и ускоряют работу визуализации.

Выбор формата в зависимости от задачи

Задача Формат
Табличные данные CSV
REST API JSON
Пространственные объекты GeoJSON
Передача геометрии между ГИС WKT
Высокопроизводительная передача геометрии WKB
Большие аналитические наборы Parquet
In-memory аналитика Arrow
Гексагональные индексы H3
Иерархические тайлы Quadbin

Правильный выбор формата определяет скорость загрузки карт, объём передаваемых данных, нагрузку на клиентское приложение и эффективность визуального анализа в проектах, построенных на основе Kepler.gl и современных систем управления базами данных.

Оглавление