Le portail francophone de la géomatique

Bonjour,
Même avis que Christophe,
Une table comportant le champ avec les valeurs "active/inactive"
Une table de relations mère/fille avec dates de création/suppression, nature de l'opération (et la référence au DA en bonus)
Quelques jointures, requêtes, stockées sous forme de vues...
...Et on a l'ébauche de l'application MAJIC III (ou de son successeur) ;)
PS : pour la topologie, çà se complique avec les opérations de remaniement, remembrement, RPCU etc...
Cordialement

Dernière modification par Jean-Michel (Thu 21 February 2013 15:53)

1) Dans ce cas une table "document d'arpentage" serait liée à une autres via un identifiant de liaison. Cette table stockerait toutes les parcelles. Ainsi, le DA n°1 serait lié aux parcelles 110, 111, 112... Il est vrai, cependant, qu'il sera difficile de comprendre la nature de l'opération.

2) Qu'entendez-vous par millésime? J'utilise le logiciel Arcgis. Je suis étudiant à l'ESGT (École Supérieure des Géomètres et Topographes) et réalise un travail de fin d'études dont le thème est l'intégration des données concernant la domanialité d'une ville dans le but d'assurer un suivi grâce à l'état des lieux qui sera fait. Les données à intégrer peuvent concerner des alignements, des mutations de parcelles appartenant au domaine de la ville, le domaine public maritime, les servitudes de droit privé... Vous l'aurez compris, je suis plus sensibilisé à la gestion du foncier qu'à l'aspect gestion de données. Cependant, je suis obligé de résoudre cette problématique.

Ma demande concerne la représentation de la présence d'un DA sur les parcelles qui sont concernées par celui-ci (il ne s'agit pas de la représentation d'une parcelle). Le but est de voir sur l'interface la présence d'une opération de bornage (comme sur geofoncier par exemple. Cependant,L'idée est également de conserver l'historique des mutations même si les parcelles mères n'existent plus. Je saisis bien le problème de représenter de la donnée qui n'a pas, à la base, de sens géographique.

3) Pour conserver l'historique, il peut être envisager de créer une table en "dure" historique qui ferait le lien avec la table "document d'arpentage" via un identifiant de liaison. Cette table historique conserverait les numéros de parcelles et même ceux n'existant plus. (idem que 1) ). Ce que vous dites est envisageable aussi. Cependant, la données en ma possession est une table DGFIP qui n'offre pas cette info.

Il m'est difficile d'expliquer simplement ce problème, veuillez m'en excuser.

C'est prévu, l'aspect juridique constitue un point important de ma réflexion. Ce qui implique une précision et permettra la dématérialisation de certaines données pour ne pas avoir à les chercher dans les archives... Des champs seront prévus : précision (inspiré du mode de classes RFU), lien vers les DA numériques/numérisés, lien vers les arrêtés (pour les alignements), etc. Dans ce sens, les données du domaine de la ville seront précises juridiquement et en termes de positionnement. L'opposabilité aux tiers pourra donc être assurée.

Le problème persistant réside dans la superposition des données lors d'opérations successives. Un contact m'a dit que ce point n'est pas géré par le geofoncier. On peut donc se retrouver avec plusieurs "signe GE" superposés dans le portail geofoncier, ce qui n'est pas terrible à mon sens. Par ailleurs, ce singe "GE" est placé plus ou moins librement par le géomètre-expert. Il n'y a donc pas d'uniformité en termes de représentation. Cependant, il n'est pas facile de trouver une alternative à ce problème. Mon but est donc de trouver la meilleure représentation possible ce qui apportera une plus-value à mon travail.

Enfin, ce qui me gène dans le système de parcelles actives/inactives c'est qu'on se retrouve avec une table qui comportera des parcelles qui n'existent plus. J'ai bien compris que ce champs"actif/inactif" est là pour ça. Cependant, garder une table à jour, c'est-à-dire avec des parcelles qui existent vraiment et faire un lien entre une table "DA" et une table à part non visible "historique de parcelle" (regroupant toutes les parcelles, même celles qui n'existent plus) ne serait-ce pas plus mal? Un id de DA serait associé à chaque parcelle concernée par celui-ci. De cette façon on se détache de la notion de parcelle et on se réfère à un numéro de parcelle.

Cordialement.

Bonjour,

Voici la méthode qui sera retenue (dans ses grandes lignes).
Pour la représentation : gestion de la superposition par un système d'étiquettes sur un élément disposant d'une chronologie (une date par exemple). Après avoir étudié ce problème de représentation, il s'avère difficile de gérer la superposition de plusieurs éléments sur une même entité... On peut, cependant, atténuer les contraintes de ce problème.

