Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site. Si vous continuez à utiliser ce dernier, nous considèrerons que vous acceptez l'utilisation des cookies. J'ai compris ! ou En savoir plus !.
banniere

Le portail francophone de la géomatique


Toujours pas inscrit ? Mot de passe oublié ?
Nom d'utilisateur    Mot de passe              Toujours pas inscrit ?   Mot de passe oublié ?

Annonce

Suite à un problème technique intervenu entre le 22 et le 23 mars, nous avons du procéder dans la soirée du 25 mars, à la restauration de la base de données du 24 mars (matinée).

En clair, nous avons perdu vos contributions et inscriptions du dimanche 24 et du lundi 25 mars.
Nous vous prions de nous excuser.

#1 Sun 22 April 2018 16:00

Rlucas
Participant occasionnel
Date d'inscription: 20 Apr 2018
Messages: 31

Base de données, évolution temporelle et incrémentation des géométries

Bonjour à tous,

Je travaille actuellement sur la restructuration d'une base de données cartographique suivant l'occupation des sols d'une région (http://www.parc-amazonien-guyane.fr/les … agricoles/).

Chaque année, des images satellites sont traitées (manuellement) afin d'identifier les parcelles et de les classer selon une typologie. Il faut préciser que le type des parcelles change presque tout les ans, étant dans une zone d'agriculture itinérante.

La base était sous format shapefile et des traitements étaient réalisés sous excel après extraction.

J'ai choisi la méthode MERISE adaptée aux SGBR comme cadre pour la restructuration. J'ai réalisé les enquêtes préliminaires et le dictionnaire de données, et je suis bloqué à l'étape du modèle conceptuel de données.

Suivant la méthodologie actuelle, on part d’une ligne de base réalisée la première année du dispositif avec la matrice d’occupation du sol recensant les polygones (=parcelles) identifiés à l’époque selon la typologie en place.

