Encore un article pense-bête pour moi et j'espère utile pour vous.

On me demande souvent lors d'export vers des instances officielles d'ajouter les coordonnées des points. Cela me parait toujours un peu étrange, mais nombre de base SIG stocke des coordonnées... De plus, on me demande en LAMBERT93/RGF93 ou en "coordonnées GPS", sûrement une façon de dire WGS84...

Alors voyons les méthodes

Je vais donc prendre une table en LAMBERT93/RGF93 (EPSG:2154) en exemple pour ajouter, ou remplir les champs x_l93,y_l93,x_wgs84,y_wgs84. Pas besoin d'expliciter qui contient quoi, si vraiment vous ne voyez pas, laisser un commentaire.

Dans QGIS

On passe par cette case rapidement pour rappelé quelques formules.

Dans la calculatrice de champs, on créé (ou mettre à jour) une colonne, je ne m'attarde pas puisque que l'on peut utiliser les formules :

On peut également les ajouter en colonne virtuelle, s'assurant ainsi de leur mise à jour continue. C'est ce que je préfère pour ne pas stocker les coordonnées dans la table, mais c'est lié à votre projet ou style et donc, si la table est utile à plusieurs et que les coordonnées sont demandées, on peut les inscrire en dur.

Dans POSTGIS

Colonnes générées

SI tout est (bien) pensé à la création de la table (ou même on peut rajouter ces colonnes après), on peut utiliser des colonnes générées de POSTGRESQL (GENERATED COLUMNS). Comment ça marche, ici en création :

CREATE TABLE public.point_x (
id serial4 NOT NULL,
geom public.geometry(point, 2154) NULL,
x_l93 numeric GENERATED ALWAYS AS (st_x(st_centroid(geom))) STORED,
y_l93 numeric GENERATED ALWAYS AS (st_y(st_centroid(geom))) STORED,
x_wgs84 numeric GENERATED ALWAYS AS (st_x(st_transform(st_centroid(geom), 4326))) STORED,
y_wgs84 numeric GENERATED ALWAYS AS (st_y(st_transform(st_centroid(geom), 4326))) STORED,
CONSTRAINT point_x_pkey PRIMARY KEY (id));

Ces colonnes ne sont pas modifiables directement, elles sont renseignées par défaut, et donc restent constamment à jour. Je trouve cela plutôt pratique et pas trop compliqué mais à faire dans chaque table.

Déclencheurs (TRIGGERS)

Autre méthode plus classique, le déclencheur (TRIGGER) qui permet de faire une action en fonction de la création, mise à jour etc, le réglage peut donc être plus fin et intégré à d'autres triggers déjà en cours. Pour cela, créons d'abord la fonction :

CREATE OR REPLACE FUNCTION create_coord()
RETURNS TRIGGER
LANGUAGE PLPGSQL
AS
$$
BEGIN
NEW.x_l93 = (ST_X(ST_centroid(NEW.geom)));
NEW.y_l93 = (ST_Y(ST_centroid(NEW.geom)));
NEW.x_wgs84 = (ST_X(ST_TRANSFORM(ST_centroid(NEW.geom),4326)));
NEW.y_wgs84 = (ST_Y(ST_TRANSFORM(ST_centroid(NEW.geom),4326)));
RETURN NEW;
END;
$$

Ensuite créer le déclencheur sur n'importe quelle table qui contient des colonnes x_l93,y_l93,x_wgs84,y_wgs84

CREATE TRIGGER modif_coord_crea_upd BEFORE
INSERT OR UPDATE ON
public.point_y FOR EACH ROW EXECUTE FUNCTION create_coord()

Le fait de mettre INSERT OR UPDATE indique que les colonnes se tiennent à jour, si on ne veut stocker que le point à la première saisie, enlever OR UPDATE.

Conclusion

Voilà, rien de très sorcier, mais plutôt pratique, j'avoue que je ne sais pas si une méthode est meilleure qu'une autre point de vue performance de base (mais à mon avis, c'est négligeable), ou quels sont les avantages-inconvénients détaillés des 2 méthodes.

J'ai également oublier d'expliquer que je m'affranchis de la géométrie de ma couche (point ou ligne ou polygone) en ne stockant que le centroïde (via ST_CENTROID), si on veut stocker d'autres coordonnées (point de départ, point spécifique...) il faudra modifier les formules.

Laisser un commentaire si vous avez d'autres méthodes ou amélioration à apporter à cet article. Merci