В прошлом уроке мы с вами поднимали данных Postgres в контейнере. Если вы забыли или пропустили, рекомендую вернуться и освежить знания.

Мы с вами уже знаем, что для создания слоя необходимо иметь геометрию.

Но у нас же ничего нет... Где нам ее взять??

И на такой вопрос есть решение. Мы с вами рассмотрим самую популярную задачу - загрузку OpenStreetMap (OSM) в свою базу с дальнейшим выводом на карту.

Что нам потребуется?

Подготовка базы данных

Первое, что нам необходимо сделать - создать отдельную базу данных с отдельным пользователем, чтобы отделить OSM от всех остальных данных.

На прошлом занятии мы уже подключились к базе данных с помощью pgAdmin. С этого места и продолжим наш путь джедая котика.

Создаем нового пользователя

1. Открываем наш сервер и кликаем ПКМ по Login/Group roles => Create => Login/Group Role... (рис 1.)
2. Указываем имя нашего пользователя. У меня это будет osm (Рис 2.)
3. На вкладке Definition указываем пароль и не забываем его запомнить/записать (Рис 3.)
4. На вкладке Privileges ставим ползунок напротив Can login (Рис 4.)

Создаем базу данных

Теперь пришло время создавать наше хранилище данных.

1. Кликаем ПКМ по Databases (Рис 5.)
2. Указываем основные параметры (Рис 6.)
1. Имя базы данных - у меня это osm
2. Owner - владельцем нашей базы ставим созданного пользователя
3. Для работы с геометрией обязательно необходимо поставить расширение postgis
1. Раскрываем нашу базу
2. Кликаем ПКМ по Extensions => Create => Extension... (Рис 7.)
3. В списке наименований выбираем posgis (Рис. 8)

Котик, база готова. Что же дальше?

А дальше мы будем заливать данные!

Первое, что нам потребуется - скрипты для загрузки и файл. Я уже подготовил загрузчик. Сегодня мы посмотрим, как же его использовать.

Загрузчик сделан на базе утилиты osm2pgsql. Что же это за штука такая чудесная? Osm2pgsql позволяет без особых усилий и больших страданий загружать данные OSM в базу postgres.

А теперь поехали загружать.

Нам необходимо склонировать репозиторий в любую удобную папку.

Далее необходимо собрать docker образ, в котором установлен osm2pgsql. Для этого необходимо выполнить команду и дождаться окончания.

cd ./osm2pgsql && docker build -t osm2pgsql:latest .

Теперь нам необходимо скачать файл с данными. Переходим на сайт и качаем russia-latest.osm.pbf.

Этот файл необходимо положить по пути: repository_path/data/files,

где repository_path - папка, куда был склонирован репозиторий

Теперь настраиваем скрипт.

Открываем файл osm2pgsql/osm2pgsql.sh в любом удобном редакторе и меняем следующие переменные

PG_DATABASE - название базы данных

PG_USER - пользователь, которого мы создавали

PG_HOST - ip адрес postgres. У меня указан host.docker.internal, поскольку один контейнер будет подключаться к другому и все это происходит локально. Если у вас БД где-то на сервере, необходимо подставить свой ip

PG_PORT - порт, на котором запущен postgres

После того, как все нужные операции были проделаны, остается самое интересное - запустить.

Из папки с репозиторием выполняем следующую команду

sh osm2pgsql/osm2pgsql.sh

Терминал запросит пароль. Необходимо ввести пароль от пользователя, которого создавали.

Если все сделано верно, то вы должны увидеть следующую картину:

На этом моменте вы можете пойти гулять, играть, пить чай. В общем, все, что душе угодно.

Надеюсь вы уже вернулись...

По окончанию работы скрипта у нас должна быть следующая картина

На этом моменте работа со скриптом будет закончена и можно вернуться в базу данных.

Открываем нашу БД и смотрим на таблички. Должно быть 9 таблиц. Если у вас не видно таблиц, то можно нажать на схему public ПКМ и выбрать пункт Refresh.

Давайте заглянем в какую-нибудь табличку, например, planet_osm_roads.

Выбираем ее ЛКМ и кликаем на кнопку с иконкой таблицы вверху.

Перед нами открылось что-то странное и непонятное, похожее на Excel. Без паники!

Сейчас нас интересует одна единственная колонка.

Если мы пролистаем вправо до самого конца, то обнаружим колонку way и что-то непонятное в данных. Это и есть наша геометрия! Ураааа!

Мы можем выделить колонку и посмотреть геометрию на карте прям из pgAdmin. Для этого нажимаем на заголовок, чтобы выделить все строки, а затем в заголовке жмем на кнопку с иконкой карты.

О, чудо!

Но, подождите, а почему все белое???

Давайте посмотрим.

Сейчас я покажу немного магии postgis.

Чтобы добавить подложку на эту карту, проекция у геометрии должна быть EPSG:4326 и никакая другая. Давайте это проверять.

Выполним запрос

SELECT way, ST_SRID(way), ST_ASGeoJSON(way)::jsonb FROM public.planet_osm_roads
LIMIT 10

Немного поясню, что сейчас произошло.

На первых уроках я показывал и рассказывал про GeoJSON. В postgis есть функции для работы с данным форматом. Одну из таких мы сейчас и использовали - ST_ASGeoJSON.

Данная функция позволяет показать геометрию в формате GeoJSON.

Тут нам уже наглядно видно две вещи:

1. Если смотреть параметр crs, то видно проекцию EPSG:3857
2. Более опытный человек может взглядом на координаты понять, что за проекция (это нарабатывается только насмотренностью)

Следующая функция - ST_SRID.

Если мы не хотим смотреть на координаты, то проекцию можно посмотреть, использовав данную функцию.

Что будем делать?

Предлагаю не модифицировать данные, а создать на основе них представления (views, вьюхи), в которых как раз перепроецируем геометрию.

View представляет собой таблицу с данными, построенными на основе других данных. То есть мы можем выполнить запрос, собрать данные, а в случае изменения исходной таблицы, View автоматически пересчитается.

Переходим к созданию вьюхи. Выбираем ПКМ Views => Create => View...

Указываем имя. У меня это v_planet_osm_roads.

Указываем владельца - созданный нами пользователь.

Переходим на вкладку Code. Здесь нам нужно вставить запрос, которым будет формироваться view.

Вставляем следующий код

SELECT 
	ST_Transform(way, 4326) as geometry
FROM public.planet_osm_roads

И сохраняем.