En ce qui concerne l'historique : j'aurai une table centrale pour la matérialisation des DA qui synthétisera le maximum d'informations pour ne pas avoir à effectuer des saisies dans plusieurs autres tables(num de DA, date de publication/validation par le cadastre, etc.). Vous noterez qu'à ce stade, les numéros de parcelles ne figureront pas (problème d'intégrité des données difficile à expliquer par écrit). Il y aura deux autres tables : une pour les points de limites, une pour les nouvelles limites selon le mode geofoncier avec un choix de classes de précision différent adapté à la ville.
Une table historique sera liée à la table centrale via une relation sur un identifiant. Chaque numéro de parcelle sera renseigné à la main et fera l'objet d'un enregistrement distinct des autres, même si plusieurs numéros de parcelle peuvent faire référence à un même DA. Ensuite, une vue sera créée entre la table des DA et la table historique pour faire figurer virtuellement les numéros de parcelle à la ligne du DA correspondant pour consulter la donnée. L'ensemble des numéros de parcelles correspondant à ce DA seront concaténés dans un même "case".

J'espère avoir été le plus clair possible, je vous remercie pour vos commentaires.

Je n'ai plus qu'à mettre en place cette partie du modèle et déjà penser à intégrer les autres données (voiries communales, domaine maritime...) avec tout ce que cela comporte en termes de précision juridique et topographique.

Cordialement.

Oui en effet, j'ai oublié de préciser quelques points.
J'ai décidé de supprimer (du moins pour l'instant, peut être qu'une autre idée surviendra) tout lien avec les parcelles, notamment pour une mise à jour automatique (d'ailleurs, geofoncier ne travaille pas sur les parcelles...). La couche de base à disposition est une couche contenant toutes les parcelles de la ville. Elle réunit tous les propriétaires. Elle n'est pas au format MAJIC. J'ai réalisé une requête isolant les parcelles de la ville et créé une nouvelle couche à partir de celles-ci. Elle est présente dans mon modèle à titre indicatif. La ville reçoit des mises à jour régulières qui pourront être confrontées à (et qui pourront remplacer) la table que j'ai créée. J'ai mis de côté l'idée de la mettre à jour automatiquement pour le moment afin de me concentrer davantage sur l'historique.

Le problème difficile à expliquer est le suivant :
J'avais pour idée de renseigner, dans la couche matérialisation des DA, le plus d'informations possible pour n'avoir à réaliser des saisies manuelles que dans une table et pour éviter la propagation des erreurs. Je voulais également renseigner les champs suivants > PARCELLE_MERE prenant par exemple la valeur (dans la même "case") sous la forme "116,117,..." et PARCELLE_FILLE prenant par exemple les valeurs "500,501,502". J'attire votre attention sur le fait qu'il s'agit d'un enregistrement, c'est-à-dire que les numéros de parcelle sont situés dans la même "case". Imaginons que cela corresponde à une opération sur les parcelles mères 116 et 117 centralisées dans une "case" donnant lieu à la création de 3 nouvelles parcelles "500,501,502", elles aussi centralisées. A ce stade de réflexion, j'imaginais un petit "script" qui scannerait les champs PM et PF et qui les décomposerait dans la table historique de la façon suivante
Exemple : pour le DA ayant par exemple l'identifiant 10, portant sur les PM 116 et 117 et donnant lieu à la création de 500,501,502 on aurait :

ID PARCELLES
10   116
10   117
10   500
10   501
10   502
L'ID serait renseigné automatiquement via une relation entre classes (arcgis). Et un numéro de parcelle pouvant, bien entendu, figurer plusieurs fois en faisant référence à des numéros de DA différents :
16   116

De telle façon, on aurait eu à renseigner uniquement la table matérialisation des DA, la table historique se renseignant automatiquement via une commande. Cependant, saisir un champ comme cela "500,501,502" ne permet pas d'avoir un contrôle d'intégrité des données dans le sens où l'opérateur à vite fait de faire une erreur. Un numéro de parcelle ne dépassant pas 4 chiffres, on pourrait facilement se retrouver avec 5ch sans que cela ne ressorte, ou avec une lettre... Aussi, on pourrait imaginer de créer plusieurs champs PARCELLE1, PARCELLE2, PARCELLE3... ce qui permettrait de dispatcher chaque numéro de parcelle dans un champ. Néanmoins, je souhaite une certaine rigueur dans mon modèle et ne veut pas me retrouver avec des champs vides. Bien qu'il est rare de réaliser (pour les villes urbaines) des opérations à grande échelle impliquant des dizaines voire des centaines de parcelles, on pourrait pousser le raisonnement et créer autant d'attributs PARCELLE qu'il en existe sur le DA (PARCELLE53...). Ce n'est pas gérable.

