Le portail francophone de la géomatique

Bonjour,

Pour les communes ce serait plutôt 360 000 environs.

Pour la Corse qui représente 1% des communes française (360 communes) il y a en 2018 deuxième trimestre (car les chiffres demandés évoluent tous les jours) :
360 communes
2124 sections.
5757 feuilles de plans.
1020784 parcelles pour : 1074400 faces, 2950911 arcs.
305549 bâtiments dont  232237 bâti durs.
10 021 numéros de voirie
279710 labels (nom rue, nom fleuve etc ...)
53057 polygones d'hydrologie
48590 arcs : axes de voies de communication
291473 détail topo linéaires
23106 détails topo surfaciques
50449 détails topo ponctuels.


Voilà je n'aurai pas la prétention de dire que la Corse c'est la France, comme d'autres pensent que Paris l'est, mais bon d'un point de vue géographique c'est assez représentatif, les couches qui me semblent le moins répondre à un critère national sont :
adressage : peu présent dans la région.
Batiment : faible densité hors zone urbaine, zones urbaines réduites.

Merci JM d'ailleurs 1% de 36 000 ça fait 360 et pas 1% de 360 000,

Désolé c'était les chiffres du syndicat pas ceux de la police.
J'ai du confondre nombre de commune et de manifestants  -)

Bonjour,

La nature de la géométrie d'une commune : MULTI POLYGON
Idem pour section

Car il suffit qu'il y ait une île, ou que l'on ai eu un remaniement partiel sur une section, je m'explique si j'"ai la section A avec cinq feuilles contigües, j'ai un polygone, je remanie les feuilles A3 et A4, la section A devient un MULTI POLYGONE et la section A n'est plus définie par une seule entité topologiquement cohérente.

Pour l'équivalence MAJIC PLAN aux niveau LOCAUX-BATIMENT, la première approche consisterai à considérer que chaque parcelle tagguée GPGL=1 ou pdl_type='CL' ou 'CV' on a un bâtiment a minima.
Pour la CORSE 335 625 Locaux MAJIC pour 232 237 bâti dur avec 23 198 parcelle assise de copro.

Pour les propriétaires j'ai un méchant doute, compte tenu des modèles de données exposés publiquement il ne faudrait pas confondre personne et compte communal, ensuite comme l'unicité de la personne n'est garantie qu'au niveau départemental (et encore y'a des bêtises) une personne d'un départent A sera peut-être à nouveau comptée dans un département B. Ensuite il y a des propriétaires 'virtuels' : "les copropriétaires de l'immeuble machin" et des propriétaires qui sont là car la DGFiP ne mets pas ses bases à jour (contrairement aux instructions du ministère), vous trouvez par exemple des propriétaires du style :
ETAT ministère du temps libre, ETAT administration des P&T ... en CORSE 37 dénomination différentes pour un truc qui devrait être : ETAT PAR l'ADMINISTRATION DES DOMAINES,
On parle aussi des propriétaire du type DEPARTEMENT 20 ? ou DEPARTEMENT DE LA CORSE ?


Bref si l'objectif (ce que je suppose) c'est de dimensionner des BD ou des serveurs le gros problème ne viendra pas de la volumétrie mais du MCD utilisé pour stocker les données, car entre les modèles existants y'a un gros gap.
Avec un modèle lizmap ou ARCOPOL tu vas stocker beaucoup plus d'informations (redondance notamment des clefs naturelles) que si tu utilise celui que nous proposons. AMHA au niveau national ça se compte en Go.

Ensuite l'autre problème c'est que les modèles précités (pas le notre) ne permettent pas une intégration de plusieurs départements dans la même BD.

GéoBonsoir Patrice, 

Je reviens sur mon histoire de modèle, et en remarque préliminaire t'indiques que les chiffres donnés pour les parcelles comprennent les parcelles non figurées au plan et les parcelles présentes dans MAJIC mais pas au plan. La variation est faible de l'ordre du millier.

Selon les modèles existant il y a deux tables parcelles, les parcelles MAJIC, les parcelles du plan et une table pour les numéro de parcelle (entité graphique).
Donc pour toutes la France 100 millions de parcelles environs:
100 millions de valeurs texte insee : 3 caractères soit 3*2 6 octets fois 100 millions = 600 Mo (je simplifie je divise par 1000 et pas 1024)
100 millions de valeurs texte nom section : 2 caractères : 400 Mo
100 millions de valeurs texte numéro de parcelle : 4 caractères: 800 Mo
Soit 1,8 Go
Tous ceci multiplié par deux car deux tables, il s'agit ici de la duplication des clefs naturelles

A ceci s'ajoute le champ numéro de la table texte parcelle : là c'est un entier 4 octets soit 400 Mo

Soit 4 Go au total

Maintenant selon notre modèle (clef primaire et étrangère obligatoire et liaison parcelle section directe):

Insee : codé dans commune : 36000 * 6 octets =216 Ko
Idcommune : entier 4 octets : 144 Ko
Ptrcommune : 850 ko

Nom section : 2124 * 100 * 4 = 850 ko
Idsection : 850 Ko

100 Millions de parcelles donc de numéros : 800 Mo
idparcelle : 400 Mo
ptrsection : 400 Mo
Choix indépendance graphique vs MAJIC
100 Millions textes parcelle : 400 Mo

On arrondi à 2 Go soit le volume de la table parcelle et texte parcelle.

J'ai pas compter les indexes qui font bien sur varier la chose. Et je ne parle pas non plus de la différence de temps d'exécution des requêtes.

Bonne soirée.

Dernière modification par ChristopheV (Thu 17 January 2019 18:57)

Bonsoir,

Si tu veux uniquement le plan (la donnée Edigéo) y'a juste une petite modif à faire à l'intégrateur que nous avons mis en ligne et si tu as une machine normalement dimensionnée (12Go RAM, disque SSD pour cluster BD, un proc correct) et environs  12 jours où elle peut tourner (peut-être moins ) c'est faisable.

Ou si tu as plusieurs machines virtuelles qui alimentent directement une BD sur un serveur lui aussi virtualisé (en fait tu travailles directement dans la machine qui virtualise tes serveurs et tu communiques par des liens virtuels au niveau logique mais physiquement c'est RAM vers SSD) TU segmentes les répertoires et tu lances plusieurs instance de l'intégrateur sur plusieurs machines, chaque instances lançant elle même le maximum de processus en fonction de la conf de la machine virtuelle, chez moi je fais tourner 15 proc EDIGéO 30 proc postgis avec un tampon de 40 lots sur une machine, 3h pour toute la Corse. Donc avec une dizaine de machines virtuelles tu peux réduire le temps à :30 heures environs. (on veut le faire mais pas le temps !).

Après il y a le coté insertion des données et des verrous, sachant que l'objet parcelle est le plus commun et nombreux ... là je connais pas assez postgis pour savoir si ça influe mais mon voisin devrait savoir


Ha j'oubliais la config serveur coté consultation, c'est juste une question de nombres de connexions possibles, coté requête avec le modèle fourni tu n'as pas besoin d'un monstre, juste penser quand tu rapatries des géométries en nombre, c'est coûteux.

Dernière modification par ChristopheV (Fri 18 January 2019 20:22)