Sortie de PostGIS 2.0

Posté par  (site web personnel) . Édité par baud123 et claudex. Modéré par baud123. Licence CC By‑SA.
Étiquettes :
29
5
avr.
2012
Base de données

On l’attendait impatiemment depuis un moment, c’est fait, la nouvelle version majeure de PostGIS est sortie !

PostGIS est la cartouche spatiale de PostgreSQL, la base de donnée Opensource relationnelle la plus avancée. PostgreSQL/PostGIS est souvent la pierre angulaire des systèmes d'information géographique. Elle comporte de nouveaux types de données (points, lignes, polygones…), un mécanisme d'indexation spatial, et un grand nombre de fonctions pour travailler avec ces données.

PostGIS 2.0, qui vient donc de voir le jour, arrive après un peu plus de 2 ans de développement. Les améliorations sont nombreuses, tant en terme de fonctionnalités, que de changements dans le code interne de PostGIS. Cette version utilise également les bibliothèques GEOS 3.3.3 et GDAL 1.9.0, qui sont sorties récemment.

Parmi les grandes nouvelles fonctionnalités, on trouve la gestion des raster (données image) dans la base de données, ainsi que la gestion d’un modèle topologique respectant le standard SQL/MM.

Tous les membres de l'équipe de développement de PostGIS tiennent à remercier leurs parents d'avoir rendu cette sortie possible.

Logo PostGIS

NdM: PostGIS 2.0 nécessite PostgreSQL 8.4 ou supérieur.

Mais ce n’est pas tout, et voici la liste des fonctionnalités introduites par PostGIS 2.0 :

  • Gestion des données raster et analyse raster/vecteur en base de données
  • Modèle topologique pour gérer les objets avec des frontières communes (pavages de plan par exemple)
  • Intégration du typmod PostgreSQL, avec table geometry_columns automatique
  • Indexation 3D et 4D
  • Recherche de plus proches voisins optimisée grâce à l’utilisation de l'indexation (KNN-search)
  • De nombreuses nouvelles fonctions de traitement vectoriel, dont :
    • ST_Split
    • ST_Node
    • ST_MakeValid
    • ST_OffsetCurve
    • ST_ConcaveHull
    • ST_AsX3D
    • ST_GeomFromGeoJSON
    • ST_3DDistance
  • Utilisation du mécanisme d’extension de PostgreSQL 9.1
  • Améliorations sur l’outil de chargement/sauvegarde de shapefiles en ligne de commande
  • Gestion multi fichier pour l’import et l’export dans l’outil d’interface graphique
  • Un géocodeur pour les données US Census TIGER 2010
  • Gestion initiale de primitives 3D

En outre, de nombreuses améliorations et refactorisations ont été faites dans le cœur de PostGIS, rendant cet outil un des plus performants du marché.

N’hésitez pas à télécharger et installer PostGIS 2.0, et à partager vos retours d’expérience de toutes ces nouvelles fonctionnalités.

