Le portail francophone de la géomatique

Bonjour

A quoi donc vous sert une base de données relationnelles dans ce cas ?

C'est la première des questions à vous poser. Donc quelles sont les relations qu'il y a entre vos différents "shape". Donc quel modèle de données. Moi je commencerai par regarder les cas d'utilisation. Pour qui, pour quoi, le comment ça vient bien après.

Quand cela sera clair vous pourrez commencer à envisager de faire quelque chose de "technique".

Bonjour,

L'idée est la suivante :

Faire un état des lieux des différentes données disponibles (pas les formats, le contenu).

Établir un échange avec les utilisateurs :
Quelles sont les données que vous utilisez, pour quoi faire ? : définition des cas d'utilisation
Veillez à utiliser le même langage qu'eux : si ils utilisent les "surfaces exclusives 2DF23", ben vous aurez un objet "surfaces exclusives 2DF23" à part le fait de savoir qu'il a une géométrie de type polygone, le reste vous importe peu.
Enfin presque, car si les mêmes vous disent que cet objet est utilisé en lien avec la couche bâtiment de la BDTopo, vous savez qu'il doit exister une relation entre l'objet "surfaces exclusives 2DF23" et BDTopo.batiment : comment la modéliser ?
Plusieurs solutions, une relation spatiale : ST_within(batiment.geom,surface2DF23.geom)
Une relation "logique" créée avec des entiers longs : id_surface2DF23 (identifiant surface) et ptr_surface2DF23 (champ de la table batiment).

Voilà l'idée c'est de commencer à définir quoi faire. Le comment faire c'est pas un soucis et ça vient après.

Bonjour

Une baie SAN connectée à un cœur de réseau ça fait aussi l'affaire.

Bonjour,

T'as raison cette habitude d'être confortable, voir sur dimensionné comme le répète Tumasgiu.
Je plaisantais un peu, mais tu as raison sur l'accès multiple, quoi que si c'est uniquement en lecture ...
Après je suis le premier à encourager le recours à une BD, après cela peu vite devenir n'importe quoi si l'on a pas pris la précaution de conceptualiser les choses avant.

Et j'encourage vivement Crumbling à perdre du temps à réfléchir, il va en gagner beaucoup après.

Bonjour à tous,

de mon coté, ma base de données PostGIS, proprement modélisée lors de sa création en 2007 fait son petit bonhomme de chemin et évolue au fil des années, des besoins de mes collègues, des questions posées, et aussi de la souplesse que je m'accorde avec le modèle relationnel.
Par contre j'ai pris l'habitude depuis deux ans de consacrer un schéma de ma base au stockage des données sources, souvent des shp, qui intègrent ce schéma sans autre modification que le format (shp -> postgis), une table par shp reçu.
Ceci me permet ensuite d'utiliser PostgreSQL comme un ETL et de garder la trace de la requête qui m'a permis d'intégrer cette donnée source à mon modèle (soit pour la réutiliser si un fichier similaire me parvient, soit pour répondre à une question ultérieure).

Bonjour,
je n'ai pas visité beaucoup le forum ces derniers jours donc je réponds un peu en retard,  mais merci pour toutes les réponses,
cela répond aux questions que je me posais.

Effectivement, au début du projet, l'objectif était d'aller vite, sans d'abord étudier précisément les besoins au niveau logiciel et des process de production. C'est revenu nous mordre après.

Encore merci pour toutes les réponses.