ST_Transform позволяет трансформировать геометрию из одной проекции в другую. В данном случае мы трансформируем геометрию из поля way с проекцией 3857 в 4326.

Теперь давайте посмотрим, что получилось. View смотреть можно точно так же, как и обычную таблицу.

Мы видим таблицу, состоящую из одной колонки.

Попробуем посмотреть геометрию.

Вуаля! У нас есть подложка!

А теперь немного волшебства

Все это круто - таблички, геометрии, какие-то поля, но пока это мало чего нам дает.

Ловите связь.

Вспоминаем формат GeoJSON.

Мы с вами знаем, что для описания объекта нам необходим тип Feature, properties и геометрия. Геометрия у нас есть, тип тоже, а где properties?

Если мы выполним запрос

SELECT way, name, population, boundary FROM public.planet_osm_roads 

то увидим табличку из 4 полей, где way - геометрия, а остальные - набор данных. Так вот, наш набор данных - это и есть properties. То есть мы можем представить представить объект в виде

Поле way переехало в geometry, остальные поля уехали в properties, где ключ - наименование поля, значение - значение из строки.

Таким нехитрым способом мы получили описание объекта.

Для описания слоя нам потребуется уже более верхоуровневая сущность - FeatureCollection. Она содержит в себе массив features - объектов.

Ой, так получается, что таблица в БД соответствует слою?

Да, верно!

Вот мы и создали наши первые слои. А что с этим делать дальше, я покажу в следующих уроках.

• Котик, какие планы на сегодня?
• Контейнеризация и Docker
• Контейнеризация
• Docker
• Особенности контейнеров
• Ряд терминов из мира Docker
• Docker compose
• Запуск PostgreSQL в контейнере
• GUI для работы с БД
• Подключаемся к БД
• Репозиторий с исходным кодом проекта

Котик, какие планы на сегодня?

1. Поговорим про контейнеризацию и Docker
2. Запустим Postgres в контейнере

Контейнеризация и Docker

Мы ж вроде только про данные поговорили, причем тут какие-то контейнеры? Еда у котиков вроде в миске обычно... Что вообще происходит???

Нет, это не те контейнеры, о которых мы могли подумать.

Контейнеризация

Контейнеризация — это подход к разработке программного обеспечения, при котором приложение или служба, их зависимости и конфигурация упаковываются вместе в образ контейнера.

Вспомните грузовые контейнеры. В них помещают какие-либо вещи, которые потом перевозят в другое место.

Так же и у нас, только у нас в контейнер помещается приложение или сервис, который затем можно запускать на любой ОС, без необходимости устанавливать кучу разного ПО перед этим.

Такой подход к разработке очень облегчает настройку окружения для разработки, а также позволяет создать одинаковые условия для работы приложения во всех окружениях, будь это тест/прод или среда разработки.

Docker

Docker — это платформа контейнеризации с открытым исходным кодом, с помощью которой можно автоматизировать создание приложений, их доставку и управление. Платформа позволяет быстрее тестировать и выкладывать приложения, запускать на одной машине требуемое количество контейнеров.

Благодаря контейнеризации и использованию Docker разработчики больше не задумываются о том, в какой среде будет функционировать их приложение и будут ли в этой в среде необходимые для тестирования опции и зависимости. Достаточно упаковать приложение со всеми зависимостями и процессами в контейнер, чтобы запускать в любых системах: Linux, Windows и macOS. Платформа Docker позволила отделить приложения от инфраструктуры. Контейнеры не зависят от базовой инфраструктуры, их можно легко перемещать между облачной и локальной инфраструктурами.

Особенности контейнеров

• Важнейшая особенность контейнеров — их сравнительно короткий жизненный цикл. Любой контейнер можно остановить, перезапустить или уничтожить, если это необходимо. Данные, которые содержатся в контейнере, при этом тоже пропадут. Так выработалось правило проектирования приложений: не хранить важные данные в контейнере.
• Объем контейнеров измеряется в мегабайтах, поскольку в них упаковывают лишь те процессы и зависимости ОС, которые необходимы для выполнения кода. Легковесные контейнеры быстро запускаются и экономят место на диске.
• Один контейнер соответствует одному запущенному процессу. Отключение отдельного контейнера для отладки или обновления никак не помешает нормальной работе всего приложения.
• Контейнеризация обеспечивает надежную изоляцию процессов и повышает уровень безопасности систем. Приложения, которые работают внутри контейнера, не имеют доступа к основной ОС и не могут на неё влиять.
• Благодаря контейнерам можно автоматизировать развертывание приложений на разных хостах.
• Использование контейнеров позволяет перейти с монолита на микросервисную архитектуру. За счет этого ускоряется разработка новой функциональности, поскольку нет опасений, что изменения в одной компоненте затронут всю остальную систему.
• С точки зрения эффективности контейнеры котируются выше виртуальных машин. На одинаковом оборудовании можно запустить большое количество контейнеров, тогда как ВМ будет в разы меньше. Это важно при использовании облачной инфраструктуры — потребуется меньше ресурсов.

Ряд терминов из мира Docker

Образ контейнера: пакет со всеми зависимостями и сведениями, необходимыми для создания контейнера. Образ включает в себя все зависимости, а также конфигурацию развертывания и выполнения для среды выполнения контейнера. Как правило, образ создается на основе нескольких базовых образов, наслоенных друг на друга в файловой системе контейнера. После создания образ остается неизменным.

Dockerfile: текстовый файл, содержащий инструкции по сборке образа Docker. Он похож на пакетный сценарий, где первая строка указывает базовый образ, с которого начинается работа, а следующие инструкции устанавливают необходимые программы, копируют файлы и т. п. для создания необходимой рабочей среды.

Сборка: действие по созданию образа контейнера на основе сведений и контекста, предоставленных файлом Dockerfile, а также дополнительных файлов в папке, где создается образ. Сборка образов выполняется с помощью следующей команды Docker:

docker build

Контейнер: экземпляр образа Docker. Контейнер отвечает за выполнение одного приложения, процесса или службы. Он состоит из содержимого образа Docker, среды выполнения и стандартного набора инструкций. При масштабировании службы вы создаете несколько экземпляров контейнера из одного образа.

Тома: файловая систему с возможностью записи, которую может использовать этот контейнер. Поскольку образы доступны только для чтения, а большинству программ требуется возможность записи в файловую систему, тома добавляют слой с поддержкой записи поверх образа контейнера, который программы смогут использовать как файловую систему с возможностью записи.

