Pages: 1
- Sujet précédent - Ambiguité sur la définition de projection d'une table PostGis - Sujet suivant
#1 Fri 01 February 2008 13:44
- Christophe Brun
- Juste Inscrit !
- Lieu: Bois-Colombes
- Date d'inscription: 19 Apr 2006
- Messages: 6
Ambiguité sur la définition de projection d'une table PostGis
Bonjour à tous,
J'utilise PostGis depuis quelques mois et j'avoue ne pas très bien comprendre un point relatif à la projection attribuée à une table (rapport entre le srid de la colonne géométrique d'une table et les coordonnées renvoyées par la fonction asewkt(The_Geom).
Concrêtement je dispose de tables shape en WGS84 (EPSG:4326) que je veux importer dans PostGis mais que je veux exploiter en LambertIICarto (EPSG:27582).
Si je paramètre shp2pgsql avec le srid correspondant à la projection voulue, soit 27582, j'ai bien une table référencée dans PostGis en 27582 mais les coordonnées de mes points ne sont pas transformées et restent en Long/Lat., même si par la suite j'applique une transformation (ST_Transform).
1ère conclusion : Passer en paramètre de shp2pgsql le srid d'origine, soit 4326 dans mon exemple.
Je dois donc transformer ma table une fois chargée et réferencée en WGS84. Après pas mal de tests, je me rends compte que pour obtenir une table en 27582, avec des coordonnées en mètres LambertII, je dois créer une nouvelle table
Code:
CREATE TABLE matable27582 as SELECT * ,ST_Transform(The_Geom,27582) FROM matable4326;
puis mettre à jour ma table geometry_columns pour indiquer la nouvelle colonne géométrique à prendre en compte.
Existe-t-il une meilleure méthode ? Peut-être avec un UPDATE de la colonne géométrique mais en supprimant la contrainte
CONSTRAINT enforce_srid_the_geom CHECK (srid(the_geom) = 4326)
générée par shp2pgsql ?
Merci d'avance pour vos commentaires car je suis un peu 'perturbé' par le fait qu'une table peut-être définie dans un système de projection différent des coordonnées qui composent ses objets.
Bon week-end à tous
Hors ligne
#2 Fri 01 February 2008 14:48
Re: Ambiguité sur la définition de projection d'une table PostGis
Bonjour,
Ton questionnement revient à demander pourquoi on peut créer un fichier .prj d'un jeu de données au format shape et y mettre une projection qui ne correspond pas à la projection réelle.
La réponse est qu'il n'est pas possible de déterminer la projection automatiquement, du moins sans utiliser ce fichier .prj.
Quand tu importes une données à partir d'un shapefile, tu lui définies la projection et la localisation du fichier, d'autres paramètres peuvent être modifié aussi (le nom du champ géométrique par exemple).
Votre procédure m'a l'air correcte, en prenant en compte la conclusion 1, bien sur . Autres solutions : crée un champ géométrique :
Code:
SELECT addGeometryColunm('matable4326','the_geom_l2e',27572,'MULTIPOLYGON',2);
Puis mettre à jour ce champ :
Code:
UPDATE matable4326 SET the_geom_l2e = ST_tranform(the_geom,27572);
Tu auras une table avec plusieurs champ géoémtrique avec une projection chacun. Note que tu peux faire quelque chose de similaire en créant un champ géométrie de type POINT pour créer le centroide des polygones.
Y.
Yves Jacolin, bénévole de l'association GeoRezo.net, agit au nom et pour le compte de l'association - Partageons ce qui nous départage !! - GeoRezo vous aide ? Aidez GeoRezo !
Hors ligne
#3 Fri 01 February 2008 16:21
- Christophe Brun
- Juste Inscrit !
- Lieu: Bois-Colombes
- Date d'inscription: 19 Apr 2006
- Messages: 6
Re: Ambiguité sur la définition de projection d'une table PostGis
Merci !
Cette méthode est plus simple et plus légère que de créer une nouvelle table. Je récupère bien mes coordonnées en Lambert et, cerise sur le gâteau, uDig se sert de cette nouvelle colonne pour représenter la table (magique ? il pourrait aussi bien se servir de The_Geom...?).
Donc shp2pgsql ne permet donc pas de changer de projection, c'est bien ça ? J'insiste parce que je trouve des infos pas toujours en accord sur ce point.
Pour le fichier .prj (qui m'est fourni par l'éditeur de mes tables), je ne comprends pas vraiment de quelle manière il est utilisé car j'ai fait un test en le supprimant pour une table et n'ai pas eu de différence lors du chargement.
Merci pour attention sur ces questionnements.
CB
Hors ligne
#4 Fri 01 February 2008 16:48
Re: Ambiguité sur la définition de projection d'une table PostGis
Bonjour,
Donc shp2pgsql ne permet donc pas de changer de projection, c'est bien ça ?
Exactement.
Je ne comprends pas vraiment de quelle manière il est utilisé car j'ai fait un test en le supprimant pour une table et n'ai pas eu de différence lors du chargement.
Normal, shp2pgsql ne s'en sert pas à mon avis. Certains logiciels s'en servent et c'est plus logique
Y.
Yves Jacolin, bénévole de l'association GeoRezo.net, agit au nom et pour le compte de l'association - Partageons ce qui nous départage !! - GeoRezo vous aide ? Aidez GeoRezo !
Hors ligne
#5 Fri 01 February 2008 19:13
- Guillaume Sueur
- Participant assidu
- Lieu: Toulouse
- Date d'inscription: 23 Sep 2005
- Messages: 331
- Site web
Re: Ambiguité sur la définition de projection d'une table PostGis
Le -s de shp2pgsql ne sert qu'à spécifier le SRID de la table, pas à en
vérifier la cohérence avec le jeu de données.
pour charger un shape dans postgis tout en le reprojetant, il vaut mieux
utiliser ogr2ogr :
ogr2ogr -overwrite -s_srs "EPSG:4326" -t_srs "EPSG:27572" -f PostgreSQL
PG:"host=serveur user=postgres password=postgres dbname=nom_base"
fichier_shape.shp -lco LAUNDER=yes -lco DIM=2 -lco
GEOMETRY_NAME=the_geom -lco PRECISION=NO -nln nom_table_a_creer
si la table créée n'est pas référencée avec un SRID=27572, alors ajouter
à la commande un -a_srs "EPSG:27572"
explications :
-s_srs : SRID de la donnée source
-t_srs : SRID cible de la transformation
-a_srs : déclaration du srid de la donnée cible, sans transformation.
équivaut au -s de shp2pgsql.
mais ogr2ogr ne crée pas d'index spatial, donc ne pas oublier d'en
ajouter un ensuite !
Guillaume
Hors ligne
#6 Thu 31 July 2008 16:07
- NyPon
- Participant actif
- Date d'inscription: 3 Nov 2008
- Messages: 111
Re: Ambiguité sur la définition de projection d'une table PostGis
Bonjour,
j'ai une question concernant le SRID d'une table sous postgis,
j'ai fait une contrainte de vérification qui force le SRID : srid(the_geom)=27572 sur la table parcelle.
pb : dès que j'essaie d'intégrer des polygones par SQL, il me dit que c'est pas possible car cela viole la contrainte.
quand je dessine une parcelle dans qgis, dans la couche parcelle, il ne veux pas sauver pour la même raison.
quand je l'enlève, il n'y plus de problèmes. la question c'est:
est-ce grave si je continue à travailler en enlevant la contrainte ?
cordialement,
Dernière modification par nponzo (Thu 31 July 2008 16:07)
Hors ligne
#7 Thu 31 July 2008 17:10
Re: Ambiguité sur la définition de projection d'une table PostGis
Bonjour,
Je pense qu'il y a un problème de projection dans votre client (QGIS par exemple), si les données sont dans une autre projection cela peut poser problème. Je pense que tu vas au devant de problèmes si tu l'enlèves.
Y.
Yves Jacolin, bénévole de l'association GeoRezo.net, agit au nom et pour le compte de l'association - Partageons ce qui nous départage !! - GeoRezo vous aide ? Aidez GeoRezo !
Hors ligne
Pages: 1
- Sujet précédent - Ambiguité sur la définition de projection d'une table PostGis - Sujet suivant