Блог

Похоже, что по умолчанию не существует способа обработки сортировки по GEOSPATIAL типу данных. Под этим я подразумеваю сам тип, а не функцию, например, получение области или широты типа. Например, в чем-то вроде BigQuery это вообще не поддерживается. Каковы некоторые возможные (и полезные способы) сортировки геоданных?

С моей точки зрения, единственными элементами, которые, по моему мнению, имеют смысл для всех типов гео, будут:

• Строка-ify поле (возможно, для отладки, похоже, не имеет никакого полезного случая, кроме этого).
• Сортировка по длине / широте, полигоны преобразуются в центроид. Например, возможно, сортировка — это расстояние от экватора / Меридиана.

Каковы наиболее распространенные способы сортировки геоданных, или сортировка очень необычна для географических данных?

Пространственные данные в значительной степени являются частью большинства современных СУБД, и под этим я подразумеваю системы управления реляционными базами данных (а также несколько нереляционных).

Я предполагаю, что вы знакомы с ГИС и концепциями пространственных данных. Esri является одним из мировых лидеров в области приложений для обработки пространственных данных, и они в значительной степени полагаются на типы пространственных данных SQL и Oracle и базовые пространственные движки.

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

Итак, в качестве примера, у вас может быть таблица roads, представляющая дороги, которые имеют тип данных line, dams или границы свойств, представленные типом данных polygon и т. Д.

Если вы работаете с данными ГИС, вы поймете, что на самом простом уровне пространственные данные могут быть географическими, т.Е. Иметь координаты, представленные широтными / длинными координатами, обычно в диапазоне x (-180, 180), y(-90, 90). В качестве альтернативы данные могут быть спроецированы с использованием некоторой системы координат, такой как UTM, Albers и т. Д. В таких случаях единицы карты могут быть представлены некоторыми другими единицами, такими как футы или метры.

В частности, в SQL server, и я полагаю, что это то же самое для Oracle, было два поддерживаемых типа данных геометрии.

1. Тип geography представляет данные в системе координат круглой земли, например, градусы минуты и секунды
2. Тип геометрии представляет данные в евклидовой (плоской) системе координат и используется для представления прогнозируемых данных, т.Е. Данных, а не в десятичных градусах.

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

Это всего лишь пример изучения синтаксиса для нового типа данных в базе данных. Если вы использовали такие продукты, как ArcGIS, предполагая, что ваши данные правильно хранятся в СУБД, вы можете выполнять большинство запросов к пространственным данным (особенно для векторных типов данных), используя SQL-подобные скрипты.

Еще одна вещь, в то время как база данных использует столбец геометрии для хранения пространственных геометрий для вашего класса объектов, о котором идет речь, например, линейный тип данных для дорог. Вы сами можете добавить любые дополнительные столбцы данных или атрибуты, которые вам нужны. Большинство пользователей СУБД это хорошо понимают. Преимущество этого заключается в том, что вы можете комбинировать пространственные запросы, которые включают ваши (непрост) атрибутивные данные. Кроме того, ваши пространственные данные могут участвовать в связях с другими таблицами, например, слишком много. Итак, в качестве реального примера, если у вас есть исторические данные о доходности, связанные с номером / идентификатором поля, можно написать запросы, которые показывают те поля, которые, как говорят, имеют самую высокую среднюю доходность за последние три года. Выбор атрибутов определяется требованиями к данным. Истинная сила корпоративных ГИС-систем заключается в способности объединять некоторые пространственные данные со связанной информацией и обрабатывать информацию для принятия более правильных решений и лучшего понимания взаимосвязей. (Однако, как бы грандиозно это ни звучало, вы можете ожидать, что около 80-90% этой работы связано с деятельностью, связанной с качеством данных и обеспечением безопасности. Самая забавная часть — это самая короткая и легкая часть.) Мусор внутри …

Вот ссылки для обработки пространственных данных в разных СУБД:

