Какова цель PostGIS на PostgreSQL?

49

PostgreSQL уже поддерживает пространственные типы данных, операторы и индексацию.

Что именно предоставляет PostGIS, что делает необходимым существование в качестве расширения PostgreSQL?

Почему бы нам всем не использовать пространственную функциональность PostgreSQL?

Zeruno
источник
2
Именно PostGIS предоставляет эти типы пространственных данных, операторы и индексацию ...
DPSSpatial,
5
Нет, он говорит о собственных типах геометрии PostgreSQL.
Эван Кэрролл
4
Короткий ответ: PostGIS (в настоящее время) в 10 раз функциональнее PgSQL. Длинный ответ, который охватывает вопрос «зачем разрабатывать новые типы, а не просто улучшать уже существующие», рассматривается ниже.
Пол Рэмси
1
То же самое произошло с фреймворком Java Spring. У Java были недостатки / отсутствующие функции. Spring исправил множество недостатков Java и добавил полезные функции. Ява скопировала исправления + функции Spring. Затем люди спрашивают, почему существует весна ...
Нил МакГиган,

Ответы:

86

Если вы перемотали вселенную в начале 2001 года и не только позволили изобретателям PostGIS увидеть будущее, но и позволили PSC PgSQL увидеть будущее, возможно, PostGIS будет серией исправлений для PgSQL. Но, как минимум, если бы мы начинали как патчи с ядра, первое, с чем мы столкнулись бы, это:

  • основные области PgSQL не поддерживают дыры, но модель ГИС действительно хочет дыры, мы можем это изменить?

И ядро ​​PgSQL сказал бы: «Нет, конечно, нет, у областей есть хорошо понятая семантика, и мы не можем делать такие несовместимые изменения в обратном направлении».

Как неосновные разработчики, PostGIS смогла выбивать ежемесячные и 6-месячные выпуски в течение ряда лет, в то время как ядро ​​PgSQL тянулось вместе с ежегодными и более длинными выпусками. Мы также могли добавлять любые функции, которые хотели, в любое время, поскольку у нас были права на коммит в нашем проекте, но получение прав на коммит в PgSQL занимает очень много времени.

К тому времени, когда PostGIS демонстрировал достаточно внешнюю ценность, чтобы ядро ​​PgSQL просматривало и говорило себе «да, это было бы неплохо иметь в ядре в качестве дополнительной функции», уже было так много кода такого другого стандарта и стиля. PgSQL (не говоря уже о несовместимой лицензии), что идея объединения не была действительно возможна.

Вместо этого PostGIS стал каноническим примером действительно большого комплексного расширения, которое помогает PgSQL оставаться модульным и расширяемым. «Как это повлияет на PostGIS?» - часто задаваемый вопрос, поскольку ядро ​​PgSQL оценивает некоторые изменения. Это также хорошая вещь, возможно, не такая хорошая, как PostGIS, являющаяся частью ядра, но достаточно хорошая.

Есть и другие причины, такие как длинный список зависимостей, которые ядро ​​PgSQL не хотело бы видеть, как правило, более низкая согласованность кода и чистота API, которые они отчаянно хотели бы улучшить, и так далее. Даже в момент зачатия PostGIS был слишком большим шаром для PgSQL, чтобы его можно было проглотить за один раз.

Пол Рэмси
источник
Также ... PostGIS - это C ++. Это было бы showtopper для слияния PostgreSQL. Или не должно быть. Зависимости также остановили бы это полностью - GDAL? Ха! Я даже не могу заставить ядро ​​согласиться зависеть от Perl> 5.8.0. Темпы развития медленные, даже если у вас есть права на коммиты; коммиттеры не просто получают бесплатно все пуш-вещи в дереве, они должны пройти проверку кода и получить большие изменения за считанные месяцы или годы. Есть преимущества в качестве кода, но он не очень быстр.
Крейг Рингер
Это особая проблема, что ядро ​​Pg продолжает изобретать вещи, чтобы избежать зависимости от большего количества внешних библиотек. Поскольку это означало бы, что $ Ancient_unix_42 с $ weird_vendor_compiler на $ dead_architecture должны были бы поддерживать его, все члены buildfarm должны были бы обновиться и т.д. Это одна из проблем со зрелостью и стабильностью, я думаю.
Крейг Рингер
@CraigRinger Почему вы думаете, что PostGIS - это C ++? Это оскорбление :-)
Никлас Авен
Это ... нет? Я мог бы поклясться. Но, конечно же, это не похоже на это. Виноват. Во всяком случае, мне действительно нравится (умеренное и сдержанное) использование C ++.
Крейг Рингер
4
В течение некоторого времени у PostGIS было несколько кусков C ++ для привязки к GEOS. Как только GEOS добавила свой собственный C API, эти части были удалены, и PostGIS стал «чистым» C.
Пол Рэмси
34

