ZonAgri - Objectifs - Interface

Objectifs - Interface

Figure C2.1. - Explorateur, vues sous forme Tableau et Carte

L'interface proposée permet de :

• définir des modèles, des documents sous forme d'objets structurés ;

• faciliter la sélection de ces objets à partir d'un explorateur ou par lien (menu contextuel Objet) dans une fenêtre de Vue ;

• visualiser les objets sous différentes facettes (description, définition, validité, résultats divers, etc) sous forme de Tableau, Graphique, Carte, etc.

Le menu et la barre d'outils Affichage     |    |            permet de visualiser différents aspects de l'objet sélectionné.

  Précédent

  Suivant

  Mise à jour

  Nouvel onglet

  Fermeture onglet

  Descriptions

  Attributs

  Définition complète

  Données par types

  Problèmes de définition

  Résultats

Le menu et la barre d'outils Edition     |   permettent les échanges de données entre objets et avec d'autres applications en utilisant le Presse-Papiers du système d'exploitation. Ceci est en particulier utile pour copier des caractéristiques identiques entre composants ou pour coller des définitions ou des résultats dans des traitements de texte ou des tableurs.

  Couper

    Copier

    Coller

    Annuler annule la dernière modification de définition active dans la liste des changements.

    Rétablir

Le menu et la barre d'outils Fichier      permettent l'ouverture et la sauvegarde de documents.

  Nouveau

    Ouvrir

    Sauvegarder

donne accès à une boîte de dialogue d'enregistrement de fichiers. Cette commande permet de sauver l'aménagement actif, la simulation courante, etc - voir Les fichiers d'entrées - sorties E1.

A FAIRE

A FAIRE

A FAIRE

Tout objet manipulé possède sa propre représentation graphique, qui peut être visualisée à partir de l'onglet du bas Graphique. Cette représentation fait référence à certaines caractéristiques : par exemple les courbes de remplissage d'un réservoir, la variation de la demande pour une consommation en eau - voir Figure C5.1 -, la variation des débits réservés pour un arc naturel, etc.

Sur tous les graphiques, vous pouvez utiliser les fonctionnalités suivantes :

• effectuer un zoom avec le bouton gauche de la souris et la touche Maj du clavier enfoncés ;

• obtenir une vue générale du graphique, après un zoom, par action de la touche R du clavier ;

• modifier une valeur avec le bouton gauche de la souris et la touche Ctrl du clavier enfoncés ; lorsque la valeur est éditable, la modification de la définition est dynamique ;

• modifier des propriétés du graphique par l'action du bouton droit de la souris ; une fenêtre à onglets permet alors de définir des titres, de modifier des couleurs ou des symboles de courbes, etc.

Figure C5.1. - Histogramme - Vue Graphique

Sur les présentations sous forme d'histogrammes en 3 dimensions, comme sur la Figure C5.1, vous pouvez utiliser les fonctionnalités suivantes :

• effectuer une rotation avec le bouton gauche de la souris enfoncé ;

• visualiser les valeurs par déplacement de la souris sur le graphique.

Le tableau de ces caractéristiques est obtenu par l'action du bouton Données par type    de la barre d'outils Vues (voir la Figure C5.2). Les définitions sont éditables.

Ces définitions sont également placées dans le Presse-Papiers de l'environnement graphique par exemple Microsoft Windows. Les graphiques peuvent ainsi être obtenus à partir d'un tableur du type Microsoft Excel en utilisant simplement le bouton Coller  . Ce fonctionnement de type Copier  - Coller   est généralisé à toute l'interface, il est ainsi possible d'exporter mais aussi d'importer des données d'autres applications.

Figure C5.2. - Histogramme - Vue Tableau

La vue Carte permet de représenter les bassins versants en plusieurs couches (au moins 2) avec les contours et les réseaux hydrographiques. D'autres fonds cartographiques pourraient être présents sur d'autres couches (limites adminsitratives, villes, etc).

