Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site. Si vous continuez à utiliser ce dernier, nous considèrerons que vous acceptez l'utilisation des cookies. J'ai compris ! ou En savoir plus !.
banniere

Le portail francophone de la géomatique


Toujours pas inscrit ? Mot de passe oublié ?
Nom d'utilisateur    Mot de passe              Toujours pas inscrit ?   Mot de passe oublié ?

Annonce

Printemps des cartes 2024

#31 Wed 24 January 2018 11:22

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 Sep 2005
Messages: 3168
Site web

Re: Nouveauté Opendata : Cadastre, documents de filiation

Grand merci pour ce partage


De rien on ne peut pas toujours être que désagréable wink

Et puis c'est aussi à but pédagogique, l'open data c'est bien, mais la données toute seule c'est pas grand chose.
L'open ingénierie c'est mieux. L'open data sans l'open modèle cela ne sert pas à grand chose.

Les discours réguliers sur les plate-formes régionales de données ... on est loin d'un Système d'Information partagé. La mise en commun des modèles permet la mise en commun des savoirs, car c'est le modèle qui permet d’interroger la donnée.

Et j'ajoute pédagogie de la méthode. Certes nous n'avons pas partagé un logiciel où l'utilisateur appuie sur un bouton pour avoir un résultat, mais il y a toute la mécanique, reste plus qu'à mettre la direction assistée, la boite auto et la carrosserie. Avis au développeur de plugin et autres fans de python, y'a plus qu'à. Et pour rebondir sur des discussions précédentes, la partie qui coûte la plus cher c'est la conception et la fabrication du moteur ou la carrosserie ?


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#32 Fri 26 January 2018 10:45

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 Sep 2005
Messages: 3168
Site web

Re: Nouveauté Opendata : Cadastre, documents de filiation

Bonjour,

Voici une question qui m'a été posée par mail (eu pu être ici mais il y avait une partie perso) :

Je me permet de t'écrire pour t'informer que selon moi,certains besoins dans l'utilisation des données généalogiques cadastrales auraient besoin de la date de la mutation cadastrale et ta fonction ne revoit pas cette valeur.


Si a priori il est facile d'adapter la structure de données renvoyée par la fonction, et la requête sous-jacente, cette question est moins triviale qu'elle n'y paraît et soulève un point important du mécanisme de modélisation.