• Oracle — https://docs.oracle.com/database/121/SPATL/spatial-concepts.htm#SPATL010
• Sql Server — https://docs.microsoft.com/en-us/sql/t-sql/spatial-geometry/ogc-methods-on-geometry-instances?view=sql-server-ver15
• PosgGresql — https://postgis.net /

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

Желаю удачи.

Практический пример в MS SQL Server:

1. Создайте пространственную таблицу и добавьте тестовые данные. На этом этапе сторонние инструменты значительно облегчают процесс загрузки, поскольку в действительности геометрия — это не то, что мы вводим, например, границы стран имеют тысячи вершин. (Я также намеренно опустил детали, относящиеся к идентификатору пространственной ссылки (SRID), чтобы упростить его.)

   ЕСЛИ OBJECT_ID (‘dbo.SpatialTable’, ‘U’ ) НЕ РАВЕН НУЛЮ
   , УДАЛИТЕ ТАБЛИЦУ dbo.SpatialTable;
   ПЕРЕЙДИТЕ

   СОЗДАЙТЕ ТАБЛИЦУ SpatialTable
   (id int IDENTITY (1,1),
   [Геометрия] геометрия,
   [StaText] КАК [Геометрия].STAsText());
   ПЕРЕЙТИ

   ВСТАВИТЬ В ПРОСТРАНСТВЕННУЮ таблицу ([Геометрия])
   ЗНАЧЕНИЯ (geometry::STGeomFromText(‘ПОЛИГОН ((0 0, 0 40, 40 80, 60 20, 0 0))’, 0));

   ВСТАВИТЬ В ПРОСТРАНСТВЕННУЮ таблицу ([Геометрия])
   ЗНАЧЕНИЯ (geometry::STGeomFromText(‘ПОЛИГОН ((0 0, 0 -40, 50 -10, 20 -10, 0 0))’, 0));
   УХОДИ

2. Выберите вставленные данные

2B) Графическое представление данных

3. Сортировка по свойству геометрии, площади.

Я думаю, что не существует универсальной сортировки 2D-данных, которая имела бы смысл в различных контекстах.

Например, рассмотрите возможность сортировки по паре ( longitude , latitude ). Если у вас нет точек с точно одинаковой долготой (маловероятно, учитывая, что это числа с плавающей запятой), это то же самое, что сортировка по longitude одному! Это просто объяснить, но имеет ли это смысл? Возможно, для некоторых приложений, но это привело бы к размещению точек на экваторе и полюсах очень близко, если они имеют близкие значения долготы, что не очень хорошо для других приложений.

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

Для разных приложений требуется различная сортировка. Например. BigQuery поддерживает кластеризацию по значениям географии. Кластеризация — это не сортировка, но в чем-то похожая. Для этого он использует кривую Гильберта, которая учитывает оба ( longitude , latitude ) и обеспечивает лучший способ кластеризации данных, чем по longitude отдельности или по паре ( longitude , latitude ), что, как мы видели, почти одно и то же. Кривая Гильберта полезна, но она не очень интуитивно понятна и не имеет смысла для других приложений, которые запрашивают сортировку.

Сортировка на 100% обычна для пространственных данных в базах данных. Фактически, основной причиной, по которой пространственные типы данных были введены в базы данных в первую очередь, была возможность сортировки по местоположению и создания пространственных индексов. (Если бы не это, мы бы все равно сохраняли местоположения в двух столбцах Lat, Lon.)

Существует много подходов к сортировке пространственных данных. Все они довольно сложны. Большинство коммерческих баз данных используют варианты схем сетки / тесселяции. Вот обзор механики пространственных индексов в SQL Server.

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

SQL Server начинается с древовидной структуры B , которая упорядочивает данные линейным образом. Из-за этого индексы должны иметь способ представления двумерной пространственной информации в виде линейных данных. Для этого SQL Server использует процесс, называемый иерархической равномерной декомпозицией пространства. При создании индекса компонент database Engine разлагает или реорганизует пространство в набор осей, выровненных по четырехуровневой сеточной иерархии. На рисунке 1 представлен обзор того, как выглядит этот процесс.

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

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