GIS

Що це таке

GIS, тобто геоінформаційна система (українською часто пишуть ГІС), — це поєднання даних, програм і робочих звичок, яке дає змогу зберігати, аналізувати й показувати все, що має положення на Землі. Вступний курс проєкту QGIS наголошує, що термін охоплює більше, ніж програму: поряд із програмним забезпеченням він називає цифрові дані й комп’ютери і розглядає GIS як усе, що стосується керування географічними даними та їх використання. Галузь склалася в 1970-х роках на обладнанні, яке могли собі дозволити лише університети й великі компанії. Сьогодні настільна GIS працює на звичайному ноутбуці, а телефон показує вебкарту, побудовану на тих самих ідеях.

Кожна GIS працює з двома видами даних.

• Векторні дані описують об’єкт як геометрію: точку для криниці, лінію для дороги, полігон для громади. Кожен об’єкт має рядок атрибутів, тож дорога знає свою назву, покриття й обмеження швидкості, а карту можна розфарбувати за будь-яким із них.
• Растрові дані описують сітку комірок, кожна з яких містить одне значення: колір пікселя на аерофотознімку, висоту рельєфу в цифровій моделі, кількість опадів за місяць. Якщо наблизити зображення достатньо, комірки стають помітними квадратами.

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

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

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

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

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

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

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

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

Широту галузі добре видно на прикладі понад тридцяти GIS-проєктів на замовлення, які було побудовано, розгорнуто й потім підтримувано в продакшні. Їхній стек відповідає частинам GIS, описаним вище. PostgreSQL із PostGIS зберігав просторові дані. GDAL/OGR переносив їх між форматами, серед яких shapefile, GeoJSON, GeoTIFF, KML і векторні тайли. QGIS і JOSM слугували для самої роботи з даними, а результат показували вебкарти на Mapbox GL і Leaflet. Робота охоплювала все від 2D- і 3D-картографії через обробку LiDAR, георектифікацію й векторизацію до карт приміщень і навігації в них.

GIS може бути й самим продуктом, а не лише інструментом за ним. SaaS-платформі для відстеження активів відновлюваної енергетики, як-от сонячних панелей і вітрових турбін, бракувало геопросторових можливостей, потрібних її клієнтам, щоб бачити, де ці активи стоять і як вони працюють. До платформи вбудували GIS-застосунок для карт з модульною архітектурою на бібліотеках GIS з відкритим кодом, обраною для того, щоб система лишалася достатньо легкою для невеликої команди. Він виріс від базового прототипу до наріжного каменя платформи з розширеною аналітикою та кастомними дашбордами й забезпечив зростання доходу у 10 разів завдяки допродажам, ліцензуванню даних та залученню нових клієнтів.

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

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

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

Сусідні полігони лишають щілини й перекриття. Межі громад, зони доставки чи поля, оцифровані по одному, сходяться неточно: між ними з’являються тонкі щілини, або дві зони претендують на ту саму смугу. Лінії, які мали б з’єднуватися, обриваються зарано чи проскакують одна повз одну (QGIS називає це undershoots і overshoots), і пошук маршруту тоді вважає дорожню мережу розірваною в цьому місці. Причина в тому, що об’єкти оцифрували незалежно, без правил топології. Оцифровувати слід із прилипанням до наявних вершин, запускати перевірку топології, яка позначає щілини й перекриття, і зберігати кожну спільну межу як одну спільну лінію.

Назви атрибутів приходять обрізаними. Шар, експортований як shapefile, повертається зі стовпцем population_density, перейменованим на population, і з другим стовпцем під назвою populati_1. Формат зберігає атрибути у файлі dBASE, який обмежує назву поля 10 символами й підтримує лише цілі числа, дійсні числа, рядки й дати, тож час доби та списки теж губляться. Обмінюватися даними варто у форматі GeoPackage, стандарті OGC, що зберігає шари й атрибути в одному файлі SQLite, а shapefile лишити для інструментів, які іншого не приймають.

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

• A Gentle Introduction to GIS — безкоштовний курс проєкту QGIS, від векторних і растрових даних до створення карт і просторового аналізу.
• Coordinate Reference Systems — розділ про родини проєкцій, про те, що зберігає кожна з них, і про перепроєктування на льоту.
• Topology — щілини, перекриття, undershoots, overshoots і відстань прилипання, яка їм запобігає.
• Shapefile driver — нотатки GDAL про обмеження формату на назви полів, типи й розмір файлу.
• GeoPackage — кодування OGC, яке зберігає векторні шари, тайли й атрибути в одному файлі SQLite.