Le portail francophone de la géomatique

Bonjour,

Pouvez vous préciser avec quelle SGBDRS vous allez travailler ?

Ensuite vous nous décrivez assez finement le processus mais en revanche le but du jeu c'est quoi ?

Si c'est connaitre l'occupation du sol à une date n ce n'est pas tout à fait la même chose que de visualiser la dynamique d'occupation du sol pour un intervalle de n années.

Ensuite (j'avoue que MERISE c'est assez abscons pour moi je préfère nettement UML) je comprends pas bien ce que vous nommez entités, attributs et surtout le sens que vous donnez au mot "base".

Bonjour,

Merci pour vos posts.

@ ChristopheV : Je travaille sous postgresql/postgis, c'est vrai que j'aurais du le préciser. Je prévois de réaliser des statistiques spatiales sous Rstudio. C'est ce qui m'a paru le plus facile pour le webmapping avec lizmap derrière (je refais de la pub pour Géopoppy).
Le but de la base est bien de fournir des analyses de la dynamique d'occupation des sols sur le territoire (mais aussi accessoirement de connaitre l'occupation des sols à une certaine date), d'où les analyses statistiques (construction d'indicateurs type : temps de retour sur parcelle, rapport à la démographie, taux d'occupation du sol sur une période, le tout sur des découpages en sous-zones...).

J'ai préféré MERISE à UML pour sa plus grande uniformité de la méthode (de nombreuses nomenclatures existent sous UML) et parce que apparemment UML est orienté objet. Les entités sont les "tables" et les attributs sont les types de données contenues dans la table. Après une rapide recherche, je crois que l'équivalent dans le diagramme de classes est entité = classes et attribut = attribut.

J'appelle "base" l'ensemble des données et la façon ont elles interagissent entre elles (et les utilisateurs), soit leur structure. C'est vrai qu'il est un peu abusif de parler de "base de données" pour le système actuel reposant sur un ensemble de shapefile, mais c'est bien sa fonction. Je veux donc construire un SGBDR pour "professionnaliser" le système (et surtout pour pouvoir faire du webmapping, plus accessible aux utilisateurs finaux - politiques et institutions - qu'un logiciel de SIG).

@ Jean-Yves G : Vous avez bien compris, on peut même ajouter que certaines parcelles recoupent en partie celles des années précédentes. On est dans un système complétement informel donc pas de cadastre, ni même de suivi par une quelconque autre administration.

Votre solution est séduisante par sa simplicité (une seule table), mais ça ne pose pas de problème qu'il y ai des polygones qui se superposent? Par exemple pour l'affichage dans un SIG? ou alors la création de "vues" par années permet de passer outre ce problème?

Merci encore pour votre intérêt.

Cordialement,

Lucas

Merci pour vos indications.

L'attribut boolean "active" ne me parait pas pertinent car pour les parcelles qui restent "actives", leur qualification (type d'occupation du sol) pouvant changer selon l'année (ex : passage d'un type 'cultivé' à un type 'jachère'), de même que pour les rares parcelles d'agriculture fixe. Il faut donc pouvoir garder une trace de leur type d'occupation en fonction de l'année. Après il peut être possible de saisir plusieurs fois la même entité, avec chacune sont type différent en fonction de l'année. Ça ne me parait pas problématique, sachant que ce cas est marginal. Néanmoins, la question reste qu'avoir des entités qui superposent leur géométrie dans une même table n'est pas problématique? Elles ne pourront pas s'afficher dans un logiciel de SIG avec postgis dans ce cas là. L'utilisation des vues permet-elle de lever cette contrainte? Cela ne va pas poser problème lors des intersections?

C'est vrai qu'elles pourront s'afficher, mais je m'inquiète des problèmes de topologie lors des intersections. Je vais faire quelques essais.

Aloha,

J'interviens après la bataille. Nous avons eu le même type de problématique à traiter lors de la constitution de l'IHU (Inventaire Historique Urbain) sur notre territoire : plusieurs occupation successive avec des activités différentes au même endroit ou avec des emprises changeantes. Nous avons opté pour un modèle relationnel (notamment pour gérer l'ensemble du fond documentaire et les accidents/incidents industriels).
Les occupations sont qualifiées, et pour ce qui vous intéresse, spécifiquement par une date de début et une date de fin. Pour produire une carte des occupations connues à une certaine date, nous procédons par une requête avec une clause type "date between...".
Un changement de destination de l'occupation se caractérise pour nous par la duplication de l'occupation précédente, l'application d'une date de fin, et le renseignement de la nouvelle occupation.

J'espère ma contribution pertinente dans votre contexte.