Nous possédons dans les données de base des informations relatives à la "division" de parcelle.
Quoi faire de ces données ? (cas d'utilisation)

1- Demander facilement au CDIF la copie d'un document d'arpentage.
2- Connaître la dimension temporelle, ie l'évolution du parcellaire au cours du temps.
3- Connaître la fréquence des opérations (division, passage au DP, réunions, remaniement ...)

Nous avons dans notre BD des parcelles, et une table qui contient :
numlotdfi
datedfi
La relation de filiation entre deux parcelles.

Je ne vois pas apparaître de table nommée "Filiation".


Question qu'est ce qu'une filiation d'une parcelle X ???????????????

Définition 1 : c'est l'ensemble des mères et des filles (X appartenant à un des deux groupes), la relation qui les lient (division, réunion etc ...), la date, le numéro de lot, et le nom du géomètre.

Définition 2 : C'est le chemin complet d'un graphe traçant la vie de la parcelle depuis la primitive jusqu'à X (et ses enfants ?)

C'est deux visions, deux modélisation différentes. Que l'on choisisse 1- ou 2- cet objet sera un objet métier "composite" qui n'est pas présent directement dans la BD mais qui se déduit des informations contenues dans la BD. Et si nous regardons bien, notre modèle de départ permet de créer un objet métier de type 1- ou 2- sans changer quoi que ce soit à la BD (tient cela veut dire que nous nous sommes pas trop trompé) .

Que c'est un CHOIX de modélisation, et c'est ni l'utilisateur métier, ni l'informaticien qui décident, c'est le groupe ! Et qui fait l'arbitre : l'architecte qui modélise.

Donc pour répondre à nos cas d'utilisation :
- Numlotdfi est un numéro interne à l'application MAJIC et il ne permet pas de faire le lien avec le numéro du DA. Le nom du géomètre est inconnu (normal quoi que c'est une personne morale donc je vois pas le coté anonyme ..... (?) quoi qu'avec les profession réglementées qui sont constituées en "Ordre" faut toujours ce méfier, pour ceux qui aiment l'histoire regardez ce qui conduit à la création des "Ordres", ou buvez éliminez comme dit la pub.

Donc il est impossible de demander la copie d'un document d'arpentage de façon normale. Il faut indiquer une référence parcellaire, le sens et éventuellement la date. C'était tellement plus simple d'avoir le numéro de DA ...

Pour le reste la définition d'un objet composite de type 1- ou 2- répond à la demande.

Je laisse le sujet ouvert et pour ceux que cela intéresse nous pouvons discuter ici de la pertinence d'une solution ou d'une autre.
Comme vous le constatez, il y a des questions, des évolutions ... mais pas de remise en cause des fondations. C'est ça l'avantage de la modélisation, on progresse en spirale pour évoluer. Ce que vous voyez régulièrement dans l'approche données (MAJIC etc ...) c'est de la conception linéaire.
On par sur un postulat, on développe, on test, si ça marche pas on casse tout et on recommence ou on s'en satisfait car même si ça marche pas bien ça a déjà coûté assez cher .... ça c'est du développement en tunnel, pratique que plus aucun développeur sérieux n'utilise aujourd'hui.


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#33 Sat 27 January 2018 14:42

cquest
Participant assidu
Date d'inscription: 6 Jan 2013
Messages: 847

Re: Nouveauté Opendata : Cadastre, documents de filiation

J'ai publié une version reformatée, plus facile à réutiliser des données d'origine: https://www.data.gouv.fr/fr/datasets/hi … filiation/

2 formats disponibles:
- json
- dump postgresql

J'ai entre autre reconstitué les identifiants complets des parcelles, remis les dates en ISO (pour le json).
Pour postgresql, il y a une table unique avec les parcelles mères et filles en array (avec un index GIN qui va bien).

C'est sûrement moins évolué que ce qu'a fait Christophe.

Le script de traitement est sur https://github.com/cquest/dgfip_dfi


Christian Quest - https://amicale.net/@cquest sur Mastodon (terminé twitter/X)
Membre fondateur et porte parole d'OpenStreetMap France
A l'origine de opendatArchives, OpenEventDatabase

Hors ligne

 

#34 Thu 01 February 2018 15:11

Sylvain PIERRE
Participant assidu
Lieu: Strasbourg
Date d'inscription: 6 Sep 2005
Messages: 170

Re: Nouveauté Opendata : Cadastre, documents de filiation

Merci pour toutes ces informations qui forment un véritable tutoriel!
Il y a matière à construire un bon article de blog
Cf ici https://blog.statsbot.co/sql-window-fun … 075b87d129

Sylvain

Hors ligne

 

#35 Tue 30 April 2019 16:40

Ghislaine
Juste Inscrit !
Date d'inscription: 12 Jan 2018
Messages: 1

Re: Nouveauté Opendata : Cadastre, documents de filiation

Bonjour,
je sais que j'arrive plus d'un an après sur ce sujet, mais je tente quand même.

Avant tout un grand merci pour toutes ces réflexions, explications et pistes de traitement.

J'ai néanmoins rencontré une difficulté :  la table reflexparcelle ne semble pas prendre en compte les cas où il y a un changement de section. C'est le cas du remaniement (Nature de DFI : 4)  et de la création ou suppression de parcelles à partir du Domaine public).
ces cas là sont bien présents dans la table divisionpart2 du DFI_schema.
Les parcelles concernées par ces cas sont bien présentes aussi dans la table division.parcelle
Mais elles n'apparaissent pas dans la table reflexparcelle.
Je pense que c'est à cause d'une requete WHERE demandant une identité de section entre les parcelles mères (typeligne=1) et les parcelles filles (typeligne =2), que ces cas sont écartés dans le processus de remplissage de la table reflexparcelle.

Dans les parties :
-- ******************  Création de la filiation descendante ********
et
-- ******************  Création de la filiation ascendante *************
Après le INSERT INTO ... SELECT .... On trouve dans la clause WHERE .....AND p1.idsection=p2.idsection.

Pour la recherche des parcelles primitives, comment prendre en compte le Domaine public qui crée de nouvelles parcelles ?

De même, ayant un peu de mal avec la complexité de la fonction GET_FILIATION, je ne sais pas s'il y a lieu d'y changer quelque chose.

Quelqu'un a-t-il entretemps pris en compte ces cas ?

Merci d'avance pour vos réponses.

Hors ligne

 

#36 Thu 02 May 2019 07:56

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 Sep 2005
Messages: 3168
Site web

Re: Nouveauté Opendata : Cadastre, documents de filiation

Bonjour,

Oui effectivement les changement de section posent un problème non traité.Le DP étant une section comme une autre.
A cette heure ci du matin problème difficilement traitable.


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#37 Fri 20 January 2023 12:08

Pastore
Participant occasionnel
Date d'inscription: 4 Nov 2019
Messages: 35

Re: Nouveauté Opendata : Cadastre, documents de filiation

Bonjour,

Merci pour le partage Christophe. Pour la création de la fonction dans PG Admin IV,  on doit bien renseigner  relation_filiation dans le type_renvoyé ?

En faisant cela, cela me crée une erreur me disant que le type de retour ne correspond pas à la fonction déclarant renvoyer division.relation_filiation.

Est ce que vous savez ce qui peut créer cette erreur? 

Merci à ous,

Cordialement

Hors ligne

 

Pied de page des forums

Powered by FluxBB