Figure C6.1. - Bassins versants - Vue Carte

L'utilisateur dispose de très nombreuses fonctionnalités afin d'adapter la vue en fonction de son attente du moment. Il est ainsi possible de :

• détailler et cadrer les vues, par des zooms (utiliser la boîte de règlage du zoom dans la barre d'outils ou cadrer votre vue par sélection d'une zone avec la souris, la touche "Shift" du clavier étant pressée, le curseur devient ) et des déplacements panoramiques (utiliser les barres de défilement), sans déformation grâce au traitement vectoriel ;

• définir les couches graphiques à afficher (icones visibilité dans le tableau de gestion des couches), correspondant à un classement des objets par thèmes, jouer sur l’opacité des couches pour visualiser de l’information correspondants à des objets superposés, choisir d'afficher les labels des objets à partir des cases à cocher texte ;

• visualiser les objets d’une couche suivant le classement d'une information associée, par exemple types d'objets ou classes de valeurs. On peut ainsi décliner les vues suivant différentes légendes, ordre de Strahler dans notre exemple.

De manière pratique, vous pouvez utiliser les fonctionnalités spécifiques suivantes :

• sélectionner différents objets par l'action du bouton gauche de la souris sur un objet ou en définissant une zone, la sélection étant le mode par défaut ;

• déplacer les objets sélectionnés par l'action du bouton gauche de la souris, la touche Alt du clavier étant pressé (ou passer en mode édition-déplacement) ;

• déplacer des points des objets sélectionnés par l'action du bouton gauche de la souris, la touche Ctrl du clavier étant pressé (ou passer en mode édition-édition de points) ;

• utiliser le menu contextuel (bouton droit de la souris) pour voir l'objet sélectionné ( Objet), Copier les objets (voir l'exemple sur la Figure suivante), etc.

A FAIRE

A FAIRE

Objectifs - Interface

La problématique

Le domaine de recherche de Christophe Cudennec est la modélisation hydrologique à base géomorphologique pour la gestion territoriale de l'eau. Ce titre scientifique décrit la recherche de modèles pluie-débit qui permettent de quantifier certaines relations entre le territoire et les circulations d'eau, et donc d'envisager un aménagement du territoire en vue de la réduction des dégâts dus aux fortes pluies.

Lorsque l'on parle ici de modèle, il s'agit d'une simplification de la réalité pour pouvoir appliquer des concepts et faire de la quantification. Un modèle pluie-débit permet de lier les pluies qui couvrent un territoire avec la quantité d'eau s'écoulant à un endroit donné pour un temps donné. Une fois un tel modèle correctement défini, l'opération inverse peut être envisagée, c'est-à-dire déduire de la quantité d'eau qui s'écoule les caractéristiques de la pluie tombée.

La problématique qui se cache derrière cette recherche est et sera de plus en plus d'actualité dans la région du Languedoc-Roussillon : les crues et la gestion de l'aménagement territorial afin de faire face à ces crues. Ce sont les précipitations de fortes intensités plutôt que le total annuel des précipitations qui causent souvent les catastrophes naturelles, comme les inondations exceptionnelles. Les précipitations fortes dépassent la capacité d'infiltration du sol et se traduisent par un ruissellement de surface qui peut devenir excessif et générer des crues importantes en aval.

Figure A.1.1 - - Le rôle intégrateur du bassin versant à l'échelle de l'évènement hydrométéorologique (Source Cudennec, 2001)

Le problème actuel est que chaque aménagement, aussi bien à l'échelle de l'agriculteur qui cherche à protéger ses récoltes qu'à l'échelle de la commune qui cherche à protéger ses habitants et leurs biens, résout des problèmes locaux de crues. Les acteurs individuels aménagent leur partie de territoire de manière à réduire les conséquences localement, sans forcément étudier l'effet de ces aménagements sur les territoires plus en aval. Pour prévenir au mieux les conséquences de ces évènements naturels, l'idée est d'étudier le comportement du territoire et de ces aménagements à un plus haut niveau d'organisation des cours d'eau et donc de résoudre les problèmes à ce niveau d'organisation : celui du bassin versant.

