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 Médéric RIBREUX (site web personnel) . En réponse à la dépêche Sortie de PostGIS 2.0. É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…