Évolutions fonctionnelles georchestra - geocontrib'. Recherche d'éléments techniques / Functional developments in georchestra - geocontrib'. Research technical elements

[BERAULT Florent]

Bonjour à toutes et tous,

 

A la MEL nous utilisons la suite geOrchestra en tant que plateforme open data et bientôt plateforme data territoriale.

Nous intégrons le module géocontrib’ comme brique permettant la saisie et la mise à jour de certaines données sur le territoire, notamment de la part des communes. (cas d’usage éclairage public, signalement espace public etc.).

 

Je souhaite faire évoluer les fonctionnalités de géocontrib’ et permettre de restreindre la lecture et la mise à jour des données selon le territoire de compétences du user. Pour cela je souhaite que géocontrib utilise les attributs ou informations contenu dans la console de geOrchestra et les informations relatives aux users.

 

Geo2FFrance avait présenté un développement similaire sur Mapstore (réalisé par JDEV) : https://www.georchestra.org/public/geocom2024/presentations/jour_2/10%20-%20NR%20-%20ZAE%20Hauts%20de%20France.pdf

 

Je suis à la recherche des spécifications techniques ou de tout élément plus précis permettant de faciliter les développements à venir.

 

Merci d’avance pour vos réponses et retours en espérant avoir choisi le bon canal (si ce n’est pas le cas je m’en excuse par avance)

 

 

Hello everyone,

 

At the MEL (Lille European Metropolis), we use the geOrchestra suite as an open data platform and soon as a territorial data platform.

 

We integrate the geocontrib’ module as a component enabling the entry and updating of certain data about the territory, particularly from municipalities (use cases such as public lighting, reporting public spaces, etc.).

 

I would like to develop the functionalities of geocontrib’ and allow users to restrict the reading and updating of data based on their area of ​​responsibility. To do this, I would like geocontrib to use the attributes or information contained in the geOrchestra console.

 

Geo2FFrance presented a similar project on Mapstore (developed by JDEV): https://www.georchestra.org/public/geocom2024/presentations/jour_2/10%20-%20NR%20-%20ZAE%20Hauts%20de%20France.pdf

 

I am looking for the technical specifications or any more precise information that would facilitate future development.

 

Thank you in advance for your answers and feedback, hoping I've chosen the right channel (if not, I apologize in advance).

 

 

Florent

 

Florent BERAULT
chargé de mission mutualisation de la donnée
Numerique Secretariat general et administration
2, boulevard des Cités Unies - CS70043 - 59040 Lille Cedex T.+33 (0)3.20.21.65.48 - P.

 

 

[gaetan....@gmail.com]

Bonjour Florent,

Il y a plusieurs sujets en lien avec ton message.

1. Evolution dans le coeur de mapstore2 (table attributaire)

Voici des spécifications non détaillées et de mémoire : 