Тег: метка для образа, которая позволяет различать разные образы или версии одного образа (в зависимости от номера версии или целевой среды).

Многоэтапная сборка: позволяет сократить итоговый размер образов. Например, большой базовый образ, содержащий пакет SDK, можно использовать для компиляции и публикации, а затем можно использовать небольшой базовый образ среды выполнения для размещения приложения.

Репозиторий (registry): место хранения готовых образов Docker. Репозиторий может быть публичный, как Docker Hub, так и приватный - развернутый в рамках корпоративной сети или локально, например, Nexus.
Если имя образа похоже на такое - registry.company.name.ru/namespace/name:1.1.0, то скорее всего у вас используется некий приватный репозиторий.
Если имя образа содержит только название образа - namespace/name:1.1.0, то, по-умолчанию, образы загружаются с Docker Hub.

При загрузке образов docker смотрит наличие скаченных или собранных локально. Если имя и тег совпадут, тогда скачивать ничего не будет.

Docker compose

Docker compose — это инструментальное средство, входящее в состав Docker. Оно предназначено для решения задач, связанных с развёртыванием проектов.

Зачем он нужен, если Docker сам по себе самодостаточный?

Программисты, а может и DevOPS'ы, по своей натуре, довольно ленивые создания. Кому, как ни котикам, это знать!😂
Docker compose призван облегчить жизнь разработчикам.

Представим ситуацию... Да чего представлять, она такой и будет в рамках разработки нашего ГИС.
Нам необходимо запустить несколько приложений:

• PostgreSQL
• Geoserver
• Frontend
• Backend

В случае использования Docker в чистом виде, на каждое приложением нам бы пришлось написать свою команду для запуска. Такие команды обычно очень длинные, например:

А если нам потребуется перед запуском контейнера оставить его, то добавится к этому еще как минимум 2 команды:

docker container stop container_name && docker container rm container_name

Согласитесь, выглядит страшновато и не супер удобно. Необходимо запоминать описание флагов (или часто подглядывать в docker help).

Docker compose призван решить эту проблему. Он предоставляет возможность описания всех необходимых параметров запуска контейнера в yaml файле. Также он продвигает идеологию запуска контейнеров в виде отдельных сервисов.

Что это нам должно сказать?

В одном yaml файле можно прописать N разных сервисов и запустить/остановить их все одной командой. Помимо запуска сервисов, сразу можно настроить общие тома и создать, а затем объединить, контейнеры в единую сеть.

Запуск PostgreSQL в контейнере

Сегодня мы с вами рассмотрим самый простой вариант запуска контейнера с помощью Docker и Docker Compose.

YAML файл для запуска контейнера выглядит следующим образом

В самом верху файла всегда указывается version. Версия эта относится конкретно к yaml. За счет нее docker compose понимает, какой набор параметров он может обработать.
Версии обновляются, посмотреть различия можно тут.

Переходим к services. Данная секция представляет собой именованный массив сервисов/контейнеров. postgres - название сервиса.

Под названием сервиса указывается уже ряд параметров, которые при использовании Docker мы бы прописывали в команде в виде отдельных ключей. Кратко пробегусь по каждому из них.

• platform - указывает контейнеру, какую платформу использовать в качестве основы. Платформу обычно никто не указывает, но мне она нужна, потому что на Apple M1 контейнер без этого просто не стартует
• container_name - имя контейнера
• image - базовый образ контейнера. Будет скачиваться с Docker Hub
• restart - политика перезапуска контейнера. Наш контейнер будет пытаться запуститься заново, во всех случаях, кроме того, когда мы его останавливает вручную
• ports - поскольку posgres у нас запущен как сервис внутри контейнера на определенном порту, нам необходимо иметь возможно достучаться до этого порта. Для этого используется маппинг портов - внешний_порт:внутренний_порт
• volumes - настройка файловой системы, томов. Поскольку это база данных, нам важно сохранять информацию на основной ОС, чтоб в случае перезапуска контейнера сохранить всю информацию. Указание мапппинга аналогично портам - внешная_папка:внутренняя_папка.
  Конструкция ${PWD} означает указание пути до текущей директории, откуда выполняем команду. Например, мы находимся в директории /users/cat/project/gis, выполняем команду в терминале из этой директории. Полный путь до папки в этом случае будет выглядеть как /users/cat/project/gis/data/db.

• environment - переменные окружения внутри контейнера.
  У меня присутствует интересная переменная $PG_PASS. Она нужна для того, чтобы не светить пароль в git. Вы при локальной разработке можете забить строку с паролем прямо в файл и не думать об этом.
  Описание переменных окружения, необходимых для нормальной работы Postgres в рамках Docker вы можете найти на странице образа в Docker hub.

Обратите внимание, никакой сети я не указывал. Docker создаст ее автоматически.

Теперь нам осталось выполнить только команду

PG_PASS=YOUR_PASSWORD docker-compose -f postgres/docker-compose.yml up -d

Выполнив команду

docker ps -a

убеждаемся в наличии запущенного контейнера, работающего на определенном порту

Если у вашего контейнера STATUS похож на "Exited...", то скорее всего вы что-то сконфигурировали неправильно, или образ содержит ошибку.

Узнать, что произошло, можно, выполнив следующую команду

docker logs container_name

Как мы видим, у нас все прошло успешно. Можно двигаться дальше.

GUI для работы с БД

Не все котики захотят работать в командной строке. Вводить команды, запоминать их... Не наш подход.
Кстати о командах. В контейнере можно выполнять команды.

docker exec -it container_name your_command

Иногда хочется зайти прямо внутрь контейнера и пошалить там. Для этого можно вызвать bash или sh, но всегда это доступно. С этим надо быть максимально аккуратным. Если ваш контейнер внутри работает из под пользователя root, то стоит задуматься, а не сменить ли образ или пересобрать под другим пользователем. С таким пользователем можно огрести множество проблем с безопасностью, например, подключив том к контейнеру, можно перейти в него и выполнить пару команд на удаление каких-нибудь папок.

Ладно, это было лирическое отступление. Возвращаемся к GUI.

На сегодняшний момент есть два варианта, как можно удобно работать с базой - в IDE или воспользоваться pgAdmin.

Я предпочитаю именно второй вариант. Там, кстати, можно посмотреть объекты прямо на карте.

Подключаемся к БД

У вас после установки первый раз будет только одна группа серверов. Кликаем по ней ПКМ и регистрируем новый сервер.

