Яка мета PostGIS на PostgreSQL?

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

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

Чому ми не просто використовуємо просторову функціональність PostgreSQL?

Якщо ви повторно намотували Всесвіт до початку 2001 року і не тільки дозволяли винахідникам PostGIS бачити майбутнє, але і дозволяли PSC PgSQL бачити майбутнє, можливо, PostGIS буде серією патчів на PgSQL. Але як мінімум, якби ми починали як основні виправлення, перше, проти чого ми би зіткнулися, це:

• основні області PgSQL не підтримують отвори, але GIS-модель дуже хоче дір, ми можемо це змінити?

І core PgSQL сказав би: "ні, звичайно, ні. У областях є вже добре зрозуміла семантика, і ми не можемо йти назад, таким чином, несумісними змінами".

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

На той час, коли PostGIS демонстрував достатню зовнішню цінність, яку ядро ​​PgSQL переглянуло і сказало собі "так, це було б добре мати в ядрі як додаткову функцію", вже було стільки коду такого іншого стандарту та стилю від PgSQL (не кажучи вже про несумісну ліцензію), що ідея об'єднання насправді неможлива.

Натомість PostGIS став канонічним прикладом дійсно великого складного розширення, яке допомагає PgSQL залишатися модульним та розширюваним. "Як це вплине на щось на кшталт PostGIS" - питання, яке часто задають, оскільки ядро ​​PgSQL оцінює певні зміни. Це також гарна річ, не дуже гарна, як PostGIS, що є частиною ядра, але досить хороша.

Є й інші причини, як-от довгий перелік залежностей, які ядро ​​PgSQL не хотілося б бачити, загалом менша узгодженість коду та чистота API, які вони бажали б покращити, і далі. Навіть зачаття, PostGIS був занадто великим стрибком волосся для PgSQL, щоб проковтнути одним укусом.

Це просто не вірно, PostgreSQL не підтримує просторові типи даних. Він підтримує геометричні типи. Вони є ідеальними для деяких речей, але вони повністю відокремлені від реальних систем координат. Рідні типи

• не мають ідентифікатора просторової довідкової системи / SRSID.
• ніколи не можуть бути перепроектовані.
• навіть на сфероїді вони забезпечують дуже обмежену функціональність.
• Вони не стандартизовані.
• Вони не надають GIST-індекси.

Оновлення

Щодо питання щодо індексу, то це у FAQ

Чому не підтримуються індекси PostgreSQL R-Tree?

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

Наші тести показали, що швидкість пошуку для рідного R-Tree та GiST є порівнянною. Native PostgreSQL R-Trees мають два обмеження, які роблять їх небажаними для використання з функціями GIS (зауважте, що ці обмеження пов'язані з поточною реалізацією PostgreSQL, яка є рідною R-Tree, а не концепцією R-Tree в цілому):

• Індекси R-Tree в PostgreSQL не можуть обробляти функції, розміри яких перевищують 8K. Індекси GiST можуть, використовуючи "втратний" трюк, замінивши обмежувальну рамку для самої функції.

• Індекси R-Tree в PostgreSQL не є "нульовими", тому побудувати індекс на стовпчику геометрії, який містить нульову геометрію, не вдасться. [Індекси GiST захищені від нуля]

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-функцій, що викликаються як для векторних, так і для растрових даних

• Упакований командний рядок для імпорту растрових даних з багатьох стандартних форматів: GeoTiff, NetCDF, PNG, JPG

• Візуалізація та імпорт функцій підтримки векторних даних для стандартних текстових форматів, таких як KML, GML, GeoJSON, GeoHash та WKT з використанням растрових даних SQL в різних стандартних форматах GeoTIFF, PNG, JPG, NetCDF, щоб назвати декілька за допомогою SQL

• Безшовні растрові / векторні SQL-дзвінкі функції для екструзії значень пікселів за геометричною областю, запущена статистика за регіонами, відсікання растрових елементів за геометрією та векторизація растрових 3D-об'єктів, просторовий індекс та функції Підтримка мережевої топології. / використання даних Тигра перепису США

Крім того, до пунктів / частин, згаданих уже в цій публікації. Я б додав, як згадувалося на веб-сайті PostGIS Як це працює

Оскільки PostGIS знаходиться в C, він може використовувати інші бібліотеки в C і C ++, і це робить це ліберально. PostGIS залежить від:

• ГЕОС для багатьох алгоритмів обробки геометрії
• Proj.4 для функцій повторного проектування координат
• GDAL для растрової обробки та підтримки формату
• LibXML2 для розбору XML
• JSON-C для розбору JSON
• SFCGAL для розширеної підтримки 3D та додаткових алгоритмів геообробки