C'est pour ces raisons, et grâce à ma discussion avec un développeur qui m'a donné de bons conseils, que les champs PARCELLE MERE et PARCELLE FILLE ne figureront que dans un mode de consultation des données via une vue qui devra être mise en oeuvre une fois le modèle de données validé. Cela veut dire que dans le modèle conceptuel (et dans un mode de travail sur les données) ces champs n'existeront pas. Il faudra, et voici les limites de mon système, saisir les données dans la table DA puis saisir les parcelles concernées par le document (aussi bien les parcelles mères que les filles) une à une dans la table historique et enfin créer une relation pour faire le lien avec l'id du DA pour associer le numéro de parcelle au bon DA. La vue fonctionnera de la même façon que je l'avais imaginer mais dans le sens inverse. Pour l'id 10, toutes les parcelles pointant vers lui seront concaténer dans un champ visible en mode consultation. Dans ce sens on peut contrôler l'intégrité des données en utilisant un format Code commune 3 chiffres.code section 2 lettres.code parcelle 4 chiffres (222AB0125).

Ma volonté de ne renseigner qu'une couche était fondée sur un souci d'utilisation des logiciels SIG par un des services de la ville. L'utilisation n'est pas aisée pour des novices et manier plusieurs tables pourrait être problématique.

Je pense que ce modèle est plutôt fiable. Avec plus de temps, peut être que j'aurais travaillé un peu plus la structure. Cependant, ce n'est qu'une partie de mon sujet et de mon modèle de données. Car viennent se greffer d'autres informations sur la domanialité... Pour les représentations, un système clair d'étiquette sera réalisé. Ainsi, lorsqu'il y aura superposition, la présence de plusieurs étiquettes indiquera qu'il y a eu plusieurs opérations sur l'emprise.

Je comprends parfaitement. De cette façon les choses sont claires et vont droit au but. Cette discussion m'a bien aidé à pousser ma réflexion. Je vous remercie pour l'intérêt que vous y avez tous porté et tâcherai de vous informer de l'évolution de mon travail.

Dernière modification par CyrilM76430 (Tue 26 February 2013 09:14)

Bonjour,

C'est la première fois que j'entends parler de ce modèle 40. J'ai réalisé quelques recherches en vain... Je vais me renseigner auprès des services du cadastre si j'en ai le temps. Si je comprends bien mon modèle est l'adaptation du M40 en base de données sig? Mon modèle est-il plus complet? Moins complet? et surtout, vous paraît-il fiable et cohérent?

En effet, cette relation existe et sera explicitée dans le modèle conceptuel. Cependant, je fais face à un contexte qui implique de faire un choix : assurons-nous au maximum la mise à jour de toutes les données y compris les parcelles ? Ou : détachons la maj des parcelles du suivi historique pour éviter de saisir des éléments dans 3 tables différentes ( DA, parcelles et historique) pouvant ainsi propager des erreurs. La mise à jour de la table parcelle serait l'idéal pour assurer un suivi et disposer de données fiables et constamment à jour. Néanmoins, le schéma serait le suivant : saisie du DA dans la table DA, saisie des parcelles concernées dans la table historique puis mise à jour des parcelles en supprimant/ou en rendant inactives les parcelles qui n'existeront plus et en créant les nouvelles parcelles *. Ce processus peut être compliqué pour des personnes qui ne sont pas formées au SIG.

L'heure est donc à la réflexion entre une mise à jour régulière des parcelles impliquant une saisie plus conséquente pouvant contenir plus d'erreurs ou bien de ne pas mettre à jour la table des parcelles et de se contenter uniquement d'un historique alphanumérique. Je re précise que nous traitons uniquement les parcelles appartenant à la ville.

* Je viens seulement de saisir le problème topologique. Lors la création de nouvelles parcelles, comment vais-je gérer la non correspondance entre les nouvelles limites issues du DA (vraies) et les limites cadastrales des parcelles voisines (qui ne seront pas concernées par le DA)?

On peut envisager de supprimer les parcelles mères de la table parcelle et de créer une nouvelle table, à part, en saisissant uniquement les nouvelles parcelles. A terme échelle en dizaine d'années voire plus...), on aurait une nouvelle couche avec les nouvelles parcelles à créer issues de DA qui s'étoffera et d'un autre côté, une table parcelle de la ville qui diminuera en consistance à chaque suppression de parcelles mères. Le seul "problème" et d'avoir une nouvelle table sur laquelle on intervient amenant le nombre d'étapes de saisie à 4. Cela alourdit l'opération de mise à jour.
OU, considérer la couche parcelle issue des données DGFIP en tant que fond de travail qu'on se réapproprie sur lequel on apportera des données de plus en plus précises (celles des DA). Par exemple, la saisie d'une nouvelle parcelle issue d'un DA sera digitalisée et les limites voisines (du cadastre) seront réajustées par rapport à ces nouvelles limites (mais resteront "fausses"). De telle façon, on a une mise à jour du parcellaire de la ville combinée à une migration vers un parcellaire vrai à l'ensemble de la ville (même si cela prend beaucoup d'année, la dynamique est là).

Reste donc ce choix à faire qui sera décidé avec les commanditaires de mon sujet.

Cordialement.

Bonjour,

Moins que les hypothèques Quoi cette année ils disparaissent ...