На вкладке General нам необходимо указать название нашего сервера. У меня это будет Development. Остальные настройки не меняем и переходим на вкладку Connection.

На вкладке Connection нам необходимо заполнить следующие поля:

• Host name/address - ip адрес нашего сервера
• Port - порт
• Maintenance database - база данных, которая будет открываться по-умолчанию после коннекта к серверу
• Username - пользователь из под которого коннектимся к серверу
• Password - пароль для пользователя
• Save password? - включаем, если хотим не вводить постоянно пароль.

Итак,

• Host name - 127.0.0.1 или localhost. Поскольку мы подключаемся с ОС к контейнеру, у которого наружу проброшен порт, мы делаем это в рамках своей сети, соответственно, можем использовать localhost
• Port - внешний порт, у нас он равен внутреннему, а именно, 5432
• Maintenance database - не меняю, так как баз у нас пока еще нет других
• Username - пока пользователей не заводили, поэтому оставляю суперпользователя postgres
• Password - помните я говорил про переменную $PG_PASS? Так вот она и содержит пароль для суперпользователя. Указываем его в поле
• Save password? - естественно включаю

Остальные вкладки мы не трогаем. Нажимаем save и проверяем, что сервер успешно добавлен, присутствует бд Postgres.

Так же можем убедиться в наличии расширения PostGIS.

Чтобы останавливать контейнер, используем команду

docker-compose -f postgres/docker-compose.yml down -v

Репозиторий с исходным кодом проекта

Я создал репозиторий с исходным кодом проекта. Разрабатывать будем там, всем примеры кода можно будет посмотреть там.
Долго не радуйтесь, поскольку проект будет довольно большой, в один прекрасный момент я создам для себя приватный репозиторий, в рамках которого продолжу разработку. Я не хочу, чтобы мой проект нагло своровали и использовали для своих нужд, а также я очень надеюсь, что вы будете кодить параллельно со мной и вкладывать частичку себя в вашу систему.

Надеюсь, мы меня поймете и поддержите 🐱

В предыдущих статьях я обмолвился, что мы будем хранить данные в БД Postgres. Почему именно он? На самом деле, все просто до безумия - самая распространенная БД, очень сильно себя зарекомендовавшая. Postgres используют многие, поэтому не вижу никаких причин его не использовать.

Чем же мы сегодня будем заниматься?

1. Вспомним немного теории баз данных
2. Посмотрим, что нам будет помогать в хранении и обработке гео данных

Немного теории БД

PostgreSQL - это мощная реляционная база данных с открытым исходным кодом бизнес-уровня. Она позволяет использовать реляционные SQL и нереляционные JSON данные и запросы.

Я думаю, все прекрасно знают, что реляционная модель предусматривает единственный способ представления данных – в виде набора двумерных таблиц.

Основные понятия, которыми будем оперировать

Из чего состоит таблица? Вы скажите, что все просто - колонки и строки. И да, вы окажитесь правы, но я есть другие понятия - поля (они же атрибуты) и кортежи.

Поля или атрибуты - описание колонок таблицы. Они состоят из описания

• Типа данных
• Признака обязательности - может ли быть пустым поле
• Длинна значения, если тип данных позволяет ограничить
• Признак главного ключа (primary key)
• Признак внешнего ключа (foreign key)

Есть еще ряд параметров, но нам хватит и этого 🙃

Ключи какие-то нам тут даешь... Какие двери ими открывать?

Главный ключ (он же primary key) обычно вешается на поле с идентификатором объекта. С его помощью можно однозначно идентифицировать, какой перед нами объект.

Primary key может быть несколько. Такое явление называется составным ключом. На практике именно в ГИС я такого не наблюдал, но, если понадобится, разберемся детально в процессе.

Внешний ключ (foreign key) обычно служит для связи двух таблиц между собой. Обычно в него записывают значение primary key другой таблицы. Таких ключей может быть несколько в рамках одной таблицы.

Установка признака внешнего ключа влияет на консистентность данных. Иными словами, если не проставить этот признак, то в поле можно будет записать индетификатор, которого не существует в связной таблице.

Например. Предположим, мы решили организовать склад хранения колес. Для этого нам необходимо иметь данные об автомобиле и его владельце, а также при приеме колес на хранение нужно учитывать ряд параметров - радиус колеса и тд. В этом случае можно схему БД можно представить следующим образом:

Получается, владелец (owners) может иметь несколько автомобилей. У автомобилей (cars), как мы знаем, по 4 колеса (wheels). Везде получается связь 1 ко многим.

Что же такое кортеж?

Кортежем является строка таблицы, содержащая данные по полям.

Ну и зачем же ты нам это рассказываешь?
Следите за ходом мысли!

Немного вернемся к самой первой статье и вспомним, что такое объект с точки зрения картографии.

Из этого определения мы можем сделать вывод, что:

1. Для того, чтобы у нас был именно картографический объект, необходимо иметь поле типа Geometry
2. Атрибутивный состав объекта - набор полей таблицы

Что же получается?

А получается интересная штука.

Слой получается путем создания таблицы, одним из полей которой является геометрия. С точки зрения GeoJSON, таблицу можно представлять в виде FeatureCollection, каждый кортеж которой - Feature, а поля таблицы попадают в properties.

Иными словами, в 90% случаев одна таблица в БД соответствует одному слою.

Бывают исключения. Например, мы хотим, чтобы на один объект приходилось несколько геометрий, каждая из которых могла быть стилизована по-своему.
В таком случае разумно будет создать две таблицы и связать их между собой в отношении 1 ко многим, либо использовать GeometryCollection и JSON поле с массивом атрибутов для геометрий.
Если мы будем делать несколько таблиц, то нам придется их все равно соединить в одну таблицу (создать представление (view) данных), где будет дублирование информации. Можно обойтись без представления, поскольку Geoserver'у можно скормить SQL, в котором прописать связь. На мой взгляд, это не самый удачный вариант, потому что можно забыть об этом SQL, изменить таблицу в бд, а потом сидеть и гадать, почему же у меня слой перестал выводится или что-то не отображается.

Как хранить гео данные в Postgres?

Вы можете задаться вопросом, а как же хранить гео данные, если Postgres по-умолчанию не умеет?

Вы всегда можете воспользоваться вариантом JSON полей, куда прописывать GeoJSON, но это не наш случай. В нашем варианте мы будем рассматривать расширение PostGIS.

