Le portail francophone de la géomatique

Cyril,

Merci de ta réponse aussi prompte !

En fait, nous avons déjà traité les fichiers MAJIC, grossomodo il s'agissait de créer des tables de grands propriétaires publics, à partir du fichier propriétaires et du fichier des propriétés non bâties (article 10). Nous avons pris le soin de créer aussi un code parcelle par concaténation du code département (ccodep), du code commune (ccocom), du code préfixe (ccopre), de la section cadastrale (ccosec), et du code parcellaire (dnupla). Nous avons aussi créer le même code pour les parcelles de la BD Parcellaire, pour pouvoir réaliser les jointures.

Pour les parcelles vectorisées ça va la jointure ne posera pas de pb, mais là où je m'interroge c'est comment, ds la BD Parcellaire, et précisément dans les tables "parcelle" et localisant", ne sélectionner que les parcelles raster pour pouvoir créer nos fameux polygones centrés sur le localisant, établir notre couche graphique puis créer un identifiant pour joindre cette couche avec les majic ??

J'ai connaissance des docs que tu m'as transmis en liens, ms je ne trouve pas trop de réponses pour cette délicate opération ^^.

Dsl c'est un peu long, j'essaye de donner assez d'infos pour être clair...

Encore merci !

Dernière modification par Antoine42 (Fri 24 June 2011 10:12)

Bonjour,

@JM il devient urgent de me mettre au boulot pour redonner le contenu de mon ancien site  ...

D'un point de vue méthodologique il faut prendre en compte plusieurs aspects. Le taux de couverture au niveau régional ou départemental des commune vecteurs est en constante évolution. L'état des données plans et des données MAJIC n'est jamais synchrone.

Donc pour traiter un lien entre plan et MAJIC il faut utiliser une base (ou une table ) contenant l'ensemble des communes du territoire affectée d'un attribut booléen : Vecteur (vrai/faux) que l'on initialise depuis les données plans, par exemple on met Vecteur à faux par défaut et on parcour tous les fichiers vecteurs pour basculer à vrai en fonction des code INSEE lus.
Utiliser ensuite les fichiers vecteurs ET localisant (en fonction de la valeur du champs Vecteur) pour initier les sections et les parcelles. L'objet parcelle étant affecté d'un attribut anomalie : Entier ou Octet qui est à 0 par défaut.
Ensuite on utilise les fichiers MAJIC, on en parcours le fichier Nbat pour lire les parcelles, on interroge la base précédente pour voir si cette parcelle existe, si oui on affecte les attributs MAJIC si non anomalie = 1 (existe dans majic mais pas au plan,(Avec une petite astuce vérifier si la parcelle n'as pas le code NFP)) etc ... A la fin on regarde quelles sont les parcelles présente au plan qui ne sont pas dans majic pour un état anomalie = 2 (au plan mais pas dans MAJIC.

Pour l'aspect MCD :

En matière de base de données relationnelles et de modélisation objet ceci est une hérésie.
Un département est un département ... qui est composé de communes, composées de sections qui sont composées de parcelles. Ce qui nous fait tout de même quatre objets donc quatre tables liées par une relation 1 à n chacune. Chacun de ces objets ayant des attributs spécifiques (par exemple ceux cités dans mon § précédent), et une clef primaire composée d'un entier long
Cette approche possède plusieurs avantages, elle correspond au plus prés à la réalité, elle est évolutive sans impacte sur l'ensemble du projet (demain la commune x devient vecteur, une valeur à changer dans un champs et hop ça roule), elle est rapide (des jointures basées sur des clefs primaires numériques est très rapide), elle est économique comparez le fait de stocker une fois le code dep ( 3 ou 6 octets, une fois le code insee 3 ou 6 o, une fois les deux lettres de section 2 ou 4, et 10 000 * 5 ou 10 octets pour les 10 000 parcelles de ma commune (total  50 008 ou
100 016) et 10 000* (3+3+2+5) ou 10*(6+6+4+10) ). Et enfin elle permet d'intégrer l'ensemble des données foncière dans une même BD si on a une cartouche spatiale.

Concernant la géométrie des objets :

Là aussi le stockage d'un point qui s'affichera sous forme d'un rectangle centré est tout de même plus proche de la réalité (un localisant est un point), et plus économe.


Désolé ici de contredire les préconisations du CETE (et pas que sur la géométrie) mais cette analyse (simplifiée) résulte d'une "longue" pratique et d'une utilisation quotidienne de ces données sur une région de deux départements de 360 communes.

Pour terminer j'ajouterais qu'avant l'exploitation il faut penser intégration, et toujours au préalable penser l'architecture avec l'approche objet et cette approche ne nécessite en aucun cas d'être "informaticien"). Réaliser une jointure entre BD Parcellaire et données MAJIC tel que vous l'abordez (Cyril et Antoine), c'est nier l'essence d'une parcelle (ou d'une donnée géographique) qui est d'être composée d'une géométrie géolocalisée) et de données littérales (ou attributaires), donc être au sens numérique UN objet stocké et interrogé dans un SGBDR spatial (ou presque) et visualisé grâce à un SIG. Votre approche consiste elle à considérer qu'il existe un objet parcellemajic et un objet parcelleBDParc et à réaliser une jointure entre eux deux ...


A+

Bonjour,

Je crois que l'on ne se comprend pas. Dans le monde réel la définition d'une parcelle est cadastrale.

Et ces parcelles peuvent avoir des relations avec d'autres objets. Un espace vert par exemple. Qui n'est pas une parcelle, même si sa géométrie est fonction de la géométrie de n parcelles particulières, ces n parcelles qui ont une relation avec l'espace vert (une relation de composition par exemple).

Vous ne faites donc pas une jointure avec une parcelle mais un localisant. C'est là que je vous indique que vous ne faite pas de l'intégration de données, mais vous rendez lisible à votre application des données fournies par des tiers.
Créer à partir des données raster, vecteur, Majic, un objet parcelle c'est intégrer de la donnée. Demain si je veux intégrer l'objet espace vert, après en avoir fait sa définition et identifier les sources de données disponibles on crée l'objet et on défini sa ou ses relations avec les autres objets du système.

Tout d'abord, comme Christophe l'a fait remarqué, les parcelles sont à relier avec les données attributaires du fichier majic. Donc, à mon avis, le plus logique et surtout pour avoir des résultats les plus proches de la réalité, il faudrait faire des calculs par rapport aux données et non aux objets.

Sinon, pour ces fameux objets, à première abord, je ferais des cercles, je ne suis pas sectaire envers les rectangles, mais ça me parait plus simple avec des cercles (et ce n'est pas plus idiot que des rectangles, vu que ça ne représente rien de réel!).
Et donc je ferais des buffers avec comme rayon : racine carrée ("champs_superficie"/3.14) . Je ne sais pas si c'est faisable par Mapinfo, mais facilement avec postgis. Je testerai et je te tiens au courant!

Dernière modification par cyril_c (Wed 29 June 2011 21:16)

Bonjour,

Ok j'ai bien pris note de ta méthode. Effectivement, je n'avais pas précisé mais la relation entre les parcelles et les données attributaires majic a été faite. J'ai un champ qui indique la superficie des parcelles...je vais donc essayer à partir de là.

Un grand merci !