Перейти до вмісту

Геопросторовий

дані, зміст яких залежить від місця

Що це таке

Геопросторовими називають дані, аналіз і програмне забезпечення, у яких положення на Землі є частиною змісту. Показ вітроміра — лише число, доки його не прив’язано до щогли, на якій його знято. Показання лічильника стає корисним для планування тоді, коли його можна поставити на конкретну ділянку мережі, у межі певного району чи поруч із метеостанцією. Слово є прикметником і рухається разом з тим, що описує: геопросторові дані, геопросторове з’єднання, геопросторове моделювання.

Просторовий — ширше слово. Розкладка мікросхеми, план складу в місцевих метрах і креслення деталі — усе це просторові дані, але їхні координати мають сенс лише всередині креслення. Геопросторові дані прив’язані до планети через систему координат, тож два набори даних, створені незалежно один від одного, усе одно можна накласти один на одний і порівняти.

Місце потрапляє в набір даних у кількох формах, і користь від них різна.

  • Координати, найчастіше широта й довгота з GPS-приймача чи геокодера, дають точку, з якою програма може рахувати безпосередньо.
  • Геометрії описують, крім точок, лінії та площі: трасу кабелю, межі затоплення, зону обслуговування. Модель Simple Features від Open Geospatial Consortium (OGC), опублікована також як ISO 19125, визначає фігури, спільні для більшості баз даних і форматів файлів.
  • Адреси й назви місць зрозумілі людям, але їх треба геокодувати, тобто перетворити на координати, перш ніж щось вимірювати, і кожен геокодер визначає їх із власною точністю.
  • Коди територій, як-от поштові індекси, коди громад чи ідентифікатори комірок сітки, кажуть, у якій території щось лежить, але без точного місця в її межах.

Під усім цим лежить набір відкритих стандартів, завдяки яким геопросторові дані переходять між системами без втрати змісту. OGC публікує специфікації для геометрії, для файлів на кшталт GeoPackage і для вебсервісів на кшталт OGC API – Features. Реєстр EPSG дає кожній системі координат числовий код, тож 4326 означає широту й довготу на WGS 84 будь-де, де трапиться цей код. PROJ, бібліотека з відкритим кодом, перераховує координати з однієї такої системи в іншу й підтримує понад сотню картографічних проєкцій.

Чому це важливо

Місце — це ключ для з’єднання, який уже є майже в кожному наборі даних. Показання лічильників, метеоспостереження, записи про клієнтів і об’єкти мережі рідко мають спільний ідентифікатор, але кожне з них сталося десь. Геопросторове з’єднання поєднує рядки за тим, як співвідносяться їхні положення: одне всередині іншого, на заданій відстані чи з перетином, а не за рівністю значень. Воно пов’язує дані, між якими зовнішнього ключа ніколи й не було, і саме це часто стає першою причиною, чому організація починає ставитися до своїх даних як до геопросторових: питання, на яке потрібна відповідь, охоплює набори даних, що зустрічаються лише на карті.

Друга причина в тому, що місце змінює зміст середнього значення. Загальнонаціональна цифра споживання чи відключень може приховати один район, що вже на межі, тоді як решта має запас, а рішення, яке справді важить, стосується саме цього району: де підсилювати мережу, куди інвестувати, куди відправити бригаду. Групування за територією чи відстанню показує розкид, який ховає одна загальна сума.

Місце важить і поза аналізом. Короткий слід GPS-точок з одного телефона зазвичай показує, де власник ночує й де працює, тож дані про місцеперебування людей потребують такої самої обережності, як і будь-які інші персональні дані. На практиці це означає збирати їх із тією точністю, якої потребує мета, загрублювати перед тим, як ними ділитися, і зберігати лише доти, доки триває мета.

Як це виглядає на практиці

Розумні лічильники в кількох регіонах дали дані для понад 500 аналітичних звітів, написаних чистим SQL у PostgreSQL і BigQuery. Показання мали геолокаційні координати кожного лічильника, тож скрипти могли використовувати геопросторові з’єднання разом із CTE та віконними функціями, щоб знаходити регіональні тренди й аномалії. Кожен звіт супроводжував анотований SQL, щоб колеги могли відтворити й перевірити результат, а типові проблеми якості даних, серед них відсутні GPS-координати, було задокументовано з рекомендованим способом обробки кожної. Звіти допомогли в балансуванні регіонального навантаження й сприяли покращенню ефективності операційного планування на 10–15%.