PostGIS — программное расширение с открытым исходным кодом, расширяющее пространственную базу данных системы управления PostgreSQL. Расширение добавляет поддержку географических объектов, благодаря чему появляется возможность выполнять запросы местоположения в SQL.PostGIS позволяет хранить ряд географических и пространственных данных — точек, ломаных линий, полигонов, растр, а также использовать их для разных операций, например, поиска.

PostGIS в PostgreSQL используется для снятия ограничений, расширения функций и позволяет применять:

• растровые данные;
• функции создания геометрий и управления ими (создание и удаление полей с географическими данными, запросы скриптов, библиотек);
• функции редактирования геометрий и их форматированного вывода;
• расширенные 2D- и 3D-функции, в том числе для определения пересечений в 3D-пространстве);
• инструменты для определения пространственных отношений и измерений (например, для сравнения расстояния по плоскости и на сфере);
• функции создания и отображения растров в удобном формате (например, в JPEG или PNG);
• инструменты обработки растров (очищение рельефа, векторизация, увеличение или уменьшение яркости).

Возможности связки PostGIS и PostgreSQL на практике могут использоваться для определения:

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

Например, PostgreSQL с предустановленным расширением PostGIS может использоваться для:

• вычисления площади города, региона, государства;
• поиска ближайшей кофейни или магазина;
• построения карты (в том числе растровой) с отображением заданных объектов;
• поиска объектов или местностей, отвечающих заданным критериям (самый крупный город, самая южная страна, самая высокая точка).

Именно благодаря нему у нас и появляется возможность создавать поля с типом Geometry.

Все возможности PostGIS описывать не буду, иначе это будет долго и очень много. Будем разбирать на практике, быстрее поймете 🙃

Поскольку нам предстоит изучение довольно большого объема информации, я решил поделить эту статью на несколько частей.

В следующей части мы коротко пробежимся о том, что такое контейнеризация и docker, а также запустим Postgres с установленным PostGIS.

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

Geoserver представляет собой веб-сервер, обеспечивающий стандартным клиентам, таким, как веб-браузеры и настольные ГИС, доступ к хранящимся в различных форматах картам и данным. Это означает, что вы можете хранить ваши пространственные данные почти в любом предпочитаемом вами формате.

Geoserver — это эталонная реализация стандартов Open Geospatial Consortium (OGC) WFS (Web Feature Service) и WCS (Web Coverage Service), а также высокопроизводительная сертифицированная реализация WMS (Web Map Service). Geoserver является основным компонентом Geospatial Web.

Поскольку geoserver реализует несколько различных картографических, изучать мы будем весь функционал постепенно, по мере нашего продвижения по миру картографии.

Введение

Предположим, у нас имеется большой объём данных, например, данные по всем зданиям города Санкт-Петербург, хранящиеся в базе данных PostgreSQL (об этом мы еще поговорим в одной из следующих статей), и какой-нибудь разработчик принимает решение использовать их в своем приложении. Прежде всего он вынужден будет реализовать все необходимые операции (извлечение, фильтрацию и т.п.) c помощью SQL. Если мы вдруг решим сменить способ хранения (например, перейдем на файловый вариант) или появится более качественный источник аналогичных данных, но в другом формате и разработчику нужно будет переключиться на него, то он будет вынужден полностью переписывать ту часть своего приложения, которая отвечает за извлечение данных из хранилища.

Основной задачей данных сервисов является предоставление универсального интерфейса доступа к данным, убирая необходимость прямого доступа к хранилищу.

Важно отличать Web Feature Service (WFS) от Web Map Service (WMS).

WMS предназначен для передачи уже отрендеренных данных, тех самых тайлов.

WFS отдаёт данные в оригинальном виде: в стандарте указан GML, однако никто не запрещает отдавать и в виде других форматов, например, изученном нами ранее GeoJSON.

Можно провести аналогию: скомпилированная программа (WMS) и исходный код (WFS).

WMS - Web Map Service

Как мы уже выяснили, WMS позволяет нам получать отрендеренные тайлы. Если говорить простыми словами - картинки с изображением объектов слоя, однако есть методы, возвращающие информацию о слое.

Рассмотрим доступные нам методы.

• GetCapabilities - возвращает параметры WMS (такие как формат изображения карты и совместимость версий WMS) и доступные слои (ограничивающая рамка карты (bounding box), системы координат, URI данных и является ли слой в основном непрозрачным или нет).
• GetMap - возвращает изображение карты. Параметры включают: ширину и высоту карты, систему координат, стиль рендеринга, формат изображения.
• GetFeatureInfo - позволяет при клике на тайл получить информацию об объектах в данной точке.
• GetLegendGraphic - возвращает изображение легенды карты, предоставляя визуальное руководство по элементам карты.

Метод GetMap - основные параметры

На данном этапе нам важно учитывать особенности Geoserver, а именно:

1. Количество стилей в параметре STYLES должно соответствовать количеству слоев в параметре LAYERS
2. Количество фильтров в параметре CQL_FILTER должно соответствовать количеству слоев в параметре LAYERS
3. Если одному из слоев нам не нужно применять фильтрацию, то к нему необходимо применить специальное слово INCLUDE

За счет регулирования параметров ширины, высоты, а также bbox, можно выводить тайлы на карту двумя способами:

1. Маленькими кусочками
2. Один тайл, захватывающий всю область видимости карты сразу

Первый способ позволяет отдавать пользователю информацию на просмотр гораздо раньше, однако в этом случае видно, как прогружается карта.

Второй способ заставляет пользователя немного подождать, однако на выходе мы получаем сразу полную картинку.

Метод GetFeatureInfo - основные параметры

Также ваша карта может отдавать в GetFeatureInfo параметры, как и у GetMap. Это абсолютно нормально, пугаться этого не стоит.

Если есть какие-то лишние параметры, которые не описаны в стандарте, то учитываться они не будут.

Если название параметра написано с ошибкой, а он обязательный, Geoserver вам об этом скажет, ровно как и сообщит о любой другой ошибке или отклонении от стандарта.

Метод GetCapabilities - основные параметры

WFS - Web Feature Service

Основная задача WFS-сервисов - это предоставление разработчикам (или конечным потребителям данных) универсального интерфейса доступа к пространственным данным, убирающего необходимость прямого доступа к хранилищу и таким образом делающего его прозрачным для пользователя. В этом случае задача по реализации доступа к различным хранилищам данных ложится на плечи WFS-сервера, то есть WFS сервер выступает в качестве прослойки между хранилищем данных и пользователем данных (к пользователям данных могут относится и в том числе и программы).

