Souscrire via RSSFOSS4G-fr : l’événement francophone majeure de la géomatique Open Source
Les 20, 21 et 22 mai sera organisé le premier événement francophone autour de la géomatique open source (FOSS signifiant Free et Open Source). Après l’événement FROG en 2013, la deuxième édition prend de l’ampleur : plus de conférences, des workshops (on dirait plutôt Travaux Pratiques en bon françois).
Pourquoi y aller ? Il existe de nombreuses bonnes raisons : rencontrer les développeurs (ils parlent une langue proche de la votre et sauront s’adapter) et discuter sur leurs travaux actuels et futurs, d’autres usagers des projets open source qui sauront partager leur point de vue, besoins et solutions qui vous intéresseront, des membres de la communauté OSGeo-fr et notamment des membres du bureau de l’association, des anciens membres du bureau.
Cet événement me fait vraiment penser à mon premier FOSS4G (international celui-là) à Lausanne en 2006 : de la technique mais pas trop et à mon niveau (à cette époque j’étais un vrai débutant et j’y ai beaucoup appris), un aperçu de ce qui se fait actuellement afin de me mettre à niveau sur le plan des usages actuels, une bonne ambiance et de la bonne humeur que j’apprécie toujours.
Le FOSS4G-fr c’est tout ca et en même temps ca sera complètement différent : car ce sera en français ! Et pour moi, ce sera le moment de partager ce que j’ai appris depuis ce fameux premier FOSS4G, de trouver de nouvelles idées, ce sera aussi, pour moi, la possibilité de discuter avec les développeurs des projets que j’affectionne.
Les présentations et travaux pratiques sont listés dans le programme, si je dois en retenir que quelques uns (donc forcément objectif et non exhaustif), commençons par les TP :
- Automatiser avec QGIS par Jean-Roc Morreales
- LizMap par Michaël DOUCHIN et Réné-Luc D’HONT
- TileMill par Sylvain Berochia
- Les plugins dans QGIS par Hugo Mercier
- Talend : François Prunayre Etienne Taffoureau et moi même
Je m’arrête là car je suis en train de tous les lister … J’oublie bien sur PostGIS avancé, MapServer/GeoServer et la directive INSPIRE, etc.
Les conférences auront lieu le 21 et 22 mai :
- OpenLayers 3
- MapServer 7.0
- geOrchestra
- des présentations sur des plugins QGIS
- GeoNetwork
- La plateforme SmartData du Grand Lyon
- OpenTripPlanner Analyst
- Import du cadastre dans une base PostGIS
- La topologie dans PostGIS : un cas d’utilisation
etc.
Notez deux conférences intéressantes et hors FOSS : nous aurons droit à deux conférences par directement lié au FOSS4G mais qui les impactent : Quelle expérience géographique à l’heure du géoweb ? par Thierry Joliveau et Évolutions européennes en cours sur INSPIRE par Marc Leobet.
Il me reste juste à vous dire de vous dépêcher de vous inscrire, l’année dernière le nombre d’inscrit a atteint la limite haute des possibilités ! Les sponsors sont prêts, l’organisation aussi, les petits fours aussi ou presque (car les repas du midi sont pris en charge). Passons quelques jours ensemble !
À très bientôt 😉
Et vous ? Vous faîtes quoi pour parler du FROG2013 ?
Au gré de mes déplacements je suis tombé sur cette devanture de magasin (en fait un club privé, tout le contraire du FROG) en Auvergne.
[GDAL-OGR] Mode ajout dans une base de données PostGreSQL
Il y a quelques temps je devais importer des données au format EDIGEO dans une base PostGreSQL/PostGIS existante. J’avais plusieurs fichiers THF à importer par conséquent je devais créer la table puis importer les fichiers les nus après les autres. Après lecture attentive de la documentation puis poser quelques questions sur la liste gdal, voici la méthode ainsi que les petites astuces qui font la différence.
Visualisation du problème
Puisque la table n’existe pas au premier fichier THF, il faut que la commande ogr2ogr s’en occupe puis, dans un deuxième temps, il faut que cette même commande ajoute les données. La doc est assez clair là dessus : il faut lancer deux commandes l’une après l’autre (en fait seules quelques options sont différentes) :
ogr2ogr -gt 65536 -f "PostgreSQL" "PG:dbname=test host='localhost'" -lco "GEOMETRY_NAME=the_geom" -lco "SCHEMA=test" -lco "OVERWRITE=YES" -nln EDIGEO_parcelle E0001.THF PARCELLE_id
Cette commande s’exécute sans problème. Les options utilisées ici sont les suivantes :
- -gt 65536 : permet de grouper les géométries par groupe de 65 536 géométries avant de les commiter. Cela évite de commiter les géométries les unes après les autres. La valeur utilisée est celle préconiser par la documentation.
- -lco « SCHEMA=test » : importer les données dans un schéma particulier.
- -lco « GEOMETRY_NAME=the_geom » : totalement inutile mais j’aime bien avoir une cohérence dans mes noms de colonnes géométriques.
- -lco « OVERWRITE=YES » : obligatoire quand on fait plusieurs essaie ou quand la table existe déjà pour cause d’import déjà réalisé. Cette option indique que la table sera écrasée (détruite puis recrée).
- -nln EDIGEO_parcelle : donner un nom différent à la table que l’on va créer. Notez le mélange de majuscules et de minuscule, nous en reparlerons plus tard.
La deuxième commande que j’ai testé pour ajouter les données à une table existante esty celle-ci :
ogr2ogr -append -update -gt 65536 -f "PostgreSQL" "PG:dbname=test host='localhost'" -lco "GEOMETRY_NAME=the_geom" -lco "SCHEMA=test" -nln EDIGEO_parcelle E0002.THF PARCELLE_id
Et là, ca marche beaucoup moins bien car je reçois ce message :
ERROR 1: Layer test.edigeo_parcelle already exists, CreateLayer failed. Use the layer creation option OVERWRITE=YES to replace it. ERROR 1: Terminating translation prematurely after failed translation of layer PARCELLE_id (use -skipfailures to skip errors)
Et les logs de PostgreSQL montrent que cela ne provient pas de la base de données :
Postgresql log file shows: 2013-03-06 15:35:44 CET LOG: could not receive data from client: Connection reset by peer 2013-03-06 15:35:44 CET LOG: unexpected EOF on client connection
Compréhension du problème et solution
En regardant les logs d’un peu plus près, voici ce que l’on y trouve :
- le nom de la table créée est test.edigeo_parcelle, ce qui est incorrecte en regard de la commande que j’ai lancé (le nom de la table aurait dû être EDIGEO_parcelle.
- une commande est réalisée lors du mode ajout et celle-ci ne cherche pas la table dans le schéma test mais dans le schéma public.
Ces deux problèmes peuvent être réglés de plusieurs manières différentes.
La solution « fainéant »
Résumons la par « Ah ben ca marche pas avec des majuscules et dans un schéma autre que le schéma public, tant pis ». La solution ici est de mettre le nom de la table en minuscule (bonne pratique) et celle-ci dans le schéma public (pas bien !).
La solution dite de « contournement »
Elle s’approche de la première car elle n’utilise pas les options nécessaires (et ajoutées pour) ce cas de figure et elle ne sert qu’au deuxième problème (celui du schéma) :
ogr2ogr -append -update -gt 65536 -f "PostgreSQL" "PG:dbname=test host='localhost'" -nln test.edigeo_parcelle E0002.THF PARCELLE_id
Notez ces modifications :
- -lco « SCHEMA=test » et -lco « GEOMETRY_NAME=the_geom » ont été supprimés car inutile. Les options -lco ne sont pas utilisées en mode append ou update (ben oui le c de lco est pour « création », logique !).
- le nom de la table dans l’option -nln a été modifié en test.edigeo_parcele : tout en minuscule et ajout du schéma
La solution qui utilise les bonnes options
Comprenons bien les problèmes. Un premier problème vient du fait que le nom de la table que nous souhaitons créer contient des majuscules qui sont transformés en minuscule. Le deuxième problème vient du fait que nous utilisons une option de création pour définir le schéma dans lequel insérer des données alors que nous somme en mode append/update.
Nettoyage des noms de couches/table, colonne
Le pilote PostgreSQL dans GDAL/OGR contient un système de nettoyage des valeurs données lors de la création d’une couche. Cette option se nomme « LAUNDER » et est définie dans la page du pilote : http://gdal.gloobe.org/ogr/formats/pg.html (en français) :
Elle peut être définie à *YES* pour forcer les nouveaux champs créés sur cette couche à avoir les noms de champs « nettoyés » dans une forme compatible avec PostgreSQL. Cela convertie la valeur en minuscule ainsi que certains caractères spéciaux comme « – » et « # » en « _ ». Si la valeur *NO* est utilisée les noms exacts seront préservés. La valeur par défaut est *YES*. Si activé le nom de la table (couche) sera également nettoyé.
Si l’on souhaite garder nos majuscules il faut définir cette option à « NO ».
Définition du schéma en mode append/update
Lorsque nous somme en mode append ou update, nous ne somme pas en mode de création. C’est peu de le dire, c’est évident, mais au final on n’en saisit pas toujours les conséquences : les options de création ne nous serons d’aucune utilité ! Heureusement il y a une possibilité : le paramètre « active_schema » dans la chaîne de connexion. Notre commande devient alors :
ogr2ogr -append -update -gt 65536 -f "PostgreSQL" "PG:dbname=test host='localhost' active_schema=test" -nln edigeo_parcelle E0002.THF PARCELLE_id
Merci à Even Rouault pour son aide sur la liste.
FROG : après les conférences, participer aux projets
Le FROG dont j’ai déjà parlé il y a peu organise après la journée dédiée aux conférences et présentations trois jours de code sprint. Ce terme parait très technique et orienté développeur (peut-être que cela peut l’être parfois) mais en ce qui concerne le FROG cela ne l’est pas du tout.
Ces trois jours sont ouvert à tous et toutes qui désirent mettre un pied dans le monde des contributeurs à un projet Open Source. Vous y verrez comment il est simple d’y participer. Les projets sont pour le moment orienté traduction (relecture, amélioration de la doc). Plusieurs projets sont pour le moment annoncé (bien qu’officieusement pour le moment, attendez vous à un comming out d’ici le 10 juin) : MapServer, QGIS, GvSIG, OSGeoLiveDVD, GDAL/OGR, etc.
La page sur le site de la conférence vous donnera quelques détails : http://frog.osgeo.fr/Sprint
FROG : la Rencontre de l’OSGeo-fr attend vos contributions !
L’OSGeo-fr organise une rencontre en juin juste avant les Rencontres SIG La Lettre dont l’objectif est de permettre les échanges entre les utilisateurs, les contributeurs, les décideurs, et tout ceux qui s’intéresse de près ou de loin aux projets open source en géomatique.
C’est la première rencontre de ce type en France : elle est spécifique aux outils open source, elle n’est pas dédié à un projet comme cela avait été le cas fin 2011 à Paris, elle propose 2 cycles de conférence dans deux salles séparées. C’est une occasion unique à la fois pour se voir et échanger. Je suis très heureux à l’idée que cette rencontre a lieu dans quelques mois ! Nous en parlons depuis si longtemps. Les sponsors ne se sont pas montré trop timide, regardez la page des sponsors pour vous donner des idées :
- IGN en sponsor Or (unique sponsor de ce niveau) ;
- Mappy (ceux qui font des cartes et des itinéraires) ;
- Camptocamp (dois je vous les présenter ? Si OpenLayers, SDI, MapFish ne vous disent rien, il faut vraiment venir à la conférence)
- Oslandia (PostGIS et 3D l’un à côté de l’autre et l’un dans l’autre) ;
- Géomatys (GeoToolkit la boîte à outils en Java) ;
- NeoGeo (faîtes un tour sur leur blog pour vous prouver que l’on n’a pas à faire à n’importe qui) ;
- Et il y a les bronzes, plus petits certes, mais pas sans moins de valeur :
- 3LIZ
- CartoExpert
- Thinking GIS
Rien que ca ! J’avoue que l’on commence à faire les fiers au sein de l’OSGeo-fr 🙂
Maintenant que les sponsors sont au rendez-vous, nous attendons vos contributions : test, use case, projet de développement (QGIS, OpenLayers, GvSIG, MapServer, GeoServer, GeoToolsKit, GDAL/OGR, et tout ceux dont je pense pas). Vous, vous les utilisez comment ces projets ? Vous voyez comment l’avenir de la géomatique Open source ?
Bref, je suis impatient de voir ce programme sur deux sessions (oui j’insiste) pour un tarif moins élevé qu’un repas à Paris (sauf qu’ici le repas, les croissants et peut-être même l’apéro est compris dans le prix) !
À très vite.
PS : oui je suis content que ce projet ait lieu, j’insiste encore pour remercier tout les sponsors qui se sont activé pour nous rejoindre dans cette aventure.
Google Fusion Table, OGR et QGIS
Google Fusion Table, OGR et QGIS : trois projets a priori indépendant, même si nous savons que derrière QGIS se cache la bibliothèque GDAL/OGR. Mais celle-ci est généralement sous estimée, notamment ses possibilités de virtualisation de données (raster ou vecteur). Entre autre chose cela permet à QGIS de pouvoir lire tous les formats de données gérés par GDAL/OGR même si elles ne sont pas listés dans les formats gérés ou qu’elles demandent des étapes intermédiaires (comme pour le format NetCDF).
Google Fusion Table (GFT) est une application Google lié plus ou moins à leur Google Doc, le tableur en particulier. En effet Google propose une feuille calc dans laquelle nous pouvons définir plusieurs colonnes, donc une spéciale, appelée Location qui contient une adresse ou une géométrie (KML par exemple).
GDAL/OGR gère le format GFT depuis sa version 1.9 (toute récente). Cet article a pour but de présenter quelques fonctionnalités et comment utiliser, simplement, un GFT au sein de QGIS (ou de MapServer bien sur).
Il y a quelques temps j’ai créé une feuille test_shapefile composée de quelques colonnes : nom, prénom, location (une adresse), et quelques informations diverses. Je peux me connecter à cette feuille via ogr comme cela :
[sourcecode language= »bash »]
yves@poseidon-vb:~$ ogrinfo -ro "GFT:email=yjacolin@gmail.com password=XXXXXX"
INFO: Open of `GFT:email=yjacolin@gmail.com password=XXXXXX’
using driver `GFT’ successful.
1: test_shapefile
[/sourcecode]
Mais entrer un mot de passe en clair n’est pas très sécurisé, Google proprose de récupérer une clé d’authentification, que l’on peut modifier enfin je suppose) :
[sourcecode language= »bash »] $ ogrinfo –config CPL_DEBUG ON "GFT:email=yjacolin@gmail.com password=XXXXXX" HTTP: Fetch(https://www.google.com/accounts/ClientLogin) HTTP: These HTTP headers were set: Content-Type: application/x-www-form-urlencoded GFT: Auth key : MACLéICI-LONGUE_DE_PLUSIEURS_CARACTèRES GFT: Run SHOW TABLES [..] [/sourcecode]
Puis, sous linux, nous utilisons une variable d’environnement pour définir la clé (d’autres possibilités existent en plus du mot de passe en clair et de la clé d’authentification, référez vous à la documentation du pilote GFT de GDAL/OGR (voir bibliographie plus bas) :
[sourcecode language= »bash »]</code> export GFT_AUTH=MACLéICI-LONGUE_DE_PLUSIEURS_CARACTèRES[/sourcecode]
On teste la prise en compte de la clé d’authentification :
[sourcecode language= »bash »]</code>ogrinfo -ro "GFT:"[/sourcecode]
J’exporte ma table en shapefile :
[sourcecode language= »bash »]ogr2ogr -f "Esri Shapefile" test_shapefile "GFT:tables=1jfYFX051Gbq5JU7Fd-Yxd_Q4aPDslDwDypsm3VU"[/sourcecode]
Puis j’importe une couche – différente – au format shapefile :
[sourcecode language= »bash »]</code>ogr2ogr -f GFT "GFT:" point_etude.shp[/sourcecode]
Pour visualiser ces données dans QGIS ou MapServer j’ai besoin de virtualiser ma couche GFT au moyen du format VRT vecteur.
Création du fichier vrt :
[sourcecode language= »xml »]
<OGRVRTDataSource>
<OGRVRTLayer name="point_etude">
<SrcDataSource>GFT:</SrcDataSource>
<SrcLayer>1SWEVgpny8Ojh-dzJEURhhEJVVa44Vnitey3DRhk&pli=1</SrcLayer>
<LayerSRS>WGS84</LayerSRS>
</OGRVRTLayer>
</OGRVRTDataSource>
[/sourcecode]
puis j’utilise ce fichier vrt pour vérifier que je me connecter correctement à ma couche GFT :
[sourcecode language= »bash »]
ogrinfo -so point_etude.vrt point_etude
INFO: Open of `point_etude.vrt’
using driver `VRT’ successful.
Layer name: point_etude
Geometry: Unknown (any)
Feature Count: 1500
Extent: (-5.974657, 40.712886) – (9.572308, 52.068039)
Layer SRS WKT:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9108"]],
AUTHORITY["EPSG","4326"]]
ID: Real (0.0)
geometry: String (0.0)
[/sourcecode]
Les géométries sont affichées comme celles-ci :
[sourcecode language= »bash »]
OGRFeature(point_etude):1425
ID (Real) = 1423
geometry (String) = <Point><coordinates>-3.443027539873455,47.169053485738431</coordinates></Point>
POINT (-3.443027539873455 47.169053485738431)
OGRFeature(point_etude):1426
ID (Real) = 1424
geometry (String) = <Point><coordinates>8.270853712116637,45.104331014323307</coordinates></Point>
POINT (8.270853712116637 45.104331014323307)
OGRFeature(point_etude):1427
ID (Real) = 1425
geometry (String) = <Point><coordinates>3.631323682505393,46.460888984293931</coordinates></Point>
POINT (3.631323682505393 46.460888984293931)
[/sourcecode]
Enfin l’export fonctionne :
[sourcecode language= »bash »]ogr2ogr -f "Esri Shapefile" test.shp point_etude.vrt point_etude[/sourcecode]
La visualisation au sein de QGIS se fait simplement en ouvrant le fichier vrt comme tout format de données vecteur.
Conclusion
Le format Google Fusion Table est un format intéressant, l’interface avec un format vrt permet de s’y connecter avec toute application s’appuyant avec GDAL/OGR comme QGIs ou MapServer mais le principale intérêt aurait été de pouvoir géocoder ses adresses au moyen de GFT et de pouvoir s’en service comme source de données. Malheureusement GFT ne permet que de géocoder ses adresses et de les visualiser dans une carte Google Map ou Google Earth. Il est impossible de sauver le géocodage dans une colonne dans un format WKT par exemple.
Si cette limitation ne vous pose pas de problème, vous pouvez stocker vos couches sur les serveurs de Google au format GFT et les lire dans QGIS/MapServer.
Bibliographie
- Le pilote GFT dans OGR : version anglaise ou la version française
- Le pilote VRT dans OGR : version anglaise ou version française
- Guide du développeur de Google Fusion Table
Personnalisation de QGIS : présentation de quelques méthodes simples
QGIS est constitué d’un coeur sous forme de bibliothèque dont l’interface graphique n’est qu’une des manières de l’utiliser. Le langage Python, largement utilisé pour les extensions, permet d’utiliser ce cœur pour créer ses extensions ou une autre application, totalement différente. Avant d’en arriver à ce niveau de personnalisation il existe plusieurs fonctionnalités qui permettent de modifier l’interface de QGIS. C’est de ces méthodes que je vais parler.
Je ne parlerais pas des possibilités de personnalisation des formats de données que l’on peut ouvrir avec QGIS, ou les paramètres de personnalisation lors de la sauvegarde d’un fichier (déjà parlé ici), ni de la personnalisation des projections, de la localisation des barres d’outils. Non il va s’agir d’utiliser les possibilités de QGIS pour simplement modifier le comportement par défaut de QGIS lorsqu’on clique sur une seule feature avec l’outil « identifier », faire en sorte que les outils et fonctions superflus ne s’affichent pas lors du lancement de QGIS et enfin de personnaliser le formulaire d’édition.
Formulaire d’édition des features
Dans les options de QGIS vous trouverez la possibilité d’afficher le formulaire par défaut lorsque vous cliquez sur une feature avec la fonction « identifier » (représenté par une flèche avec un bouton « i » avec un fond bleuté). Il y a alors deux types de fonctionnement : le premier lorsqu’on clique sur plusieurs features (en fait quand il y a plusieurs feature qui se superposent) une fenêtre s’ouvre et liste les attributs des features. Le deuxième fonctionnement, et c’est le plus intéressant, apparaît lorsqu’on clique sur une seule feature. Un formulaire d’édition apparaît et celui-ci permet de modifier les attributs si nous somme en mode édition.
La capture d’écran suivante montre les deux comportements. Les deux features sur lesquels j’ai cliqué sont entouré de rouge (on remarque que les multiples-features sélectionnées et qui donnent la fenêtre de gauche sont celles situées vers le bas). La fenêtre de droite est le fameux formulaire d’édition de la feature. Nous verrons un peu plus bas comment personnaliser ce formulaire très facilement.
Personnalisation des outils affichés
Cette fonctionnalité est nouvelle et n’est pas encore disponible dans la version stable actuelle, elle le sera dans la version 1.8.0. Un nouvel item fait son apparition dans le menu Options : « Paramétrage ». Celui-ci parait un peu obscure mais il s’agit d’un paramétrage pour choisir les menu, boutons et toolbars qui vont s’afficher dans QGIS. La fenêtre permet de choisir ce que vous désirez activer ou non. Il y a deux possibilités : décocher les items dans la liste déroulante ou bien utiliser la fonction « attraper les widgets dans l’interface » (traduction de mon fait).
Après avoir coché et décoché les cases désirées, vous cliquez sur le bouton « Appliquer ». À la prochaine ouverture de QGIS seules les barres d’outils, menu et boutons cochés seront affichés. Vous pouvez aussi sauver le fichier sous forme de fichier ini pour le charger dans une autre instance de QGIS. Voici ce que donne un exemple de personnalisation, à l’extrême :
Notez que pour revenir en arrière vous devez lancer qgis avec l’option –nocustomization et réinitialiser le paramétrage.
Créer son formulaire d’édition
QGIS propose la possibilité de créer son propre formulaire qui sera affiché lors de l’édition de la feature. Cela peut paraître compliqué mais c’est en fait très simple. Vous devez avoir qt4designer installé sur votre système. Lancez le, créez votre projet (celui par défaut conviendra parfaitement). Créez le formulaire en vous aidant des widgets sur la gauche et n’oubliez pas de les configurer avec la partie droite. Attention, il est important de données le nom du champ auquel le widget se rapporte à ce widget. C’est de cette manière que se fera le lien entre le champ du formulaire et le champ de la table attributaire. Voici ce que donne le mien :
Puis dans les propriétés de la couche, entrez le chemin vers le fichier formulaire créé précédemment (l’extension des formulaires créés avec qt4designer est .ui).
Enfin entrez en mode édition et éditez une feature :
Mise à jour de la documentation de GDAL en français
L’annonce a déjà transpiré sur Twitter mais il faut l’officialiser : la doc de GDAL en français a été mise à jour. Celle-ci contient non seulement la traduction de la doc de GDAL mais également de nouveaux chapitres originaux : Python, FAQ, et d’autres traductions de commandes utiles et complémentaire à celles de GDAL-OGR.
La doc a été passée en restructured text permettant une export en HTMl et PDF à partir de la version Softlibre (et non celle du wiki de GeoRezo.net) afin de faire évoluer la licence vers une licence proche de celle de GDAL : Licence Creative Common BY.
La version HTML est disponible à cette adresse : http://gdal.gloobe.org/index.html
Participation aux communautés
GeoRezo.net était à la base une liste de diffusion. Au fil du temps le site a évolué vers un portail complet proposant un forum, plusieurs listes, un wiki, des blogs, etc. Ce qui reste constant depuis sa création est sa communauté et son animation.
L’objet de cet article est de partager quelques informations sur les communautés : qui sont les contributeurs ? Pourquoi contribuent ils ? Comment évolue ces contributions ?
Lire plus »
Éditer des géométries avec un service WFS-T avec QGIS
Un message passé inaperçu il y a quelques mois annoncé l’amélioration du plugin WFS dans QGIS. En effet celui-ci permet « maintenant » d’éditer les données vectoriels et de les sauver par l’intermédiaire d’un service WFS-T.
Pour cela il suffit d’activer le plugin WFS (installé avec QGIS par défaut) puis de configurer un service WFS comme vous le faîte généralement pour de la simple visualisation. Si le flux permet l’option « transactionnel » (le T de WFS-T) alors l’icône « Basculer en mode édition » (icône représentation un stylo bleu) sera activé.
Le mode édition fonctionne exactement pareil que pour une couche vecteur normale. À la fin de l’édition vous pouvez simplement sauver vos modifications et rebasculer en mode normal.