Quel est le but de PostGIS sur PostgreSQL?

PostgreSQL supporte déjà les types de données spatiales, les opérateurs et l'indexation.

Qu'est-ce que PostGIS fournit exactement qui a rendu nécessaire l'existence d'une extension à PostgreSQL?

Pourquoi n'utilisons-nous pas tous la fonctionnalité spatiale de PostgreSQL?

Si vous remontez dans l'univers jusqu'au début de 2001 et que vous laissez non seulement les inventeurs de PostGIS voir l'avenir, mais également que le PSC de PgSQL voit l'avenir, peut-être que PostGIS serait une série de correctifs sur PgSQL. Mais au minimum, si nous avions commencé comme correctifs, la première chose à laquelle nous nous serions heurtés était:

• Les zones PgSQL de base ne supportent pas les trous, mais le modèle SIG veut vraiment des trous, pouvons-nous changer cela?

Et PgSQL de base aurait dit: "non, bien sûr que non, les régions ont une sémantique existante bien comprise et nous ne pouvons pas aller dans le sens contraire pour des changements incompatibles".

En tant que développeurs non essentiels, PostGIS a été en mesure de préparer des versions mensuelles et semestrielles pendant un certain nombre d'années, tandis que le noyau PgSQL était associé à des versions annuelles et plus longues. Nous avons également pu ajouter les fonctionnalités de notre choix, à tout moment, car nous avions des droits de validation dans notre projet, mais l'obtention de ces droits dans PgSQL prend très longtemps.

Au moment où PostGIS démontrait suffisamment de valeur externe que le noyau de PgSQL examinait et se disait: "Euh, ça aurait été sympa d'avoir dans le noyau une fonctionnalité supplémentaire", il y avait déjà tellement de code d'une norme et d'un style si différents de PgSQL (sans mentionner sous une licence incompatible) que l'idée de fusionner n'était pas vraiment possible.

Au lieu de cela, PostGIS est devenu l'exemple canonique d'une extension complexe de très grande taille qui aide PgSQL à rester modulaire et extensible. "Comment cet effet ressemblera-t-il à PostGIS?" Est une question souvent posée lorsque PgSQL principal évalue certains changements. C’est aussi une bonne chose, peut-être pas aussi bien que PostGIS, mais assez bon.

Il y a d'autres raisons, comme la longue liste de dépendances que PgSQL core aurait détesté, la cohérence généralement inférieure du code et la propreté des API qu'ils auraient désespérément amélioré, etc. Même au moment de la conception, PostGIS était une boule de poils trop grosse pour que PgSQL l’avale en une bouchée.

Ce n'est tout simplement pas vrai, PostgreSQL ne supporte pas les types de données Spatial. Il supporte les types géométriques. Celles-ci conviennent parfaitement à certaines choses, mais elles sont totalement distinctes des systèmes de coordonnées du monde réel. Types natifs

• ne pas avoir d'identifiant de système de référence spatiale / SRSID.
• ne peut jamais être re-projeté.
• même sur un sphéroïde, ils offrent des fonctionnalités très limitées.
• Ils ne sont pas standardisés.
• Ils ne fournissent pas d'index GIST.

Mise à jour

Quant à la question d'index, c'est dans la FAQ

Pourquoi les index PostgreSQL R-Tree ne sont-ils pas pris en charge?

Les premières versions de PostGIS utilisaient les index PostgreSQL R-Tree. Cependant, les arborescences R de PostgreSQL ont été complètement supprimées depuis la version 0.6, et l'indexation spatiale est fournie avec un schéma R-Tree-over-GiST.

Nos tests ont montré que la vitesse de recherche des fichiers R-Tree et GiST natifs est comparable. Les arborescences R-Post natives PostgreSQL ont deux limitations qui les rendent indésirables pour une utilisation avec les fonctionnalités SIG (ces limitations sont dues à l'implémentation actuelle de R-Tree native de PostgreSQL, et non au concept de R-Tree en général):

• Les index R-Tree dans PostgreSQL ne peuvent pas gérer les fonctionnalités dont la taille est supérieure à 8 Ko. Les index GiST peuvent, en utilisant l’astuce "avec perte", remplacer le cadre de sélection par la fonction elle-même.

• Les index R-Tree dans PostgreSQL ne sont pas "nuls et sans danger". Par conséquent, la construction d'un index sur une colonne de géométrie contenant des géométries nulles échouera. [Les index GiST sont null-safe]

PostGIS est une extension de base de données spatiale pour la base de données relationnelle-objet PostgreSQL . Il ajoute la prise en charge des objets géographiques permettant l'exécution de requêtes d'emplacement en SQL.

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

Outre la connaissance de base de l’emplacement, PostGIS offre de nombreuses fonctionnalités rarement trouvées dans d’autres bases de données spatiales concurrentes telles que Oracle Locator / Spatial et SQL Server. Reportez-vous à la liste des fonctionnalités PostGIS pour plus de détails.

La liste des fonctionnalités de PostGIS étend également ces fonctionnalités:

PostGIS ajoute des types supplémentaires (géométrie, géographie, raster et autres) à la base de données PostgreSQL . Il ajoute également des fonctions, des opérateurs et des améliorations d'index qui s'appliquent à ces types spatiaux. Ces fonctions, opérateurs, liaisons d'index et types supplémentaires augmentent la puissance du système de gestion de base de données PostgreSQL, ce qui en fait un système de gestion de base de données spatiale rapide, riche en fonctionnalités et robuste.

Liste des fonctionnalités

La série PostGIS 2+ fournit:

• Fonctions de traitement et d'analyse pour les données vectorielles et matricielles pour l'épissage, le découpage en dés, le morphing, le reclassement et la collecte / fusion avec la puissance de l'algèbre de cartes raster SQL pour un traitement de trame à grain fin
• Reprojection spatiale Fonctions appelables SQL pour les données vectorielles et raster Prise en charge de l'importation / exportation des données vectorielles du fichier de formes ESRI via des outils à la fois en ligne de commande et en interface graphique et prise en charge de formats supplémentaires via d'autres outils Open Source tiers

• Ligne de commande empaquetée pour importer des données raster à partir de nombreux formats standard: GeoTiff, NetCDF, PNG, JPG

• Rendu et importation de fonctions de support de données vectorielles pour les formats textuels standard tels que KML, GML, GeoJSON, GeoHash et WKT à l'aide de SQL Rendu de données raster dans divers formats standard GeoTIFF, PNG, JPG, NetCDF, pour en nommer quelques-uns à l'aide de SQL

• Fonctions callables SQL raster / vectorielles sans couture pour l'extrusion de valeurs de pixels par région géométrique, l'exécution de statistiques par région, l'écrêtage de rasters selon une géométrie et la vectorisation de rasters Prise en charge des objets 3D, index spatial et fonctions Prise en charge de la topologie du réseau / Utilisation des données US Census Tiger

En outre, aux points / parties déjà mentionnées dans ce post. J'ajouterais comme mentionné sur le site Web de PostGIS Comment ça marche

Puisque PostGIS est en C, il peut utiliser d'autres bibliothèques en C et C ++, et ce de manière libérale. PostGIS dépend de:

• GEOS pour de nombreux algorithmes de traitement de géométrie
• Proj.4 pour les fonctions de re-projection de coordonnées
• GDAL pour le traitement raster et la prise en charge du format
• LibXML2 pour l'analyse XML
• Analyse JSON-C pour JSON
• SFCGAL pour une prise en charge 3D étendue et des algorithmes de géotraitement supplémentaires