Стандарт WFS описывает 6 методов, каждый из которых отвечает за выполнение той или иной операции:

• GetCapabilities
• DescribeFeatureType
• GetFeature
• GetGMLObject
• Transaction
• LockFeature

Поскольку мы рассматриваем базовые возможности WFS, то остановимся на рассмотрении только первых трёх методов: GetCapabilities, DescribeFeatureType и GetFeature. GetGMLObject - довольно сложная штука и вряд ли вы с ней столкнётесь, а последние два метода Transaction и LockFeature предназначены для выполнения операций по редактированию объектов.

У всех запросов будет примерно одинаковый набор параметров. Дабы их каждый раз не повторять, вынесу отдельно

Метод GetCapabilities

Если вы внимательно посмотрите на название, то заметите, что такой метод уже был в WMS. Смысл этого метода точно такой же, что и в WMS.

Метод DescribeFeatureType

В ходе работы может потребоваться узнать дополнительную информацию об отдельных слоях, опубликованных по WFS. Для этого предназначен метод DescribeFeatureType. Данный метод возвращает список доступных слоёв или описание атрибутов, если в запросе передано имя конкретного слоя.

Метод GetFeature

Описанные выше два метода конечно полезны, однако наиболее важный метод ради которого и был разработан стандарт WFS - метод GetFeature, позволяющий запрашивать с сервера непосредственно сами данные. Данный метод необходимо использовать совместно с параметром typeName, определяющем имя слоя, объекты которого мы запрашиваем.

Если необходимо запросить информацию об одном объекте, то зная его id, то можно использовать параметр featureID.
Например,

?service=WFS&version=1.1.0&request=GetFeature&typename=space:buildings&featureID=buildings.7

featureID должен выглядеть как название_слоя.id

C помощью параметра maxFeatures можно ограничить количество получаемых данных. Здесь же можно передать параметр startIndex, который поможет получать информацию дозировано, а может быть и сделать пагинацию без написания своего бэкенда.

?service=wfs&version=1.1.0&request=GetFeature&typeName=space:buildings&maxFeatures=10&startIndex=11

Такой запрос означает, что мы получим 10 объектов, начиная с 11-го.

При этом Geoserver нам отдаст дополнительную информацию о кол-ве всего объектов в слоев, а также повторит информацию о кол-ве полученных объектов, равного параметру maxFeatures.

Ограничить список возвращаемых атрибутов можно с помощью параметра propertyName, передавая значения имен атрибутов через запятую, а отсортировать полученный результат с помощью параметра sortBy

• sortBy=value+D - по убыванию
• sortBy=value+A - по возрастанию

?service=wfs&version=1.1.0&request=GetFeature&typeName=space:buildings&sortBy=year+D&propertyName=year,address

Параметр outputName позволяет нам определить, в каком формате мы хотим получать ответ. Для нас самым часто используемым будет формат application/json, благодаря которому мы будем получать GeoJSON.

Оба метода GetCapabilities возвращают XML. Я намерено не углубляюсь в их ответы, поскольку GetCapabilities не так часто используется на фронтенде, а если и нужен, то карты, которыми мы будем пользоваться, умеют парсить ответ из коробки.

Если вам это очень интересно, подробнее можно почитать про WMS и WFS.

Geoserver позволяет нам фильтровать объекты как для WMS, так и для WFS, передавая параметр CQL_FILTER. Возможностифильтрации мы рассмотрим на практике, так как это тема отдельной статьи, а пока просто важно знать, что оно есть :)

На следующем занятии посмотрим, где мы будем хранить наши гео данные, и создадим первый слой.

В предыдущей статье мы затронули такие понятия, как форматы представления географических объектов, а также немного посмотрели на то, какие виды геометрии бывают. Сегодня мы начнем погружаться в детали, будет много технической информации. Надеюсь, вы еще не поджали свои маленькие хвостики.

Если вы не читали прошлую статью, настоятельно рекомендую сначала ознакомиться с ней.

Координаты

Координаты – фундаментальная геометрическая концепция. Свойство «coordinates» объекта геометрия состоит из пары/триплета координат (в случае геометрии типа «Point»), массива координат (объекты типа «LineString» или «MultiPoint»), массива массивов координат (объекты типа «Polygon», «MultiLineString») или многомерного массива координат (объекты типа «MultiPolygon»).

Координаты определяются массивом чисел. Этот массив должен содержать минимум два элемента, но их может быть больше. Порядок элементов должен быть следующим: x, y, z (для данных, находящихся в прямоугольной системе координат - смещение на восток, смещение на север, высота, для данных, находящихся в географической системе координат – долгота, широта, высота).

Например:

[30.315830718468703, 59.95010599732575, 3]

Система координат (СК) или проекция - определяют, как двумерная спроецированная карта описывает реальные местоположения на Земле с помощью координат. Нам из этого будет важно понимать, что СК имеет четкую формулу пересчета координат. Основные СК, которым будем оперировать:

1. WGS 84 или EPSG:4326
2. Меркатор или EPSG:3857

Пример EPSG:4326

[30.315830718468703, 59.95010599732575]

Пример EPSG:3857

[3374742.838555017, 8388637.907395536]

В дальнейшем в разных статьях примеры геометрий я буду приводить в разных системах координат. Будем развивать вашу насмотренность, чтобы вы могли с первого взгляда на описание геометрии определять, в какой системе координат она описана.

Геометрия

Прежде чем приступать к форматам представления, повторим, какие виды геометрий у нас есть, а также узнаете новые.

Есть три основных вида геометрий, с которыми чаще всего будем сталкиваться на практике.

1. Точка - Point
2. Линия - LineString
3. Полигон - Polygon

Если вы внимательно читали предыдущую статью, особенно описание каждого вида геометрий, наверняка обратили внимание на повторяющуюся фразу "состоит из набора точек". О чем нам это должно говорить? Точка является основой любой геометрии. На основе точек, или как их иначе называют, узлов, составляются все остальные геометрии.

Помимо основных видов, существуют еще подвиды - мульти- геометрии, а также геометрия в виде коллекции (geometry collection).

Мульти- геометрия состоит из набора геометрий одного вида, например:

1. MultiPoint - Геометрия, состоящая из нескольких точек
2. MultiLineString - Геометрия, состоящая из нескольких линий
3. MultiPolygon - Геометрия, состоящая из нескольких полигонов.

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

А что тогда с коллекцией геометрией? 🤔

Её особенность заключается в том, что, в отличие от мульти- геометрий, в нее можно положить разные виды геометрий.