Le bassin versant est un territoire sur lequel les gouttes de pluie qui tombent s'écoulent, puis se rejoignent en un même endroit : l'exutoire (remarque : il existe toujours une partie de la pluie qui est stockée dans des réserves souterraines ou en surface, qui retourne à l'atmosphère par évaporation ou qui " fuit " en profondeur). Un bassin versant possède des frontières naturelles qui suivent des lignes naturelles et définissent généralement une zone fermée. Nous pouvons donc définir qu'un bassin versant est une zone délimitée par un contour. Les gouttes de pluie peuvent aussi s'infiltrer dans la roche et former des réservoirs ou des nappes souterraines ; il existe alors une circulation souterraine des eaux.

Dans un bassin versant, l'eau s'écoule toujours d'un point haut vers un point bas, soit de l'amont vers l'aval. Sur son chemin, elle recueille les eaux d'autres cours d'eau, plus petits. Ils sont appelés les affluents.

Il faut noter l'existence, à la surface du bassin versant, d'un système longitudinal, le réseau de drainage ou réseau hydrographique, défini comme l'ensemble des cours d'eau naturels ou artificiels, permanents ou temporaires, qui participent à l'écoulement. Ce réseau est plus ou moins développé selon différents facteurs (géologie, climat, pente du terrain, etc.). La carte 1 présente l'exemple du réseau hydrographique du bassin versant de Skhira :

Figure A.1.2 - - Présentation du bassin versant de Skhira (Source Cudennec et al, 2005)

En définitive, le réseau hydrographique est donc un objet ramifié et hiérarchisé. Pour un bassin versant, outre l'exutoire, unique extrémité aval, le réseau hydrographique est composé de points particuliers : les extrémités amont, appelées sources, ainsi que les jonctions entre plusieurs - en général deux - branches du réseau, c'est à dire les confluences. La fraction du réseau hydrographique comprise entre deux confluences ou bien entre une confluence et une extrémité est appelée bief.

Etudes de bassins versants - Caracteristiques du reseau hydrographique" />

Dans notre objectif, la plupart des statistiques géomorphométriques d'un bassin versant seront générées à partir des caractéristiques du réseau hydrographique. Nous les définissons donc maintenant afin de ne pas perdre le lecteur par des définitions hydrologiques au milieu de la description du logiciel.

Donc, la caractéristique la plus simple à calculer, mais dont tous les autres calculs dépendent, est la longueur de chacun des biefs du réseau. En connaissant ces longueurs, il sera possible de calculer les longueurs pour d'autres éléments du bassin versant.

Une des principales études à faire sur un bassin versant est celle de la classification de son réseau hydrographique. La classification est facilitée par un système de numérotation des biefs. L'ordre des cours d'eau est donc une classification qui reflète la ramification du cours d'eau. Il existe plusieurs types de classification des biefs, dont la classification de Strahler (1952), qui est la plus utilisée. C'est celle que nous utiliserons.

Cette classification permet de décrire sans ambiguïté le développement du réseau de drainage d'un bassin de l'amont vers l'aval. Nous allons tout d'abord considérer l'ordre de Strahler sur un réseau hydrographique binaire car, dans un milieu naturel, les confluences multiples sont rares. Donc, sur un réseau hydrographique binaire, l'ordre de Strahler se base sur les règles suivantes :

La figure suivante illustre l'ordre de Strahler sur le réseau hydrographique binaire du petit bassin versant tunisien de Hadada.

Figure A.1.3 - Application des ordres de Strahler au réseau hydrographique binaire du bassin versant de Hadada (Tunisie)

Figure A.1.4 - Application des ordres de Strahler à un réseau hydrographique non binaire extrait d'un MNT

Enfin, les longueurs des chemins (de chaque bief et de chaque point de la grille d'échantillonnage) et de leurs composantes sont considérées en termes statistiques et cartographiques.

L'analyse du comportement hydrologique d'un bassin versant (système hydrologique) s'effectue par le biais de l'étude de la réaction hydrologique du bassin face à une sollicitation (la précipitation). Cette réaction est mesurée à l'exutoire du système hydrologique par l'observation d'un hydrogramme qui n'est autre que la représentation de l'évolution du débit Q en fonction du temps t.

Figure A.1.4 - Principes d'analyse du comportement hydrologique du bassin versant et hydrogramme résultant (Source http://hydram.epfl.ch/e-drologie/)

Il s'agit donc d'analyser le débit d'eau dans le cours du temps à l'exutoire d'après des relevés spatio-temporels de la pluie.

Pour calculer ce débit au cours du temps, il suffit alors d'appliquer un champ de pluie, c'est-à-dire la quantité de pluie tombée à un instant t et à une position dans l'espace p, à la représentation du bassin versant sous forme de zones isochrones. On peut alors prévoir, à chaque pas de temps suivant, la quantité d'eau provenant de ce champ de pluie et arrivant à l'exutoire. Il faut pour cela calculer la pluie nette, c'est-à-dire la quantité de pluie qui va s'écouler à travers le réseau hydrographique, à partir de la pluie brute, c'est-à-dire la quantité d'eau spécifiée par le champ de pluie. Il suffit alors d'appliquer le champ de pluie dans le temps et dans l'espace, c'est-à-dire de prendre en compte la variabilité de l'intensité et de l'emplacement des nuages de pluies, et on obtient un débit théorique dans le temps que l'on peut comparer au débit réel.

Pour cela, il est donc envisageable de déduire les zones isochrones en terme de temps d'écoulement, à partir de caractéristiques du réseau hydrographique. Les zones isochrones définies représenteront alors les zones d'égal temps de parcours de l'eau jusqu'à l'exutoire via le réseau hydrographique. Le tracé du réseau des isochrones permet donc de comprendre en partie le comportement hydrologique d'un bassin versant et l'importance relative de chacun de ses sous bassins.

Figure A.1.5 - Présentation des isochrones du bassin versant de Skhira (Source Cudennec et al, 2005)

Les zones isochrones et les comportements hydrauliques alors définis, on aboutit alors au graphique qui suit :

Figure A.1.6 - Champ de pluie appliqué aux zones isochrones d'un bassin versant (Source Cudennec et al, 2005)

OdefiX - Objectifs - Interface graphique - API - GUI

Cette partie présente l'architecture générale du développement. Elle détaille notamment les classes créées pour concevoir l'interface graphique générique présentée à la section précédente.

L'architecture de l'application, présentée dans la figure 5.1, est définie par le regroupement de classes dans des paquetages. Les relations entre paquetages définissent les dépendances dans l'application et déterminent la stabilité de l'architecture.

Figure 5.1. - Architecture générale

• Le paquetage java regroupe tous les paquetages du kit de développement fourni par Sun Microsystems. Nous utilisons le JDK 1.4 (Java Development Kit).

• Le paquetage data contient des classes nécessaires à la construction et à l'évolution des modèles.

• Le paquetage gui : Graphical User Interface regroupe les classes écrites pour l'interface graphique de l'application. Ce package est fortement lié au package data puisqu'il sert à les figurer, ainsi qu'à les manipuler et les visualiser.

• Le paquetage applicatif_métier applicatif_métier correspond aux classes propres à un modèle spécifique. Ce dernier est basé sur le package data, les données d'un modèle dérivant des données génériques. Le package gui sert quant à lui à représenter ces données

L'intérêt de l'architecture réside dans la souplesse de modification pour ajouter de nouvelles caractéristiques. La génération d'applicatifs dédiés est facilitée par la structuration proposée, qui permet ainsi une extension aisée des types de composants à étudier.

Les classes de base

La présentation de l'interface graphique générique a montré l'intérêt de spécifier la notion générale de définition. Tout objet manipulé peut être traité comme une définition plus ou moins complexe. Il peut se ramener dans tous les cas à la définition d'une donnée de type simple comme une chaine de caractères, un réel, un entier, un booléen. Ces données peuvent elles mêmes être traitées comme des définitions.

Dans OdefiX, les données manipulées par le modèle seront toutes décrites par une Definition. Tout objet du monde réel nécessaire au modèle, qu'il soit concret (réservoirs, bassin versant, etc.) ou abstrait (chroniques des pluies ; variation dans le temps de certaines données, etc. ), pourra et devra être représenté par une Definition. Ces définitions sont plus ou moins complexes selon le type d'élément qu'elles vont figurer.

Figure 5.2. - les classes de base

L'abstraction Definition

Pour un objet, être une Definition assure de la spécification de :

• un label, qui constitue la dénomination de l'objet ;
• un identifiant le définissant de manière unique ;
• un type, qui permet de qualifier l'objet par une brève description (méthode getType()) ;
• la représentation et l'affectation possible des données sous forme d'une chaine de caractères (méthodes toString() et set(String s)) ;
• la validité de l'objet (renvoi des incohérences);
• la représentation de l'objet, sous forme d'un modèle de tableau (TableModel), suivant différents points de vue : description, définition, validité, résultats, etc.

Toute Definition possède également un formalisme en XML et pourra donc être stockée dans un fichier au format XML puis restaurée depuis ce fichier. Cet enregistrement/restauration des données en tant que fichier ne se fait que pour les Definition qui sont également des Documents. Toute Definition possèdera forcement un Document comme parent dans un des niveaux supérieurs de sa hiérarchie. Un document est une définition complexe, extensible, qui peut être chargée et sauvée au format XML. C'est un composant de base de l'environnement de travail.

L'avantage des Definitions est l'homogénéité. En effet, si chaque modèle et ses données sont représentés sous forme de Definition, il sera d'autant plus simple de faire cohabiter les modèles, ce qui est la finalité d'OdefiX.

-A VOIR-
- explications sur persistance en XML
- explications sur gestion de l'indexation
- explications sur la gestion des modifications sep-2004

OdefiX offre un ensemble de Definitions qui seront communes à de nombreux modèles. Il fournit pour cela des Definitions correspondant aux données primitives des langages de programmation (les chaînes de caractères, les nombres entiers, les nombres à virgule flottant, les booléens ), ainsi que l'équivalent des tableaux à une et deux dimensions de ces données primitives.

A chaque définition Data est associé un DataType, qui spécifie le type des données représentées (un nombre représentant un débit est différent d'un nombre représentant une coordonnée). Un type Datae données possède donc différents attributs (des bornes de validité minimale et maximale, une valeur par défaut, une unité, un format, une précision, etc.) Ces types de données sont répertoriés dans des catégories et principalement défini dans des fichiers XML. Les types de données communs à tous les modèles sont stockés dans la catégorie OdefiX, tandis que chaque modèle spécifique possède sa propre catégorie, et éventuellement son propre fichier XML.

Figure 5.3. - les définitions de type de base

Exemple de types simples sous leur forme XML :
Le type de la catégorie OdefiX décrivant un nombre à virgule flottant quelconque :
<type id="real" label="Real" base="real" minValue="0" maxValue="1000000000000" precision="0.01" format="0.0#"/>
Le type de la catégorie ZonAgri décrivant un prix se basant sur le type simple de base décrit ci-dessus:
<type id="price" label="Prix total" base="real" desc="Prix des produits total" minValue="0" maxValue="100000" precision="0.01" unit="euro" cumul="true" format="0.00" holeValue="-1"/>

-A VOIR-
- explications sur le formatage
- explications sur la gestion des unités

Une Definition possède un contenu qui peut être simple ou complexe, extensible ou prédéfini. Une Definition complexe pourra donc contenir d'autres Definition, elles-mêmes pouvant être complexes. Il apparaît alors la notion de hiérarchie, chaque Definition possédant une Definition parent et des Definitions enfants, en ce qui concerne les complexes. Les Definitions extensibles peuvent recevoir un certain nombre de Definition d'un certain type, défini par le programmeur et correspondant à la nature spécifique de l'objet contenant.

Figure 5.4. - les définitions "complexes"

Par exemple, un réservoir peut être défini pour une contenance maximum et un débit constant, qui seront tous deux des définitions simples. Une zone géographique peut alors être décrite comme un ensemble de réservoirs. Ce sera alors une définition complexe et extensible, qui possèdera une liste de réservoirs, c'est-à-dire une liste de Definitions complexes.

- soit créer une Definition qui n'est en fait qu'un raccourci, une référence à une Definition déjà définie ailleurs dans l'arborescence de l'environnement de modélisation. Ainsi, toute Definition de type Document sera manipulée à travers des associations ;

- soit définir une liste de Definition, à partir de laquelle on pourra choisir le type de Definition de l'objet. Par exemple, une valeur peut être définie par un nombre ou bien par un calcul (une formule). Ce sera à l'utilisateur de choisir le mode de définition.

Figure 5.5. - les associations

La figure 5.5 présente l'arbre d'héritage des classes pour la gestion du temps : pas de temps, variations saisonnières, chroniques, etc.

Figure 5.5. - Les classes de gestion du temps

Le pas de temps est introduit par la classe abstraite TimePeriod qui hérite de AbstractIntDefinition. La classe TimePeriod assure en plus la spécification :

• d'un calendrier de référence, on utilise le calendrier grégorien disponible dans le paquetage java.utilgetCalendar()) ; (méthode
• d'un format de date (méthode getFormat()) ;
• du passage au pas de temps suivant (méthode toNext()) ;
• du nombre de jour du pas de temps (méthode getDays()) ;
• de diverses méthodes intéressant les dates (méthode isLeapYear(int _year), etc).

Les classes YearStep, MonthStep, D10Step et DayStep assurent l'implémentation de la spécification d'un pas de temps respectivement annuel, mensuel, décadaire (au sens météorologique c'est à dire période du 1 au 10, du 11 au 20, et du 21 à dernier jour du mois) et journalier.

La variation saisonnière d'une caractéristique numérique est introduite par la classe YearlyVariation qui hérite de TimeVariation donc de AbstractDefinition. La classe YearlyVariation assure, à partir de la définition des valeurs mensuelles interannuelles, la spécification :

• de la valeur de la variable pour une décade ou un jour particulier, actuellement traitée par interpolation linéaire (méthodes getValue(D10Step _step) et getValue(DayStep _step)) ;
• de chroniques de valeurs interpolées en décadaire et journalier (méthodes getD10Chronicle() et getDayChronicle).

La classe Chronicle permet de définir la variation d'une caractéristique numérique à pas de temps fixe sur une grande période. La chronique peut être affectée à partir d'un fichier (méthode set(java.io.File file)). Le pas de temps début (méthode getFirstStep()) spécifie le type de variation : annuelle, mensuelle, décadaire ou journalière.

-A VOIR-
- explications sur le package data.time

Cette extension est basée sur une structuration générique des données (gestion de cartes, plans, schémas, graphes, etc) par un typage des informations et propose une formalisation de la gestion du temps autorisant les animations graphiques.

Figure 5.6. - Les classes de représentation en 2D

Le document cartographique est une Definition composée d'objets Couche. Un document peut contenir une ou plusieurs couches. Chaque couche correspond à une agrégation d'objets permettant une représentation en deux dimensions et possédant des informations associées.

Ces objets, que nous dénommons Série, sont donc décrits par une série de valeurs x et de valeurs y, les types de valeurs correspondants et une liste d'informations associées.

-A VOIR-
- explications sur le package data.map
- explications sur les parsers ASCII dont le parser Mif/Mid