Aller plus loin

  • # où ça des améliorations ?

    Posté par  (site web personnel) . Évalué à 1.

    En outre, de nombreuses améliorations et refactorisations ont été faites dans le cœur de PostGIS, rendant cet outil un des plus performants du marché.

    J'ai pas trouvé la liste de ces améliorations, justement…

    • [^] # Re: où ça des améliorations ?

      Posté par  (site web personnel) . Évalué à 5.

      Il s'agit principalement de la réécriture du format de sérialisation interne des géométries, ainsi que de la réécriture d'une grande partie du code d'indexation.

      Le parser (WKT & co) a également bénéficié de petits soins lui donnant plus de robustesse.

      On trouve aussi plus de fonctions qui supportent le type geography que dans la 1.5.3.

      La gestion des géométries EMPTY a également été rationalisée.

      Ensuite on trouve des corrections de bug en pagaille.

      Pour plus d'info il faut aller voir le changelog ou bien le trac. Par exemple :
      http://svn.osgeo.org/postgis/trunk/ChangeLog
      http://trac.osgeo.org/postgis/query

  • # I beg your pardon?

    Posté par  (site web personnel) . Évalué à 4.

    PostGIS est la cartouche spatiale de PostgreSQL,

    Je ne comprends pas ce que signifie "cartouche spatiale".
    C'est pour dire que PostGis est l'arme fatale de PostgreSQL dans le domaine de géolocalisation face a ses concurrents, ou c'est une pathétique traduction d'un terme anglais qui lui veut dire quelque chose a la base?

    (je pense que le fait que j'ai a me poser ce genre de question montre a quelles abysses d'absurdités on en est arrive en terme de traduction de termes techniques qui n'ont pas a l'être…)

    • [^] # Re: I beg your pardon?

      Posté par  . Évalué à 4. Dernière modification le 06 avril 2012 à 11:54.

      Ton commentaire me semble incroyablement pertinent, j'ai aussi buté 4 ou 5 secondes sur le terme "cartouche spatiale". Est-ce qu'il faut comprendre cartouche dans le même sens que les cartouches dans l'égypte ancienne ?

      EDIT : Ou en fait c'est juste "la cartouche" dans le sens "The killer feature" ou "La botte secrète" ou encore "L'arme absolue" :) (Comme tu l'avais dis plus haut…)

    • [^] # Re: I beg your pardon?

      Posté par  (site web personnel) . Évalué à 10.

      C'est une bonne question !

      C'est le terme qui est utilisé en géomatique pour désigner l'extension d'une base de données qui permet de traiter l'information géographique.

      Selon moi, cela ne vient pas de l'anglais, mais d'une déformation d'usage d'un nom masculin français, «LE cartouche».

      Selon le Grand Dictionnaire Terminologique, le cartouche en géographie est :

      Encadrement figurant au bas d'un tableau ou d'une carte géographique, dans lequel sont indiqués le titre, la légende ou d'autres mentions.

      Par analogie de construction, le cartouche spatial d'une base de donnée, est donc un élément positionné sur la base de données, rajoutant des éléments supplémentaires, en l’occurrence des éléments géographiques.

      C'est mon opinion personnelle, mais je n'ai jamais trouvé d'autre explication. En tout cas loin de l'idée des développeurs de PostGIS d'introduire une quelconque violence dans leur logiciel :)

      • [^] # Re: I beg your pardon?

        Posté par  (site web personnel) . Évalué à 3.

        C'est aussi utilisé dans d'autres domaines. Par exemple, dans AndroMDA, le système est composé d'un coeur est d'un ensemble d'extensions appelées cartouches (cartridge en anglais) qui sont des modules/filtres d'importation/exportation. Ces extensions apportent la partie "traitement des données". Si on veut modifier le contexte d'utilisation, il suffit de remplacer la cartouche.

        Par contre je ne vois pas le rapport avec le cartouche. Donc pour moi ce nom est féminin. Je pense que l'analogie (aussi bien en français qu'en anglais), vient du fait qu'en fonction de l'environnement de production (la cible), on insère la cartouche qui-va-bien dans le système (l'arme) et que sa nature produit un code (un effet) différent.

      • [^] # Re: I beg your pardon?

        Posté par  . Évalué à 2.

        J'ai toujours pas compris a quoi ca servait, y aurait il un exemple concret d'utilisation ?

        • [^] # Re: I beg your pardon?

          Posté par  (site web personnel) . Évalué à 10.

          Exemple :
          J'ai une table de communes (représentées par des polygones), et une table avec des points représentant les endroits où on trouve des services (médecin, pharmacie, etc). Ces deux tables n'ont aucun identifiant commun permettant de les relier par une jointure alphanumérique.

          Je peux alors faire des requêtes SQL spatiales pour répondre à une question par exemple :
          «combien y a t-il de médecins par commune et quelle est leur zone de couverture ?»

          Si je simplifie et considère qu'un médecin couvre une zone de 3 kilomètres à vol d'oiseau autour de son implantation, je peux effectuer la requête suivante :

          select
    c.code_insee
    , c.name
    , count(*) as nb
    , st_asgeojson(st_concave_hull(st_union(st_buffer(s.geom, 3000), 0.99, true)) as zone_couverture
from
    communes as c
join
    services as s
on
    st_contains(c.geom, s.geom)
where
    s.type = 'medecin'
group by
    c.code_insee, c.name;

          Je vais alors récupérer une liste de communes, avec le nombre de médecins dans chaque commune, et un objet géométrique (ici au format geojson), qui représente la zone de couverture globale des médecins dans la commune. Je peux ensuite renvoyer les résultats à une application cliente web utilisant OpenLayers par exemple, et afficher le tout sur une carte.

          Les géométries sont traitées de la même façon que les objets classiques de la base de données, et les possibilités de traitement et d'analyse sont tout aussi étendues.

        • [^] # Re: I beg your pardon?

          Posté par  (site web personnel) . Évalué à 9.

          Hello,

          en fait, ça sert à amener de la géométrie dans une base de données relationnelle. Traditionnellement, les SGBDR utilisent des objets de type alphanumérique. Du coup on retrouve classiquement des requêtes SQL du type "Sélectionne moi les personnes dont le revenu est supérieur à 5000€/mois, qui sont célibataires, qui n'ont pas d'enfants". Dans ce cas, on ne travaille qu'en croisant des valeurs et les opérateurs utilisés sont assez classiques (= ou différent de ou supérieur à ou opérateur logique).

          Dans le monde du spatial, on a d'autres besoins: "Sélectionne moi les maisons dont la surface fait moins de 150m2 et qui sont situées à moins de 300m d'un cours d'eau et en dehors d'un périmètre de plan de prévention des risques naturels inondation". Du coup, on utilise des opérateurs un peu différents genre: intersecte, est disjoint, touche, est contenu dans, etc. Tout cela implique d'utiliser des outils géométriques un peu différents des outils classiques. Mais la philosophie (le paradigme) reste le même: on souhaite interroger des données structurées et stockées dans une base de données. Rien de bien nouveau.

          Donc, pour globaliser à l’extrême, un cartouche spatial ne fait qu'ajouter les fonctionnalités de type géométrie à un SGBDR. Tout le reste fonctionne comme avant et c'est une force: il n'y a pas besoin de dispositif supplémentaire (donc pas d'autre langage de requête par exemple) et on peut travailler à la fois avec la géométrie mais aussi avec l'alphanumérique. On a donc des requêtes du type: Sélectionne moi les personnes dont le revenu est supérieur à 5000€/mois, qui sont célibataires, qui n'ont pas d'enfants et qui habitent une maison de moins de 150m2 située à moins de 300m d'un cours d'eau et en dehors d'un PPRI…

        • [^] # Re: I beg your pardon?

          Posté par  (site web personnel) . Évalué à 2.

          Cela sert à beaucoup de choses, en fait il s'agit plus ou moins d'ajouter un type «objet géométrique» aux types habituels dans les bases de données.

          Derrière les applications cartographiques comme Google Maps ou OpenStreetMap, il y a une base de donnée de ce genre.

          Toutes les personnes qui ont besoin de faire des inventaires incluant des éléments géographiques utilisent ce genre de données. Par exemple je travaille actuellement pour un cabinet d'experts et prépare une carte des nuisances sonores pour une ville de 400.000 habitants. On a donc des fichiers représentant les habitations avec leur hauteur, leur utilisation (habitat, bureaux, industries, écoles, hopitaux, etc.) et leur occupation, des informations sur le trafic routier associées au réseau routier, idem pour les avions, les trains et les bâteaux.

          Tu peux expérimenter avec genre d'outils avec QGis (un logiciel libre) et de nombreux organismes publient des données publiques dans des formats utilisables avec QGis. Il ne reste plus qu'à trouver les questions pour saisir l'intérêt de ce genre d'outils.

      • [^] # Re: I beg your pardon?

        Posté par  (site web personnel) . Évalué à 3.

        Donc c'est juste pour le plaisir de ne pas dire "module" ou "plugin", on est d'accord?

        • [^] # Re: I beg your pardon?

          Posté par  (site web personnel) . Évalué à 3.

          Oui, en fait on utilise indifféremment pour PostGIS «cartouche spatiale», «extension spatiale», «plugin» ou «module». C'est certainement le terme d'extension qui restera à terme, vu que c'est comme cela que s'appelle le mécanisme technique implémenté dans PostgreSQL 9.1.

      • [^] # Re: I beg your pardon?

        Posté par  (site web personnel) . Évalué à 3.

        Le cartouche désigne aussi le cadre situé généralement en bas et à droite d'un plan dans lequel on écrit la référence, la désignation, les indices de modifications et la date de mise à jour.
        Avec l'informatique, cet usage a tendance à s'estomper, mais avec les planches à dessin, c'était obligatoire.

        • [^] # Re: I beg your pardon?

          Posté par  . Évalué à 0.

          Euuuh : "couche" ???

          "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

          • [^] # Re: I beg your pardon?

            Posté par  . Évalué à 2.

            Sauf que "couche" a une signification bien particulière en SIG (traduction de "layer"), et que ça pourrait entraîner confusion.

        • [^] # Re: I beg your pardon?

          Posté par  . Évalué à 1.

          Avec l'informatique, cet usage a tendance à s'estomper, mais avec les planches à dessin, c'était obligatoire.

          c'est bien le problème, il n'y à aucune raison que ce ne soit pas obligatoire. Quand tu fais une carte, tu dois mettre des TOLES sinon tu t'en prends une :
          - Titre
          - Orientation
          - Légende
          - Échelle
          - Sources

          et normalement aussi auteur et date et je ne vois pas pourquoi le fait de passer à l'informatique libérerait d'une de ces contraintes qui sont absolument nécessaires pour comprendre une carte.

          • [^] # Re: I beg your pardon?

            Posté par  . Évalué à 4.

            Il n'y pas dit qu'on arrêtait de donner les informations mais de les mettre dans le cartouche. C'est typiquement ce qui va dans les métadonnées, pas sur une image.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: I beg your pardon?

              Posté par  . Évalué à 1.

              Il n'y pas dit qu'on arrêtait de donner les informations mais de les mettre dans le cartouche. C'est typiquement ce qui va dans les métadonnées, pas sur une image.

              qu'on le mette dans les meta-données c'est très bien, mais cela doit être sur la carte aussi sinon tu ne comprends rien !

              tu peux faire dire tout et son contraire avec une carte si tu ne sais pas d'où viennent les sources et ce que représente les éléments de la carte. D'ailleurs une carte, tu la fais pour représenter ce que TU veux montrer au lecteur, c'est un élément de communication, le choix d'une méthode de catégorisation des données modifie le rendu visuel et la compréhension du phénomène. Donc sans la légende sur la carte, tu es juste incapable de pouvoir interpréter ce que tu vois sur cette carte d'où l'obligation de le rendre visible sur l'image et pas seulement dans les méta-données.

          • [^] # Re: I beg your pardon?

            Posté par  (site web personnel) . Évalué à 2.

            Il manque le système de coordonnés dans ta liste…

  • # Tout mettre au même endroit...

    Posté par  (site web personnel) . Évalué à 7.

    Hello,

    l'élément important de cette version 2.0 est (selon moi), la gestion des rasters (bitmap) directement dans la DB. C'est une excellente fonctionnalité qui permettra de tout stocker au même endroit: vecteurs, rasters et données attributaires. Jusqu'à présent, il était obligatoire de gérer les rasters à part, c'est à dire dans un autre format. L'intérêt de tout mettre au même endroit est de faciliter la gestion et l'administration des patrimoines de données qui peuvent parfois être très variés et très riches. De plus, un seul dépôt permet de faciliter l'accès aux données des utilisateurs qui n'ont qu'un seul endroit à interroger pour récupérer leurs données. Enfin, c'est plus facile de croiser deux tables si elles sont dans la même DB.

    Même si on peut imaginer que, dans un premier temps, le support des rasters sera plus ou moins buggué et balbutiant en terme de fonctionnalités, c'est un très bon point. A noter que ce support était déjà implémenté dans les versions Beta depuis quelques temps ce qui laisse imaginer un niveau de stabilité correct. Enfin, il reste à diffuser ce support aux logiciels de SIG. GDAL semble utiliser les fonctionnalités raster de PostGIS depuis quelques années déjà. On peut penser que ça devrait permettre à des logiciels comme QGis de pouvoir déjà accéder à ce genre de données.

    Encore bravo aux équipes de développement de PostGIS pour simplifier la vie des géomaticiens (et de ceux qui bossent avec eux)…

  • # Commentaire supprimé

    Posté par  . Évalué à 1.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Petite précision

      Posté par  . Évalué à 3.

      C'est modifié mais ça me semblait clair vu qu'on parlait de la version 2.0 justement.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Petite précision

      Posté par  (site web personnel) . Évalué à 2.

      Dans tous les cas PostgreSQL 8.2 n'est plus supporté, et les différences entre PG 8.3 et 8.4 font qu'il est très fortement conseillé d'utiliser cette dernière si on veut rester dans la version majeure 8.
      Globalement avec PostgreSQL, on a toujours intérêt à utiliser la dernière version stable (sauf contraintes spécifiques bien sur, organisationnelle, de dépendance…).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.