Одинадцять операторів електромереж мали операційні дані, проте рішення про підсилення мережі й інвестиції ухвалювали майже без геопросторового аналізу. Їхні операційні дані було об’єднано з геопросторовим моделюванням, щоб кожну мережу можна було розглянути на карті й поставити їй конкретні запитання: які ділянки наближаються до своїх меж і які території насамперед виправдовують інвестиції. Аналіз підганяли під те, як кожен оператор фактично керує своєю мережею, замість роздати всім один шаблон.

Геопросторові дані мають лишатися швидкими й тоді, коли їх стає більше. У застосунку на PostgreSQL, де запити до геопросторових даних сповільнилися разом із часовими рядами споживання електроенергії, для геопросторових даних додали індекси GiST, а географічні дані хеш-партиціонували, щоб рівномірно розподілити навантаження між вузлами. Після цього геопросторові пошуки виконувалися за мілісекунди.

Де виникають проблеми

Позиції без GPS скупчуються там, де екватор перетинає нульовий меридіан. Карта клієнтів чи пристроїв показує щільне скупчення в Гвінейській затоці, а регіональні підсумки враховують записи з місця, де жоден клієнт жити не може. Пристрій без сигналу GPS або імпорт, що натрапив на порожню клітинку, записав нулі замість того, щоб лишити положення незаповненим. Невідоме положення слід зберігати як NULL, додати обмеження, яке відхиляє саме пару 0, 0, точку у відкритому морі, і рахувати відсутні положення в кожній партії, щоб кожен звіт зазначав, скільки записів лишилися без місця.

З’єднання за координатами дає лише кілька збігів. Два набори даних описують ті самі підстанції, проте з’єднання за рівними широтою й довготою поєднує лише жменьку рядків. Кожне джерело вимірювало чи округлювало координати по-своєму, а координати — це числа з рухомою комою, тож дві позиції за кілька сантиметрів одна від одної є просто різними значеннями. З’єднувати слід за відстанню, з допуском, обраним відповідно до точності джерел, через предикат, який може обслужити просторовий індекс. У PostGIS, зі стовпцями geography, що вимірюються в метрах:

SELECT a.substation_id, b.asset_ref
FROM survey AS a
JOIN register AS b
  ON ST_DWithin(a.location, b.location, 15);

Після цього варто переглянути рядки, які отримали більше ніж одну пару, бо допуск, достатньо широкий, щоб поглинути похибку вимірювання, може з’єднати й два сусідні об’єкти.

Точки в центрі поштової зони видають себе за точні позиції. Аналіз відстаней показує десятки клієнтів, що живуть в одній і тій самій точці, або теплова карта має гострі піки посеред поштових зон. Адреси геокодовано лише до рівня індексу, і кожна повернулася як центр своєї зони, а аналіз цього не помітив. Рівень, до якого визначено кожну точку (адреса, вулиця чи індекс), слід записувати в окремий стовпець поруч і фільтрувати або зважувати за ним, перш ніж вимірювати будь-яку відстань, коротшу за саму зону.

Торішні регіональні підсумки змінюються після оновлення меж. Звіт, повторно запущений на незмінених історичних даних, дає інші цифри за регіонами, ніж ті, що були опубліковані спершу. Точки з’єднали з поточним шаром меж, а відтоді громади об’єдналися, індекси розділили або зону обслуговування перекреслили. Слід зберігати сирі координати, а не лише регіон, у який вони потрапили, тримати шари меж із датами їхньої чинності, з’єднувати кожен запис із межею, що діяла на момент його часової мітки, і зазначати в кожному звіті, яка версія меж дала ці цифри.

Що почитати далі

  • OGC Standards — каталог відкритих геопросторових стандартів Open Geospatial Consortium, кожен зі своїми документами специфікації.
  • Simple Feature Access – Part 1 — спільна модель геометрії з точками, лініями й полігонами, на яку спираються бази даних і формати.
  • EPSG Geodetic Parameter Dataset — реєстр, що стоїть за кодами на кшталт 4326 і 3857, з повним визначенням кожної системи відліку.
  • PROJ — бібліотека з відкритим кодом, яка перераховує координати між системами відліку, з інструментами командного рядка та API.
  • OGC API – Features — стандарт OGC для публікації геопросторових об’єктів і запитів до них через HTTP.

Словник