Discussion :

[yo_haha]

Bonjour,

J'ai créé une table avec Postgresql. J'ai ajouté à cette table une colonne 'geom' de type POINT (PostGIS) et de dimension 2 avec la fonction addgeometrycolumn(). J'ai créé des enregistrements dans cette table sans toucher au champ geom. J'ai voulu remplir les champs geom avec la requête

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

UPDATE client SET geom=st_geomfromewkt('POINT(45 50)');

et j'ai obtenu l'erreur suivante :
la nouvelle ligne viole la contrainte de vérification « table » de la relation « enforce_srid_geom »

Auriez-vous une idée de ce qui se passe ?

[xavier-Pierre]

bojnour le srid correspond à un système de référence spatiale(http://en.wikipedia.org/wiki/SRID),les coordonnées de ton point ne correspondent pas à ce "srid", pour tester postgis tu peux à la limite supprimer la contrainte portant sur le srid (d’après les coordonnées de ton point tu n'as pas besoin de srid)

[yo_haha]

Merci pour votre réponse rapide.
J'avais même testé avec la projection conique conforme Lambert 1 et un point de coordonnées (601000, 201000) et ça me donnait la même erreur.

[SQLpro]

C'est vous qui n'avez pas compris ce qu'est une dimension !
Lisez l'article que j'ai écrit sur la manipulation des SIG dans SQL : http://blog.developpez.com/sqlpro/p9...n-geographiqu/

et notamment :

6.3 - Méthodes communes
[...]
Dimension() : Integer
Retourne la dimension spatiale de l’objet de 0 à 2 (un point étant de dimension 0, une ligne 1, un polygone 2…)

A +

[yo_haha]

D'accord merci. Je vais essayer avec la dimension 0. Mais n'y a-t-il pas une redondance ? Pour créer une colonne spatiale, il faut préciser la dimension et le type géométrique 'POINT' dans mon cas?

[SQLpro]

NON !
Le standard OGC prévoir que le type est GEOMETRY ou GEOGRAPY (avec donc en sus un SRID) mais l'utilisation de addgeometrycolumn() pour un type plus précis est un gadget PostGreSQL pour alimenter une table système des colonnes géométriques....
Mieux vaut passer par une contrainte CHECK sur un type GEO que par ce genre de gadget !

A +

[yo_haha]

Si j'ai bien compris, il vaut mieux utiliser le type GEOMETRY + dimension 0 qu'utiliser le type POINT.
Et ne pas utiliser addgeometrycolumn() mais ajouter un champs normal (texte ?) et mettre une contrainte check pour vérifier que c'est une GEOMETRY ? Dans ce cas, faudrait-il remplir la table geometry columns manuerllement ?

[SQLpro]

Type GEOMETRY + contrainte CHECK.
Alimentation manuelle de la table geometry_columns si besoin est !
Je comprend pas votre "champs text" (au passage dans les SGBDR les "champs" ça n'existe pas. Soyez clair et précis. On parle de colonne dans une table !)

A +

[yo_haha]

Ok merci je comprends maintenant.
Mes enseignants, par contre, conseillent de passer plutôt par la fonction addgeometrycolumn() qui pour vous est un "gadget" Postgresql. Donc pour vous, c'est mieux de passer par les standards OGC qu'utiliser des gadgets. Juste pour récapituler.

Merci.

[SQLpro]

OUI, chaque fois qu'il y a des normes (et le langage SQL est une norme ISO) ou à défaut un standard (et la partie SIG de PostGreSQL, comme celle de SQL Server reposent sur le standard OGC), il vaut TOUJOURS mieux se reposer dessus, sauf dans le cas ou la particularité apporte un avantage certains, mais c'est au risque d'une mauvaise interopérabilité qui peut vous péter au nez à retardement....

Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p9...er-les-normes/

PS : je suis moi même enseignant, auteur du livre sur SQL, le plus vendu à ce jour en français (et vous y trouverez un chapitre de 30 pages sur les SIG en SQL) mais aussi et surtout professionnel !

A +