Это просто неправда, PostgreSQL не поддерживает пространственные типы данных. Поддерживает геометрические типы. Они отлично подходят для некоторых вещей, но они полностью отделены от систем координат реального мира. Родные типы

Обновить

Что касается вопроса об индексе, это в FAQ

Почему не поддерживаются индексы PostgreSQL R-Tree?

Ранние версии PostGIS использовали индексы PostgreSQL R-Tree. Однако, начиная с версии 0.6, R-деревья PostgreSQL были полностью отброшены, а пространственная индексация обеспечивается схемой R-Tree-over-GiST.

Наши тесты показали, что скорость поиска для родного R-Tree и GiST сопоставима. Нативные R-деревья PostgreSQL имеют два ограничения, которые делают их нежелательными для использования с функциями ГИС (обратите внимание, что эти ограничения обусловлены текущей реализацией R-Tree в PostgreSQL, а не концепцией R-Tree в целом):

  • Индексы R-Tree в PostgreSQL не могут обрабатывать объекты, размер которых превышает 8 КБ. Индексы GiST могут, используя трюк с потерями, подставляя ограничительную рамку для самой функции.

  • Индексы R-Tree в PostgreSQL не являются «безопасными с нулевым значением», поэтому построение индекса по столбцу геометрии, содержащему нулевую геометрию, завершится неудачей. [Индексы GiST безопасны]

Эван Кэрролл
источник
Не могли бы вы рассказать о своем последнем пункте - об индексах GiST? PostgreSQL предоставлял R-Tree и теперь предоставляет это через индекс GiST, поэтому я не совсем понимаю этот момент.
Зеруно
обновлено с прямым текстом от часто задаваемых вопросов.
Эван Кэрролл
1
GiST API является PostgreSQL , что обеспечивает доступ / gist.h . Вы можете увидеть это в использовании в PostGIS здесь
Эван Кэрролл
3
Хотя PostGIS имеет свою собственную реализацию rtree-on-gist, она очень похожа на ту, что используется PgSQL для его основной поддержки графических объектов по той простой причине, что мы изначально скопировали их.
Пол Рэмси
1
@Zeruno, нет, изменение сплиттера rtree в PgSQL не изменит поведение PostGIS, потому что у нас есть свой собственный, в gserialized_gist_picksplit_2d (). Вы не будете сильно отличаться от PgSQL, если вообще будете.
Пол Рэмси
8

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

SELECT superhero.name
FROM city, superhero
WHERE ST_Contains(city.geom, superhero.geom)
AND city.name = 'Gotham';

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

Список возможностей PostGIS также расширяет эти возможности:

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

Список возможностей

Серия PostGIS 2+ обеспечивает:

  • Обработка и аналитические функции для векторных и растровых данных для сращивания, наложения кубиков, морфинга, переклассификации и сбора / объединения с помощью алгебры растровых карт SQL для детальной обработки растра
  • Пространственное репроецирование SQL вызываемых функций как для векторных, так и для растровых данных. Поддержка импорта / экспорта векторных данных шейп-файлов ESRI с помощью инструментов командной строки и графического интерфейса пользователя, а также поддержка большего количества форматов с помощью других сторонних инструментов с открытым исходным кодом.
  • Упакованная командная строка для импорта растровых данных из многих стандартных форматов: GeoTiff, NetCDF, PNG, JPG

  • Рендеринг и импорт функций поддержки векторных данных для стандартных текстовых форматов, таких как KML, GML, GeoJSON, GeoHash и WKT, с использованием SQL Рендеринг растровых данных в различных стандартных форматах GeoTIFF, PNG, JPG, NetCDF и многие другие с использованием SQL

  • Бесшовные растровые / векторные SQL-функции для извлечения значений пикселей по геометрическим областям, запуска статистики по регионам, обрезки растров по геометрии и векторизации растров. Поддержка 3D-объектов, пространственного индекса и функций. Поддержка топологии сети Packaged Tiger Loader / Geocoder / Reverse Geocoder / используя данные американской переписи тигра

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

Так как PostGIS находится в C, он может использовать другие библиотеки в C и C ++, и делает это свободно. PostGIS зависит от:

  • GEOS для многих алгоритмов обработки геометрии
  • Proj.4 для координатных функций повторного проецирования
  • GDAL для растровой обработки и поддержки формата
  • LibXML2 для разбора XML
  • JSON-C для разбора JSON
  • SFCGAL для расширенной поддержки 3D и дополнительных алгоритмов геообработки
whyzar
источник