Chaque année, cette matrice est incrémentée en lui superposant le raster et en découpant les nouveaux polygones figurant les ouvertures de parcelles de l’année en cours (qui peuvent très bien se superposer à ceux de l'année passée, ce qui crée de nouveau polygones). Les polygones restants (non modifiés par le redécoupage) sont requalifiés en gardant bien sûr leur attributs des années précédentes. Le nombre de polygones de la matrice croit donc chaque année et leur qualification s'incrémente.

Parallèlement, le découpage des parcelles donne lieu à la création d’une couche annuelle d’occupation des sols, où les polygones sont agglomérés selon leur type pour représenter des parcelles uniques.

La redondance de la base actuelle est donc importance. Je me demande donc quelle est la meilleure manière de représenter le temps dans le modèle :
- Faut-il garder le polygone de la matrice (initiale puis incrémentée) comme entité et donc le temps comme un attribut des polygones (occupation du sol en 20XX), avec le risque d'obtenir une base complétement pixelisée à long terme.
- Faut-il garder l'année comme entité et les géométries/occupation du sol des parcelles comme attribut, mais qui demande à chaque traitement pluriannuel de réaliser une intersection des géométries, ce qui peut être lourd en calcul.
- Faut il prendre les parcelles des différentes années comme entité et l'année comme attribut.
- Faire une entité par occupation du sol?

Bref je suis un peu perdu quand à la définition des entités géographiques quand celles-ci se redécoupent et leurs attributs évoluent dans le temps, et cette question dépasse le cadre de mon cas. J'ai trouvé ce post qui parlait de quelque chose similaire,
https://georezo.net/forum/viewtopic.php?id=53287
Mais dans ce cas me semble-t'il les polygones ne se redécoupaient pas chaque année, seuls leur attributs changaient. J'ai trouvé quelques articles scientifiques sur cette question, mais je vous avoue que j'ai rien compris.
Bref si vous avez des idées sur comment gérer cette question, je vous en serais for gré.

Hors ligne

 

#2 Mon 23 April 2018 08:09

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 Sep 2005
Messages: 3163
Site web

Re: Base de données, évolution temporelle et incrémentation des géométries

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".


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#3 Mon 23 April 2018 08:51

Jean-Yves G
Membre
Lieu: toulouse
Date d'inscription: 12 Oct 2005
Messages: 516

Re: Base de données, évolution temporelle et incrémentation des géométries

Bonjour,

S' j'ai bien compris, chaque année vous avez une nouvelle couche d'occupation des sols , certaines parcelles ne bougent pas et d'autres apparaissent , voire certaines disparaissent.

Au niveau MERISE (que je connais depuis tout petit !!!) , j'identifierais une entité parcelle-culturale , avec une géométrie  un type de culture et une date d'identification.
Cette entité se décline en une grosse table , alimentée chaque année  .... L'historique territorial se fait par jointure "spatiale" , aller chercher tout ce qui s'est passé sur un MEME endroit.
C'est sûr, il y a un gros traitement d'intersection, mais on ne peut pas faire autrement .... sauf si la segmentation des cultures s'appuie sur un parcellaire cadastral fixe , mais je ne crois pas que ce soit le cas.

Cordialement
JYG

Hors ligne

 

#4 Mon 23 April 2018 13:45

Rlucas
Participant occasionnel
Date d'inscription: 20 Apr 2018
Messages: 31

Re: Base de données, évolution temporelle et incrémentation des géométries

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

Hors ligne

 

#5 Mon 23 April 2018 16:13

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 Sep 2005
Messages: 3163
Site web

Re: Base de données, évolution temporelle et incrémentation des géométries

Bonjour,

parce que apparemment UML est orienté objet.


Je confirme ! Et nous nous faisons de la programmation orientée objet ....d'où notre choix.

Effectivement j'opterai pour la solution de JY-G avec une table parcelle-culturale comportant un attribut millésime de type string ou date,  et un attribut boolean "active".
Ce qui permet d'afficher la situation à un instant t (WHERE millésime ='2016') et de connaître la situation actuelle (WHERE active=true).

Ceci permet d'éviter les doublons pour celle qui ne changent pas, je m'explique : si une parcelle culturale apparaît en 2008, je la taggue comme active millésime 2008, si elle reste telle que en 2009 je la laisse active avec un millésime 2008.
Inversement si cette parcelle change (de forme, de lieu, de nature de culture) je la rend inactive et je créé la nouvelle parcelle millésime 2009 active.

Je peux donc remonter le temps et éviter de saisir plusieurs fois la même entité.
C'est ce modèle (millésime, actif) que nous utilisons pour la mise à jour du plan cadastral.

Avec l'espoir que cela vous aidera car passer du SHP et Excel à postgresql/postgis c'est une initiative que je ne peux qu'encourager.


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#6 Mon 23 April 2018 16:47

Rlucas
Participant occasionnel
Date d'inscription: 20 Apr 2018
Messages: 31

Re: Base de données, évolution temporelle et incrémentation des géométries

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?

Hors ligne

 

#7 Tue 24 April 2018 14:06

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 Sep 2005
Messages: 3163
Site web

Re: Base de données, évolution temporelle et incrémentation des géométries

Bonjour,

Elles ne pourront pas s'afficher dans un logiciel de SIG avec postgis dans ce cas là.


L'utilisation de la transparence ?


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#8 Tue 24 April 2018 20:22

Rlucas
Participant occasionnel
Date d'inscription: 20 Apr 2018
Messages: 31

Re: Base de données, évolution temporelle et incrémentation des géométries

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.

Hors ligne

 

#9 Tue 15 May 2018 20:45

Rlucas
Participant occasionnel
Date d'inscription: 20 Apr 2018
Messages: 31

Re: Base de données, évolution temporelle et incrémentation des géométries

Bonjour,

Après plusieurs essais, il apparait que la "superposition" des géométries ne pose pas de problèmes particulier, ni pour l'affichage ni pour les problèmes de géométries lors des intersections. Par contre, la base de donnée se retrouve 10 fois plus chargée (10 ans de données, 40000 enregistrements) et les durées de calcul sont souvent longues, voire font planter la machine, même avec des index.
J'ai pallié au problème de manière détournée en systématisant le recours aux vues et aux tables temporaires (ou aux 'sous-tables') pour réduire l'échantillon traité en fonction d'un critère spécifique, et donc des temps de traitement.
Merci à vous pour vos contributions!

Hors ligne

 

#10 Wed 16 May 2018 11:17

Pierre
DesCartesPourUnMondeMeilleur
Date d'inscription: 22 Sep 2005
Messages: 1643

Re: Base de données, évolution temporelle et incrémentation des géométries

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.


art X I. Déclaration des Droits de l’Homme et du Citoyen 1789
La libre communication des pensées et des opinions est un des droits les plus précieux de l’Homme : tout Citoyen peut donc parler, écrire, imprimer librement, sauf à répondre de l’abus de cette liberté, dans les cas déterminés par la Loi.

Hors ligne

 

Pied de page des forums

Powered by FluxBB