Форматы представления географических объектов

Чтобы работать с геометрией на фронтенде, обмениваться картографическими данными между системами или просто передавая по API, люди придумали и зафиксировали определенные форматы. На текущий момент для быстрого старта в мир картографии нам хватит двух - GeoJSON и WKT.

На деле же форматов гораздо больше - shape, mid/mif, kml и т.п., но подробнее мы их будем разбирать позднее.

GeoJSON

Вспомним определение - формат на основе JSON, предназначенный для представления географических объектов с их непространственными атрибутами.

GeoJSON - четко зафиксированный формат данных. Любое отклонение в сторону грозит риском, что ваши карты его не смогут понять и отобразить. Официально зафиксированный стандарт, можно изучить тут.

Зачем объяснять, если он зафиксирован и можно почитать официальную информацию?

• Не все котята знают английский язык
• Стандарты иногда пишутся очень заумным языком
• Раз уж мы взялись собирать всю информацию в одном месте, давайте соберем и это, тем более rfc не описывает все примеры 🙃

Будем идти от простого к сложному - от описания геометрий до описания целого слоя с набором объектов.

Представление геометрий

Геометрия описывается в виде объекта, который обязательно должен содержать два поля:

1. type - тип геометрии
2. coordinates - описание координат

Теперь давайте посмотрим, как выглядят различные типы геометрий в формате geoJSON.

Точка - Point

{
   "type": "Point",
   "coordinates": [
         30.315830718468703,
         59.95010599732575
   ]
}

Линия - LineString

{
   "type": "LineString",
   "coordinates": [
      [30.303325070439058, 59.94495377359024],
      [30.303536318623713, 59.947704454457636],
      [30.31001459629374, 59.950948553926935],
      [30.31445080817707, 59.95271151830221],
      [30.32008409310859, 59.95316987367963],
      [30.323956976498494, 59.95281729318262]
   ]
}

Полигон - Polygon

В простом варианте

{
   "type": "Polygon",
   "coordinates": [
      [
         [30.307057121705924, 59.94953811490868],
         [30.32367531225134, 59.953099357880376],
         [30.320436173416283, 59.95658970985352],
         [30.307761282321366, 59.955144255147474],
         [30.307057121705924, 59.94953811490868]
      ]
   ]
}

Более сложный

{
   "type": "Polygon",
   "coordinates": [
      [
         [30.307195, 59.949252],
         [30.32423, 59.952949],
         [30.321053, 59.956903],
         [30.307918, 59.955141],
         [30.307195, 59.949252]
      ],
      [
         [30.311009, 59.954324],
         [30.318907, 59.955442],
         [30.320281, 59.95368],
         [30.311094, 59.952218],
         [30.311009, 59.954324]
      ]
   ]
}

Мульти-точка - MultiPoint

{
   "type": "MultiPoint",
   "coordinates": [
      [30.260433, 59.932574],
      [30.293057, 59.941431],
      [30.290653, 59.92337]
   ]
}

Мульти-линия - MultiLineString

{
   "type": "MultiLineString",
   "coordinates": [
      [
         [30.296181, 59.954495],
         [30.312751, 59.964721]
      ],
      [
         [30.295062, 59.955225],
         [30.311982, 59.96558]
      ],
      [
         [30.306481, 59.950025],
         [30.305966, 59.952819],
         [30.308885, 59.95559],
         [30.311761, 59.956708],
         [30.317084, 59.95703],
         [30.320776, 59.956256],
         [30.323609, 59.955075],
         [30.324897, 59.953807]
      ]
   ]
}

Мульти-полигон - MultiPolygon

{
   "type": "MultiPolygon",
   "coordinates": [
      [
         [
            [30.283822, 59.951443],
            [30.286397, 59.950283],
            [30.288973, 59.952389],
            [30.286483, 59.953248],
            [30.283822, 59.951443]
         ]
      ],
      [
         [
            [30.308976, 59.948607],
            [30.312239, 59.947704],
            [30.317905, 59.948091],
            [30.321253, 59.949896],
            [30.323056, 59.951099],
            [30.322283, 59.952217],
            [30.315072, 59.952217],
            [30.311724, 59.95097],
            [30.308976, 59.948607]
         ]
      ],
      [
         [
            [30.333787, 59.953764],
            [30.33808, 59.953764],
            [30.33808, 59.955698],
            [30.333787, 59.955698],
            [30.333787, 59.953764]
         ]
      ]
   ]
}

Коллекция геометрий - GeometryCollection

{
   "type": "GeometryCollection",
   "geometries": [
      {
         "type": "Point",
         "coordinates": [30.304941,59.95776]
      },
      {
         "type": "Polygon",
         "coordinates": [
            [
               [30.330697, 59.954623],
               [30.335848, 59.954623],
               [30.335848, 59.95703],
               [30.330697, 59.95703],
               [30.330697, 59.954623]
            ]
        ]
      }
   ]
}

"Вау! Мы нарисовали слой!!!", - могли подумать вы, и оказались не правы. Мы нарисовали всего лишь геометрию, состоящую из двух разных простых геометрий. Мы даже не нарисовали объект, так как у нас нет набора атрибутов.

Представление объектов

С геометрией все понятно, но ведь у объекта есть атрибуты. Куда же их девать?

Чтобы описать объект вместе с его атрибутами, в geoJSON сделали сущность Feature.

Feature обязательно должен иметь следующие поля:

1. type - тип, значение Feature
2. geometry - описание геометрии
3. properties - атрибуты объекта в виде JSON объекта.

Если объект содержит идентификатор, он может быть указан в виде отдельного поля id.

Если объект не содержит атрибутов, то поле properties должно быть установлено в значение пустого объекта. Отсутствие данного поля будет означать, что описание объекта является не валидным.

{
   "type": "Feature",
   "properties": {
      "shape": "Circle",
      "radius": 192.8759203950539,
      "name": "Просто круг в центре города"
   },
   "geometry": {
      "type": "Point",
      "coordinates": [30.304941,59.95776]
   },
   "id": "8c2c17eb-0c4a-4ed5-bab9-d00ae8289303"
}

А что с GeometryCollection? Все ровно также, как и с обычной геометрий. Поле geometry получает в виде значения описание GeometryCollection. Однако с точки зрения карты получится, что все ваши геометрии будут иметь одинаковый набор атрибутов, соответственно. Если вы хотите иметь разный атрибутивный состав, то у вас есть два пути описания:

