Open babastienne opened 1 year ago
Le sous-module FONCIER n'était pas pensé pour stocker les informatiques cadastrales parcelle par parcelle et je pense pas que ça soit adapté de stocker ça comme ça.
Il y a clairement un vrai besoin Cadastre dans Geotrek, mais qui concerne plutôt le fait de pouvoir croiser et interroger le cadastre. Pas forcément le stocker comme ça dans des statuts en segmentation dynamique qui vont être impossibles à renseigner et à tenir à jour, la plupart du temps faux.
Je pense que cela devrait être réfléchi et analysé plus globalement, et pas seulement ajouter un champs "Parcelle" dans le sous-module FONCIER, qui va laisser penser qu'on gère le cadastre dans Geotrek, alors qu'on le gérera mal.
A discuter.
En complément, voici que j'avais évoqué il y a quelques mois quand nous avions discuté du même sujet :
Initialement, l'idée du module STATUTS était de pouvoir localiser sur le linéaire de tronçons des informations comme le type foncier, le gestionnaire, le type physique... Ces infos n'ont volontairement pas été définies tronçon par tronçon (trop lourd et fin), mais en segmentation dynamique pour pouvoir définir un début et une fin de chaque information, potentiellement couvrant plusieurs tronçons (complètement ou partiellement). Ça aurait clairement été ingérable de renseigner ces infos tronçon par tronçon, mais je continue à m'interroger si c'est vraiment viable en segmentation dynamique. Pour les gestionnaires je ne vois pas d'autre solution.
Par contre, pour le statut foncier, provenant des infos cadastrales, je pense qu'il faudrait aborder cela différemment. D'autant plus si on veut découper ça parcelle par parcelle pour disposer du numéro de celles-ci mais aussi du propriétaire.
Pour cela, un champs PROPRIETAIRE et CONVENTIONNE a été ajouté en 2017 (https://github.com/GeotrekCE/Geotrek-admin/issues/1621) sur les statuts fonciers, mais je pense que c'était une mauvaise idée. Saisir des types fonciers, parcelle par parcelle, en segmentation dynamique me semble ingérable et impossible à tenir à jour.
La seule solution viable à mon avis, pour connaitre les infos cadastrales précises d'un sentier, tronçon, aménagement est de faire une intersection dynamique et géographique entre l'objet et le cadastre, pour interroger une info viable et à jour.
Mais là, on se heurte à un autre soucis du cadastre, dont on a discuté lors du premier "Café Geotrek" : Le cadastre est un référentiel juridique et non géographique. Il a été numérisé et vectorisé depuis quelques années, mais n'est pas superposable avec les autres référentiels IGN, comme on peut le voir ici :
Intersecter géographiquement un objet linéaire issu des référentiels IGN (BD topo ou autre) avec le cadastre vectorisé apporterait des infos potentiellement erronés, comme illustré ci-dessus.
Comme évoqué lors du "café Geotrek", je pense qu'il faudrait sérieusement se poser sur le sujet Geotrek et cadastre pour l'analyser globalement et plus en détail, car ce sujet est souvent évoqué, mais jamais vraiment creusé ni analysé.
Si un groupe veut se pencher sur le sujet, je serai ravi d'y participer.
En attendant, je ne suis pas contre le développement proposé, mais selon moi, ce n'est que remettre sous le tapis le sujet de fond qui serait à analyser.
Ok Camille, merci pour ton complément. Je pense qu'à court terme on va ajouter le champ et réaliser le développement pour permettre aux territoires de travailler de la sorte. En effet c'est dans la lignée des champs "propriétaire" et "conventionné" déjà existants (même si j'ai bien noté ta réticence initiale à l'ajout de ces champs).
Par contre je suis d'accord aussi avec toi pour réfléchir plus en profondeur sur la meilleure manière de gérer le cadastre dans Geotrek. Ce n'est pas un sujet que je maitrise vraiment mais j'aimerai bien participer à la réflexion également. Peut-être que côté CD25 il pourraient se joindre à la réflexion ?
Quels sont les cas d'usage pour les numéros de parcelles liés aux tronçons ?
Je pense qu'il ne faut pas ajouter ce champs, ça va être faux et mal rempli, ça n'a pas de sens et on détourne encore plus la logique du module FONCIER.
Ajouter ce champs va aussi laisser penser à ceux qu'ils le saisissent que les informations foncières doivent être saisies manuellement parcelle par parcelle, ce qui n'est pas l'idée du module et n'est pas viable.
Il faudrait plutôt savoir quel est le besoin, quel est le contexte et ce dont on a besoin.
Et certainement faire une couche vectorielle de polygones où on pourrait charger tout le cadastre. Et ainsi pouvoir l'intersecter (stocké ou à la volée) avec les autres objets.
Je pense que si on ajoute ce champs, c'est pire que le champs Propriétaire car c'est une info encore plus fine, impossible à renseigner et tenir à jour dans un champs texte du module FONCIER.
Je pense qu'il ne faut pas l'ajouter mais préciser le besoin et définir une vraie solution.
Peut-être même vaut-il mieux utiliser la couche zonages existante si on veut faire simple pour le moment ...
Demande effectuée par le CD25.
Cela permettrait d'avoir l'information dans un champ dédié à l'export et également de pouvoir avoir un filtre dans la vue liste pour filtrer les statuts foncier par parcelle.
Il s'agirait d'un champ texte libre.