Quel est le but de PostGIS sur PostgreSQL?


49

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?


2
C'est PostGIS qui fournit les types de données spatiales, les opérateurs et l'indexation ...
DPSSpatial

5
Non, il parle des types de géométrie PostgreSQL natifs.
Evan Carroll

4
La réponse courte est que PostGIS est (maintenant) 10x aussi fonctionnel que les types PgSQL. La réponse longue, qui englobe la question "Pourquoi développer de nouveaux types, et pas seulement améliorer ceux qui existent déjà", est abordée ci-dessous.
Paul Ramsey

1
La même chose s’est produite avec le framework Java Spring. Java avait des défauts / fonctionnalités manquantes. Spring a corrigé de nombreuses failles Java et ajouté des fonctionnalités utiles. Java a copié les correctifs et les fonctionnalités de Spring. Les gens se demandent alors pourquoi le printemps existe ...
Neil McGuigan le

Réponses:


86

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.


Aussi ... PostGIS est C ++. Ce serait un Showstopper pour un merge.Whether PostgreSQL ou non devrait être. Les dépendances l'arrêteraient aussi complètement - GDAL? Ha! Je n'arrive même pas à obtenir que le noyau accepte de dépendre de Perl> 5.8.0. Le rythme de développement est lent, même si vous avez des droits d’engagement; Les committers ne se contentent pas de libérer tous les objets cachés dans l’arbre, ils doivent également passer en revue le code et obtenir de grands changements en prenant des mois, voire des années. Il y a des avantages en termes de qualité de code mais cela ne va certainement pas vite.
Craig Ringer le

C’est un problème particulier que core Pg ne cesse de réinventer les choses pour éviter de dépendre de bibliothèques plus externes. Parce que cela voudrait dire $ ancien_unix_42 avec $ weird_vendor_compiler sur $ dead_architecture devrait le supporter, tous les membres de buildfarm auraient besoin de mises à jour, etc. C'est l'un des problèmes de maturité et de stabilité, je suppose.
Craig Ringer le

@CraigRinger Pourquoi pensez-vous que PostGIS est C ++? C'est une insulte :-)
Nicklas Avén

Ce n'est pas ... J'aurais pu prêter serment. Mais bien sûr, ça n'en a pas l'air. Ma faute. En tout cas, j'aime bien utiliser (modérément et modérément) le C ++.
Craig Ringer le

4
Pendant un certain temps, PostGIS utilisait quelques éléments de C ++ pour créer une liaison avec GEOS. Une fois que GEOS a ajouté sa propre API C, ces éléments ont été supprimés et PostGIS est devenu "pur" C.
Paul Ramsey

34

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

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]


Pouvez-vous développer votre dernier point - celui sur les index GiST? PostgreSQL fournissait R-Tree et le fait maintenant à travers un index GiST donc je suis confus sur ce point.
Zeruno

mis à jour avec le texte direct de la FAQ.
Evan Carroll

1
L'API GIST est une chose PostgreSQL fournie par l' accès / gist.h . Vous pouvez le voir en cours d'utilisation dans PostGIS ici
Evan Carroll le

3
Bien que PostGIS ait sa propre implémentation rtree-on-gist, il est très similaire à celui utilisé par PgSQL pour son support de base des objets graphiques pour la simple raison que nous avons copié les leurs.
Paul Ramsey

1
@Zeruno, Non, la modification du séparateur d'arborescence dans PgSQL ne modifiera pas le comportement de PostGIS, car nous avons le nôtre, dans gserialized_gist_picksplit_2d (). Vous ne serez pas différent de celui de PgSQL, voire pas du tout.
Paul Ramsey

8

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
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.