1. Отказаться от GeometryCollection и поместить каждую геометрию в свой Feature, получив тем самым несколько разных объектов
2. Создать атрибут объекту Feature, который содержал бы значение массива объектов JSON, описывающих каждую геометрию отдельно

Представление слоя

Feature - это прекрасно, но мы хотим получать слой!

И на этот случай вам приходит сущность FeatureCollection. Эта сущность является самой верхоуровневой. Выше уже ничего не нет.

FeatureCollection должен иметь следующие поля:

1. type - тип, значение FeatureCollection
2. features - массив объектов Feature

Если объектов в слое еще нет, features должен быть объявлен как пустой массив.

В дальнейшем мы будем работать с Geoserver и получать слой разными способами. Забегу немного вперед. Если мы посмотрим на представление FeatureCollection, которое будет отдавать Geoserver, то увидим, что, помимо двух обязательных полей, он отдает еще ряд дополнительных, например, totalFeatures, crs и другие. Стандарт geoJSON позволяет расширять описание, добавляя дополнительные поля, если они необходимы. Мы даже можем добавить дополнительную геометрию, например, основная геометрия - полигон, а нам нужна центральная точка полигона. Однако стандарт говорит о том, что поле crs с указанием системы координат больше не используется, соответственно, валидаторы считают такой geoJSON невалидным

Geoserver отдает дополнительные поля скорее для упрощения жизни разработчику. Например, он позволяет делать пагинацию, запрашивая слой с limit и offset, как это делали бы мы в SQL. За счет передачи дополнительных полей мы четко можем понять, сколько всего объектов слое, а сколько мы получаем.

{
    "type": "FeatureCollection",
    "features": [{
        "type": "Feature",
        "properties": {
            "shape": "Circle",
            "radius": 192.8759203950539,
            "name": "Просто круг в центре города"
        },
        "geometry": {
            "type": "Point",
            "coordinates": [30.304941, 59.95776]
        },
        "id": "8c2c17eb-0c4a-4ed5-bab9-d00ae8289303"
    }, {
        "type": "Feature",
        "properties": {
            "shape": "Rectangle",
            "name": "Unnamed Layer"
        },
        "geometry": {
            "type": "Polygon",
            "coordinates": [
                [
                    [30.330697, 59.954623],
                    [30.335848, 59.954623],
                    [30.335848, 59.95703],
                    [30.330697, 59.95703],
                    [30.330697, 59.954623]
                ]
            ]
        },
        "id": "a6ccfde2-6ab9-4254-a051-c7a5faa4d594"
    }, {
        "type": "Feature",
        "properties": {
            "shape": "Line",
            "name": "Unnamed Layer"
        },
        "geometry": {
            "type": "LineString",
            "coordinates": [
                [30.301336, 59.969962],
                [30.30434, 59.96906],
                [30.308891, 59.969489]
            ]
        },
        "id": "925627f4-f015-419f-8cf5-b84f1ec7d408"
    }],
    "totalFeatures": 10,
    "numberMatched": 10,
    "numberReturned": 3,
    "timeStamp": "2023-05-01T19:42:10.965Z",
    "crs": {
    	"type": "name",
    	"properties": {
    		"name": "urn:ogc:def:crs:EPSG::4326"
    	}
    }
}

Инструменты

Быстрый просмотр и редактор геометрий

Валидация geoJSON

WKT - Well-known text

Еще один формат представления географических объектов. Не привязан ни к каким форматам, позволяет описывать геометрию в виде строки. Какого-то конкретного стандарта я найти не смог, однако на сайте IBM есть вполне четкое описание.

Неужели GeoJSON не хватает?

Да, не хватает. GeoJSON хоть и позволяет описать весь слой, однако итоговое описание получается очень громоздким, что нам не подходит под некоторые задачи.

В отличие от GeoJSON, WKT не позволяет описать весь слой, не позволяет описывать объекты слоя, т.е. никаких атрибутов положить в текстовое описание мы не можем.

Так для чего же нам тогда пригодится этот формат?

Поскольку в нашей практической части мы будем использовать открытое ПО, ГИС Geoserver, реализующий стандарт OGC, он будет накладывать на нас определенные ограничения.

В некоторый момент мы придем к тому, что заходим отфильтровать слой, получив определенный набор объектов. В Geoserver мы можем сделать это двумя путями:

1. Отправить запрос, сформировав определенного формата XML
2. Добавить query параметр к запросу

Я предпочитаю использовать второй вариант, так как его понимают большинство.

Query параметр сам по себе уже накладывает на нас ограничение. Передавать JSON таким способом плохая идея, тут нам на помощь как раз и приходит WKT.

Закончили минутку забегания вперед, давайте смотреть, как же описывать геометрию в данном формате.

WKT позволяет нам описать геометрию в виде строки определенного формата.

Координаты (долгота и широта) разделяются пробелом. Пары координат разделяются запятой.

Посмотрим на примерах, как это выглядит.

Точка

Пустая точка

POINT EMPTY

Точка с координатами

SRID=4326;POINT(30.330697 59.954623)

Точка с высотой

SRID=4326;POINT(30.330697 59.954623 3)

Линия

Пустая линия

LINESTRING EMPTY

Линия с координатами

SRID=4326;LINESTRING (30.303325070439058 59.94495377359024, 30.303536318623713 59.947704454457636, 30.31001459629374 59.950948553926935, 30.31445080817707 59.95271151830221, 30.32008409310859 59.95316987367963, 30.323956976498494 59.95281729318262)

Полигон

Простой полигон

SRID=4326;POLYGON ((30.307057121705924 59.94953811490868, 30.32367531225134 59.953099357880376, 30.320436173416283 59.95658970985352, 30.307761282321366 59.955144255147474, 30.307057121705924 59.94953811490868))

Полигон с "дыркой"

SRID=4326;POLYGON ((30.307195 59.949252, 30.32423 59.952949, 30.321053 59.956903, 30.307918 59.955141, 30.307195 59.949252), (30.311009 59.954324, 30.318907 59.955442, 30.320281 59.95368, 30.311094 59.952218, 30.311009 59.954324))

Коллекция геометрий

GEOMETRYCOLLECTION (POINT (30.304941 59.95776), POLYGON ((30.330697 59.954623, 30.335848 59.954623, 30.335848 59.95703, 30.330697 59.95703, 30.330697 59.954623)))

Инструменты

Online конвертер geoJSON в wkt

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

В следующей статье мы начнем разбирать Geoserver и затронем стандарт OGC.

Итак, поехали!