Пример рабочего процесса для науки о векторных геопространственных данных
Делиться
Введение
Большинство данных, относящихся к измеряемым процессам в реальном мире, имеют геопространственный аспект. Организации, управляющие активами на обширной географической территории или имеющие бизнес-процессы, требующие учета множества географических атрибутов, требующих картографирования, столкнутся с более сложными требованиями к геопространственной аналитике, когда начнут использовать эти данные для ответа на стратегические вопросы или оптимизации. Такие организации, ориентированные на геопространственные данные, могут задавать следующие вопросы о своих данных:
Сколько моих активов попадают в географические границы?
Сколько времени требуется моим клиентам, чтобы дойти до объекта пешком или доехать на машине?
Какую плотность пешеходного потока следует ожидать на единицу площади?
Все это — ценные геопространственные запросы, требующие интеграции ряда сущностей данных в общий уровень хранения и масштабирования геопространственных соединений, таких как операции «точка-в-полигон» и геопространственное индексирование, для обработки соответствующих входных данных. В данной статье рассматриваются подходы к масштабированию геопространственной аналитики с использованием функций Databricks и инструментов с открытым исходным кодом, использующих реализации Spark, распространённый формат хранения таблиц Delta и каталог Unity [1], с упором на пакетную аналитику векторных геопространственных данных.
Обзор решения
На диаграмме ниже обобщен подход с открытым исходным кодом к построению геопространственного Lakehouse в Databricks. С помощью различных режимов загрузки (хотя часто через публичные API) геопространственные наборы данных попадают в облачное хранилище в различных форматах; в Databricks это может быть том в каталоге и схеме Unity Catalog. Форматы геопространственных данных в основном включают векторные форматы (GeoJSON, .csv и Shapefiles .shp), которые представляют точки широты/долготы, линии или полигоны и атрибуты, а также растровые форматы (GeoTIFF, HDF5) для данных изображений. Используя GeoPandas [2] или геопространственные инструменты на основе Spark, такие как Mosaic [3] или SQL-функции H3 Databricks [4], мы можем подготовить векторные файлы в памяти и сохранить их в унифицированном бронзовом слое в формате Delta, используя Well Known Text (WKT) в качестве строкового представления любых точек или геометрий.
В то время как слой «от приземления до бронзового» представляет собой журнал аудита принятых данных, слой «от бронзового до серебряного» — это то место, где могут применяться подготовка данных и любые геопространственные соединения, общие для всех вариантов использования в восходящем потоке. Готовый серебряный слой должен представлять единое геопространственное представление и может интегрироваться с другими негеопространственными наборами данных в рамках корпоративной модели данных; он также дает возможность консолидировать несколько таблиц из бронзового уровня в основные наборы геопространственных данных, которые могут иметь несколько атрибутов и геометрий, на базовом уровне детализации, необходимом для агрегации в восходящем потоке. Золотой слой в таком случае является слоем геопространственного представления, где могут храниться выходные данные геопространственной аналитики, такие как время в пути или расчеты плотности. Для использования в инструментах для создания информационных панелей, таких как Power BI, выходные данные могут быть материализованы в виде схем «звезда», в то время как облачные ГИС-инструменты, такие как ESRI Online, будут предпочитать файлы GeoJSON для определенных картографических приложений.
Подготовка геопространственных данных
Помимо типичных проблем с качеством данных, возникающих при объединении множества отдельных источников данных в архитектуре озера данных (отсутствующие данные, переменные методы регистрации и т. д.), геопространственные данные сталкиваются с уникальными проблемами качества и подготовки данных. Чтобы сделать векторные наборы геопространственных данных совместимыми и легко визуализированными на уровне вышестоящих источников, лучше всего выбрать геопространственную систему координат, такую как WGS 84 (широко используемый международный стандарт GPS). В Великобритании многие публичные наборы геопространственных данных используют другие системы координат, такие как OSGB 36, которая представляет собой оптимизированную систему координат для картографирования географических объектов Великобритании с повышенной точностью (этот формат часто записывается в восточном и северном направлениях, а не в более типичных парах широты и долготы), и для этих наборов данных необходимо преобразование в WGS 84, чтобы избежать неточностей на уровне нижестоящих источников, как показано на рисунке ниже.
Большинство геопространственных библиотек, таких как GeoPandas, Mosaic и другие, имеют встроенные функции для обработки этих преобразований, например, из документации Mosaic:
df = ( spark.createDataFrame([{'wkt': 'MULTIPOINT ((10 40), (40 30), (20 20), (30 10))'}]) .withColumn('geom', st_setsrid(st_geomfromwkt('wkt'), lit(4326))) ) df.select(st_astext(st_transform('geom', lit(3857)))).show(1, False) +—————————————————————————————————————————————————— |MULTIPOINT ((1113194.9079327357 4865942.279503176), (4452779.631730943 3503549.843504374), (2226389.8158654715 2273030.926987689), (3339584.723798207 1118889.9748579597))| +—————————————————————————————————————————————————————————+
Преобразует многоточечную геометрию из формата проекции WGS84 в формат Web Mercator.
Ещё одной проблемой качества данных, характерной только для векторных геопространственных данных, является концепция недопустимой геометрии, показанная на рисунке ниже. Эти недопустимые геометрии нарушают работу исходных файлов GeoJSON или анализов, поэтому при необходимости их рекомендуется исправить или удалить. Большинство геопространственных библиотек предлагают функции для поиска или попытки исправления недопустимой геометрии.
Эти этапы обеспечения качества и подготовки данных должны быть реализованы на ранних этапах в слоях Lakehouse. Ранее я уже выполнял их на этапе перехода от бронзового к серебряному уровню, вместе с любыми повторно используемыми геопространственными соединениями и другими преобразованиями.
Масштабирование геопространственных объединений и аналитики
Геопространственный аспект уровня Silver/Enterprise в идеале должен представлять собой единое геопространственное представление, которое обеспечивает все вышестоящие агрегации, аналитику, моделирование на основе машинного обучения и ИИ. Помимо проверки качества данных и исправления ошибок, иногда полезно консолидировать множество наборов геопространственных данных с помощью агрегаций или объединений, чтобы упростить модель данных, упростить запросы к вышестоящим данным и избежать необходимости повторного выполнения дорогостоящих геопространственных соединений. Геопространственные соединения часто требуют больших вычислительных затрат из-за большого количества битов, необходимых для представления порой сложной многополигональной геометрии, и необходимости множества попарных сравнений.
Существует несколько стратегий повышения эффективности таких соединений. Например, можно упростить сложные геометрические объекты, эффективно сократив количество пар широта-долгота, необходимых для их представления. Для этого существуют различные подходы, ориентированные на различные желаемые результаты (например, сохранение площади или удаление лишних точек), которые можно реализовать в библиотеках, например, в Mosaic:
df = spark.createDataFrame([{'wkt': 'LINESTRING (0 1, 1 2, 2 1, 3 0)'}]) df.select(st_simplify('wkt', 1.0)).show() +—————————+ | st_simplify(wkt, 1.0) | +—————————+ | LINESTRING (0 1, 1 2, 3 0) | +—————————+
Другой подход к масштабированию геопространственных запросов заключается в использовании системы геопространственного индексирования, представленной на рисунке ниже. Агрегируя данные о геометрии точек или полигонов в систему геопространственного индексирования, такую как H3, можно представить приближенную версию той же информации в сильно сжатом виде, представленную коротким строковым идентификатором, который соответствует набору фиксированных полигонов (с визуализированными парами широты и долготы), покрывающих земной шар в диапазоне шести- и пятиугольных областей с различным разрешением, которые можно сворачивать или сворачивать в иерархии.
В Databricks система индексирования H3 также оптимизирована для использования с движком Spark SQL, поэтому вы можете писать запросы, такие как эта точка в соединении полигонов, как приближения в H3, сначала преобразуя точки и полигоны в индексы H3 с требуемым разрешением (разрешение 7, что составляет ~ 5 км^2), а затем используя поля индекса H3 в качестве ключей для соединения:
WITH places_h3 AS ( SELECT id, lat, lon, h3_pointash3( CONCAT('POINT(', lon, ' ', lat, ')'), 7 ) AS h3_index FROM places_h3 AS ( SELECT name, Explode( h3_polyfillash3( wkt, 7 ) ) AS h3_index FROM regions ) SELECT l.id AS point_id, r.name AS region_name, l.lat, l.lon, r.h3_index, h3_boundaryaswkt(r.h3_index) AS h3_polygon_wkt FROM places_h3 l JOIN regions_h3 r ON l.h3_index = r.h3_index;
GeoPandas и Mosaic также позволяют выполнять геопространственные соединения без каких-либо приближений, если это необходимо, но часто использование H3 обеспечивает достаточно точное приближение для соединений и аналитики, например, для расчёта плотности. С помощью облачной аналитической платформы вы также можете использовать API для получения данных о дорожном движении в режиме реального времени и расчёта времени в пути с помощью таких сервисов, как Open Route Service [9], или дополнять геопространственные данные дополнительными атрибутами (например, транспортными узлами или торговыми точками) с помощью таких инструментов, как Overpass API для Open Street Map [10].
Геопространственные слои представления
Теперь, когда некоторые геопространственные запросы и агрегации выполнены, а аналитика готова к визуализации на последующих этапах, уровень представления геопространственного хранилища данных может быть структурирован в соответствии с инструментами, используемыми на последующих этапах для использования карт или аналитики, полученной на основе данных. На рисунке ниже представлены два типичных подхода.
При обслуживании облачной геопространственной информационной системы (ГИС), такой как ESRI Online или другого веб-приложения с картографическими инструментами, файлы GeoJSON, хранящиеся в томе слоя Gold/Presentation и содержащие все необходимые данные для создания карты или информационной панели, могут составлять слой представления. Используя тип GeoJSON FeatureCollection, можно создать вложенный JSON-файл, содержащий несколько геометрических объектов и связанных с ними атрибутов («объектов»), которые могут быть точками, линиями или полигонами. Если инструментом для создания информационных панелей является Power BI, предпочтительной может быть схема «звезда», в которой геометрические объекты и атрибуты могут быть смоделированы как факты и измерения для максимальной эффективности поддержки кросс-фильтрации и измерений, а выходные данные материализуются в виде дельта-таблиц на слое представления.
Архитектура платформы и интеграции
Геопространственные данные обычно представляют собой часть более широкой корпоративной модели данных и портфеля аналитических данных и вариантов использования машинного обучения/искусственного интеллекта, и для этого (в идеале) потребуется облачная платформа данных с рядом интеграций восходящих и нисходящих потоков для развертывания, организации и реального подтверждения ценности аналитики для организации. На рисунке ниже показана высокоуровневая архитектура платформы данных Azure, с которой я работал ранее.
Данные загружаются с помощью различных инструментов ETL (если возможно, достаточно самого Databricks). В рабочих областях поддерживается медальонная структура слоёв raw (бронзовый), enterprise (серебряный) и presentation (золотой), используя иерархию каталога Unity catalog.schema.table/volume для разделения слоёв по вариантам использования (в частности, прав доступа) при необходимости. Когда готовые к публикации презентабельные результаты доступны для различных вариантов обмена данными, создания приложений, создания информационных панелей и интеграции с ГИС.
Например, с облаком ESRI, коннектор учетной записи хранения ADLSG2 в ESRI позволяет данным, записанным во внешний том каталога Unity (т. е. файлы GeoJSON), извлекаться на платформу ESRI для интеграции в карты и панели мониторинга. Некоторые организации могут предпочесть, чтобы геопространственные выходные данные записывались в нисходящие системы, такие как CRM или другие геопространственные базы данных. Курируемые геопространственные данные и их агрегации также часто используются в качестве входных данных для моделей машинного обучения, и это без проблем работает с геопространственными таблицами Delta. Databricks разрабатывают различные функции аналитики ИИ, встроенные в рабочее пространство (например, AI BI Genie [11] и Agent Bricks [12]), которые дают возможность запрашивать данные в каталоге Unity, используя английский язык, и, вероятно, в долгосрочной перспективе любые геопространственные данные будут работать с этими инструментами ИИ так же, как и любые другие табличные данные, только одним из визуализированных выходных данных будут карты.
В заключение
В конечном счёте, всё сводится к созданию интересных карт, полезных для принятия решений. На рисунке ниже представлены несколько результатов геопространственной аналитики, которые я сгенерировал за последние несколько лет. Геопространственная аналитика сводится к знанию таких вещей, как местонахождение скоплений людей, событий или активов, время, которое обычно занимает путь из пункта А в пункт Б, и как выглядит ландшафт с точки зрения распределения интересующих нас характеристик (например, среды обитания, уровня депривации или какого-либо фактора риска). Всё это важно знать для стратегического планирования (например, где разместить пожарную часть?), определения клиентской базы (например, кто находится в радиусе 30 минут от меня?) или поддержки оперативных решений (например, в какую пятницу, какие места, скорее всего, потребуют дополнительных мощностей?).
Спасибо за чтение. Если вы заинтересованы в дальнейшем обсуждении или чтении, свяжитесь с нами или ознакомьтесь с некоторыми из ссылок ниже.
https://www.linkedin.com/in/robert-constable-38b80b151/
Ссылки
[1] https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/
[2] https://geopandas.org/en/stable/
[3] https://databrickslabs.github.io/mosaic/
[4] https://learn.microsoft.com/en-us/azure/databricks/sql/language-manual/sql-ref-h3-geospatial-functions
[5] https://www.ordnancesurvey.co.uk/documents/resources/guide-coordinate-systems-great-britain.pdf
[6] https://github.com/chrieke/geojson-invalid-geometry
[7] https://carto.com/blog/h3-spatial-indexes-10-use-cases
[8] https://www.uber.com/en-GB/blog/h3/
[9] https://openrouteservice.org/dev/#/api-docs
[10] https://wiki.openstreetmap.org/wiki/Overpass_API
[11] https://www.databricks.com/blog/aibi-genie-now-generally-available
[12] https://www.databricks.com/blog/introducing-agent-bricks
Источник: towardsdatascience.com