- saisie automatique de champs à partir des informations du header (e.g nom de l'utilisateur qui a saisie ou modifié  une donnée via la table attributaire de mapstore 2)

- restreindre la saisie selon la zone de compétence (selon le JSON fourni par la console georchestra ou bien un JSON ou WKT disponible ailleurs via une URL)

- pouvoir choisir selon le role, si l'utilisateur peut éditer la géométrie ou que les attributs

- permettre de bloquer l'édition de certains champs (exemple : ne pas permettre d'éditer le champ FOO si pas admin ou n'a pas certains rôles)

Les contributions sont encore en cours dans le coeur de MapStore2 et contienne la description des fonctionnalités avec des vidéos (gifs) :

- https://github.com/geosolutions-it/MapStore2/pull/10515

- https://github.com/geosolutions-it/MapStore2/pull/10524

Ces modifications sont déjà en production sur https://www.geo2france.fr/mapstore/#/ et le code source est disponible ici :

- https://github.com/geo2france/mapstore2-georchestra

Il faudrait se rapprocher de Vincent Fabry si vous souhaitez une démonstration.

2. Plugin de consultation et saisie attributaire

Ce travail va débuter prochainement (2026).
L'objectif est d'avoir un plugin qui permet de consulter les attributs d'une couche dans une interface dédiée en dehors de la table attributaire.

Selon la configuration du plugin, et pour les couches déclarées dans la configuration, ce plugin permettra de : 

- cliquer sur la carte
- voir les attributs des entités cliquées sur la carte (des couches configurées et visibles sur la carte)

- pouvoir passer en édition attributaire (le dessin n'est pas prévue) - uniquement les champs string, number, date, liste, auto pour les info du user ou la date

- pouvoir supprimer une entité selon les rôles de l'utilisateurs

- de masquer certains champs selon les rôles de l'utilisateur

- de bloquer l'édition de certains champs selon les rôles de l'utilisateur

- de restreindre la visualisation ou modification des attributs selon la zone de compétence (fournie par la console)

Ce plugin permet d'être autonome et indépendant de la table attributaire qui fait partie du coeur de MapStore2.

Dans un plugin, il sera plus simple de réaliser des évolutions et de la maintenance sans avoir de latence entre la fin des développements et la sortie de la release à installer (puisque le plugin est indépendant).

Ce plugin reprend globalement les spécifications du premier point, mais se dégage des contraintes technique autour de la contribution et de la maintenance (actuellement, les modifications du coeur vivent dans un fork tant que Geosolution n'a pas validé les PRs).

N'hésitez-pas si vous avez des questions.
Gaëtan B

[BERAULT Florent]

BERAULT Florent reacted to your message:

---

From: georc...@googlegroups.com <georc...@googlegroups.com> on behalf of gaetan....@gmail.com <gaetan....@gmail.com>
Sent: Thursday, December 18, 2025 9:37:09 AM
To: georchestra <georc...@googlegroups.com>
Subject: [georchestra] Re: Évolutions fonctionnelles georchestra - geocontrib'. Recherche d'éléments techniques / Functional developments in georchestra - geocontrib'. Research technical elements

 

--
--
Vous avez reçu ce message, car vous êtes abonné au groupe
Groupe "georchestra" georc...@googlegroups.com
voir http://groups.google.fr/group/georchestra
 
Site web : http://www.georchestra.org

---
Vous recevez ce message, car vous êtes abonné au groupe Google georchestra.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse georchestra...@googlegroups.com.
Pour afficher cette discussion, accédez à https://groups.google.com/d/msgid/georchestra/b890abbf-07b2-4878-8904-265cf01e8930n%40googlegroups.com.

[François Van Der Biest]

Merci Gaëtan et Florent pour vos messages.

Je vois ici un besoin de plus en plus fort pour les applications qui tournent dans geOrchestra d'avoir un comportement différencié selon la zone de compétence précise de l'utilisateur (telle que fournie par la console via l'organisme de rattachement).

On ne peut donc plus se contenter des géométries simplifiées fournies par le fichier geojson (https://github.com/georchestra/datadir/blob/master/console/cities.geojson) et retournées agrégées pour un utilisateur par le service /console/account/areaofcompetence. En effet, ces géométries sont en général fortement simplifiées de manière à autoriser un affichage et une sélection rapide par un administrateur de comptes.

Cela plaiderait à mon avis pour une GIP d'évolution de geOrchestra afin de mieux gérer les géométries unitaires des zones de compétences.

Cette GIP viserait à notamment à fournir aux applications hébergées des identifiants stables et des géométries de précision différenciée, mais peut être aussi des facilités pour mettre à jour la liste des périmètres géographiques (penser aux fusions de communes... actuellement probablement un cauchemar à gérer).

Qu'en pensez vous ?

F.

--

[gaetan....@gmail.com]

Ce serait une bonne idée de pouvoir avoir des géométries assez précises pour être utilisées comme référentiel.
J'ai des réserves sur les performances l'affichage d'un JSON plus complexe. Par contre, il peut être intéressant d'utiliser une couche tuilée sélectionnable (WMS qui retourne du JSON au clique).

Il faudrait un retour des utilisateurs quotidiens.

Gaetan

[François Van Der Biest]

On Fri, Dec 19, 2025 at 11:22 AM gaetan....@gmail.com <gaetan....@gmail.com> wrote:

Ce serait une bonne idée de pouvoir avoir des géométries assez précises pour être utilisées comme référentiel.

Yep.

 

J'ai des réserves sur les performances l'affichage d'un JSON plus complexe.

Justement, ma proposition vise à offrir 2 niveaux de détail pour chaque objet vectoriel : 

• l'un, topologique et simplifié à l'extrême pour la sélection et l'affichage des zones
• l'autre, de précision maximale, qui serait exposé aux applications nécessitant un filtrage géographique précis.

Les 2 géométries étant attachées à un même identifiant en base (ex: code insee).

 

Par contre, il peut être intéressant d'utiliser une couche tuilée sélectionnable (WMS qui retourne du JSON au clique).

Il faudrait un retour des utilisateurs quotidiens.

En effet => GIP ;-)

 

Pour afficher cette discussion, accédez à https://groups.google.com/d/msgid/georchestra/00de9043-fd30-40a5-9fc3-0a9d05f38765n%40googlegroups.com.

--

Camptocamp France SAS, Chambéry
https://www.camptocamp.com/fr/geospatial_solutions