4.5 - Conception et réalisation de la carte d’habitats. IFREMER des habitats marins

ドキュメント

4 - Comment réalise-t-on une carte ? 255

Carte

des habitats du chenal de

Bristol, qui intègre des données biologiques et environnementales. Elle résulte d’une analyse de groupement, ainsi que d’une carte des structures du fond et des figures

sédimentaires

(Mackie et al.,

2006).

4.5 - Conception et réalisation de la carte d’habitats

Au cours de cette quatrième et dernière étape de la production d’une carte d’habitats, un

élément important à considérer est de savoir si le produit final sera sous forme imprimée ou électronique. Une carte imprimée doit être interprétée à une échelle déterminée, alors qu’une carte électronique permet à l’utilisateur de faire à sa guise des zooms avant ou arrière pour obtenir la résolution voulue. Mais même avec une carte électronique, l’utilisateur doit savoir jusqu’à quelle échelle les données permettent de faire un zoom tout en demeurant adéquates ou significatives.

Cette section contient un bref guide de la cartographie électronique, qui porte notamment sur la création de cartes adéquates des habitats benthiques et à leur visualisation dans un

système d’information géographique (SIG). Il propose quelques solutions pratiques pour améliorer le rendu cartographique.

Parmi les éléments importants de la conception d’une carte, on aborde la bonne utilisation de systèmes de coordonnées, les métadonnées, ainsi que l’enregistrement des attributs dans une table (codes d’identification, noms des structures, etc.).

256 4 - Comment réalise-t-on une carte ?

4.5.1 - Réalisation de cartes électroniques à l’aide d’un SIG

Les deux logiciels de SIG les plus couramment employés en Europe pour la réalisation de

cartes d’habitats benthiques sont la suite ArcGIS

de la société ESRI et le logiciel

MapInfo Professional

de la société MapInfo . Les conseils donnés ici sont fondés sur l’expérience de l’utilisation de la suite ArcGIS

de la société ESRI, mais les mêmes principes sont applicables à MapInfo Professional

Systèmes de coordonnées

Il est possible de tracer des polygones dans une couche de données (essentiellement une

carte électronique) sans définir de système de coordonnées associé aux structures. Mais si on veut pouvoir s’en servir plus tard, il est essentiel que le système de coordonnées soit clairement défini. Des fichiers qui ne se rapportent à aucun système de coordonnées ne peuvent pas être visualisés avec d’autres fichiers dont le système de coordonnées est bien défini dans un SIG. Un SIG permet de vérifier quel système de coordonnées se rapporte à un gisement de données, et comporte des outils de définition (ou de changement) de systèmes de coordonnées. Par exemple, les fonctions Projections du module ArcToolbox

permettent :

– de définir le système de coordonnées d’un jeu de données ;

– de modifier les paramètres d’un système de coordonnées déjà défini ;

– de convertir des données d’un système de coordonnées à un autre.

Métadonnées

Une documentation adéquate des gisements de données à l’aide de métadonnées fait gagner du temps par la suite. Les métadonnées sont décrites en détail au chapitre 6 enregistrées avec les données elles-mêmes, ou externes, c’est-à-dire conservées dans un catalogue consultable de métadonnées. Les métadonnées internes accompagnent toujours les données et sont facilement accessibles à tous les utilisateurs. À titre d’exemple, le module ArcCatalog

permet à l’utilisateur de créer des métadonnées internes. Il est possible d’exporter des métadonnées internes vers des bases de données, en général au moyen du langage XML (eXtensible Markup Language – langage de

balisage extensible). Par contre, les métadonnées externes permettent de faire des recherches de manière plus efficace dans de nombreux fichiers, particulièrement si elles sont stockées dans une base de données. Avec des métadonnées externes, il est crucial de définir clairement le lien entre les métadonnées et les données qu’elles décrivent, en utilisant idéalement des identificateurs exclusifs. Par exemple FR000001 désigne la première couche de données constituée par l’Ifremer, partenaire français du projet M

ESH

Lorsque l’on envisage de définir des métadonnées pour une couche de données, la première question à se poser est de savoir si ce sont des métadonnées internes, externes, ou encore une combinaison des deux, qui répondront le mieux aux besoins.

Attributs

Les éléments d’une couche de données vectorielles (polygones, points, lignes) sont normalement associés à d’autres informations sémantiques appelées attributs, enregistrés dans une zone de données contenue dans un fichier d’un SIG. Une couche peut avoir de nombreux attributs (code, libellé, auteur) enregistrés dans des zones distinctes. Les fichiers qui contiennent ces données sont communément appelés tables

d’attributs et servent normalement à l’analyse des données et à la production de cartes.

Il est essentiel que les couches d’information de vos cartes aient les bons attributs, afin que d’autres utilisateurs puissent exploiter au maximum le gisement de données. Lorsque l’on utilise une carte électronique par ailleurs excellente, il est très frustrant de constater

4 - Comment réalise-t-on une carte ? 257 que l’information sur ce qui est réellement présent au fond de la mer à un endroit précis ne fait pas partie du gisement de données. Par exemple, si un cartographe utilise un tableau avec un lien ou un fichier de légende pour documenter les symboles d’une carte, ces données cruciales sont souvent perdues si elles ne sont pas conservées avec le gisement de données. Un autre problème courant vient de l’emploi de codes alphanumériques représentant des catégories de données (par exemple des types d’habitat), lorsque les codes servent à déterminer les couleurs des polygones thématiques de la carte, mais que la légende ne contient qu’une description textuelle des catégories. Il peut être alors difficile de faire le lien entre les descriptions textuelles et les codes correspondants. Pour éviter de tels problèmes, il faut toujours enregistrer toute

information descriptive pertinente associée à des structures sous forme d’attributs dans la

table d’attributs de la couche de données.

Dans les modules d’ArcGIS

, les noms d’attributs sont limités à dix caractères. Il faut donc toujours choisir des noms qui demeurent exclusifs et reconnaissables lorsqu’ils sont tronqués à dix caractères, sinon il peut être difficile d’identifier les attributs. En plus d’un nom, chaque attribut a un type de donnée et une longueur de zone. Par exemple, l’attribut

« Code d’habitat » peut être de type textuel avec une longueur de zone de 20 caractères.

Il faut définir avec soin le type et la longueur de zone des attributs : une zone trop courte pour contenir l’information nécessaire se traduit souvent par des pertes d’information.

Même si la plupart des bases de données modernes (dont ArcGIS

et MS Access) ne font pas la distinction entre les majuscules et les minuscules dans les noms d’attribut, il est bon d’adopter une manière normalisée d’ajouter des attributs dans un fichier de données, par exemple de toujours utiliser des lettres majuscules. Il ne faut pas oublier que d’autres logiciels ou langages informatiques (en particulier ceux qui sont plus anciens) peuvent faire la distinction entre les majuscules et les minuscules lors des recherches dans une table d’attributs. C’est le cas par exemple des modèles HTML utilisés dans le SIG webGIS de M

ESH

pour interroger les tables d’attributs du fichier de formes, et l’emploi erroné de majuscules ou de minuscules dans un nom d’attribut fera

échouer la recherche.

Topologie

En plus de définir un système de coordonnées, d’enregistrer des métadonnées et d’ajouter des attributs, il faut aussi considérer la topologie lorsque l’on crée un gisement de données vectorielles. Dans les SIG modernes, la topologie se rapporte aux relations entre structures adjacentes. Alors que dans les structures de données vectorielles, les relations topologiques entre diverses entités sont explicitement enregistrées, dans les bases de données matricielles, elles ne sont qu’implicitement codées dans les valeurs des attributs des pixels. La topologie peut sembler très éloignée des préoccupations de la

cartographie des habitats benthiques, mais il est essentiel d’en tenir compte lorsque l’on crée des données cartographiques. Les règles topologiques supposent que les structures géographiques existent dans un plan, donc en deux dimensions. Les structures spatiales sont donc représentées par des nœuds (cellules à 0 dimension), des arêtes (cellules à 1 dimension) ou des polygones (cellules à 2 dimensions).

Outils de vérification et d’édition de données cartographiques

Étant donné les règles topologiques appliquées par les SIG, certaines fonctions ne se déroulent correctement que si les couches de données vectorielles contiennent des structures topologiquement correctes (dites « simples »). Par exemple, les outils de l’assistant de géotraitement d’ArcGIS

(dissolution, fusion, union, intersection) risquent d’échouer si les fichiers de formes en entrée contiennent des structures topologiquement erronées (souvent qualifiées de « non simples »). Voici les problèmes topologiques communs dans les fichiers de formes produits à partir de données de cartographie des

habitats benthiques : structures orientées dans le sens anti-horaire plutôt que le sens

258 4 - Comment réalise-t-on une carte ? horaire, « nœuds papillons » dues à des intersections, segments libres (culs-de-sac).

Voici quelques schémas illustrant des structures non simples. a. Polygone non fermé

(les points de départ et d’arrivée sont distincts) d. Polygone orienté dans le sens anti-horaire et non horaire b. Polygone comportant une intersection

(« nœud papillon ») e. Polygone comportant un segment libre

(cul-de-sac) c. Segments d’un polygone non tous orientés dans le même sens

Illustration de structures non simples en vertu des règles topologiques d’ArcGIS

Par conséquent, lorsque l’on produit des fichiers de formes destinés à être analysés ou

édités à l’aide d’outils d’analyse spatiale, il est important de vérifier leur topologie et de simplifier partout où c’est possible les structures non simples.

La vérification par lots des fichiers de formes permet évidemment de gagner du temps.

C’est pourquoi l’équipe du projet M

ESH

a mis au point pour la suite ArcGIS

un ensemble d’outils de traitement par lots de fichiers de formes : structures non simples ;

– simplify shapefiles : simplification des fichiers de formes qui contiennent des structures non simples ;

– dissolve shapefiles : dissolution (fusion) d’un lot de fichiers de formes en fonction d’un

attribut spécifié par l’utilisateur (utile pour la construction de polygones frontières).

Il arrive parfois que l’outil Simplify shapefiles soit incapable de simplifier toutes les structures contenues dans un fichier de formes. Dans ce cas, un ensemble d’outils supplémentaires traite les fichiers de formes un à un pour aider à trouver l’erreur :

– find non-simple features : recherche et simplification des structures non simples dans un fichier de formes, et suppression des structures qui ont une géométrie vide ;

– split multipart features : séparation de structures en structures simples qui conservent les attributs de la structure non simple d’origine ;

– remove interior rings : suppression des anneaux intérieurs de structures, ce qui permet de supprimer les artefacts résultant d’opérations d’union ;

– re-order shapefile : outil de visualisation qui consiste à tracer d’abord les plus grands

polygones afin d’empêcher les plus grandes structures de cacher les plus petites.

Les outils mis au point par l’équipe du projet M

ESH

pour la suite ArcGIS

sont accessibles à tous. Il faut toutefois noter que ni le projet M

ESH

ni le JNCC n’assurent le soutien technique de ces outils, et que l’utilisateur s’en sert donc à ses risques. À ce jour, ces outils n’ont été utilisés qu’avec les versions 8.2 et 8.3 d’ArcGIS

. Il est conseillé de faire des copies de sauvegarde de toutes les données avant de se servir de ces outils.

4 - Comment réalise-t-on une carte ? 259

4.5.2 - Présentation d'une carte

Visualisation des données

Les cartes thématiques qui distinguent des structures selon leurs caractéristiques utilisent des couleurs et des motifs pour mettre en évidence la gamme des valeurs d’attribut de ces structures. Le choix des couleurs et des motifs joue un rôle important dans l’impact visuel d’une carte et dans la facilité d’interprétation de son contenu. Un usage inapproprié des couleurs et des motifs peut rendre inutile une carte par ailleurs excellente ! Les conseils ci-dessous reposent sur notre expérience de l’examen de cartes d’habitats benthiques dans le cadre du projet M

ESH

. Ces conseils ne prétendent pas être exhaustifs et ne constituent pas des règles obligatoires, mais simplement une liste de choses à faire et à ne pas faire lorsque l’on définit un jeu de couleurs et de motifs à utiliser dans une

carte d’habitats benthiques.

À faire

Tenir compte de l’agencement des couleurs de polygones adjacents sur la carte : pourra-t-on les distinguer à une échelle « normale » de visualisation ?

Vérifier si possible l’aspect de couleurs sur différents écrans et avec une variété d’imprimantes, car il y a toujours de légères différences d’un appareil à l’autre dans le rendu des couleurs.

Considérer la taille relative des polygones sur la carte. Par exemple, sur une carte qui couvre à la fois des zones intertidales et subtidales, les polygones des zones subtidales sont généralement plus grands que ceux des zones intertidales. Il est préférable de donner des couleurs claires aux grands polygones pour éviter qu’ils ne dominent la carte sur le plan visuel. Utiliser des couleurs soutenues pour mettre en

évidence les petites zones intertidales sur la carte.

Se rappeler que les utilisateurs regardent souvent une carte à des échelles plus ou moins globales (zoom arrière) ou fines (zoom avant). Les systèmes de cartographie

électronique permettent à l’utilisateur de faire à sa guise des zooms avant ou arrière ;

à une échelle globale, les couleurs attribuées à un niveau très détaillé d’une typologie peuvent devenir impossibles à distinguer.

Penser aux utilisateurs qui distinguent mal les couleurs (daltoniens), en particulier à ceux qui sont incapables de distinguer le rouge et le vert.

Étudier l’aspect qu’aurait un jeu de couleurs existant sur une carte. Cela peut enrichir la carte, puisque les utilisateurs habitués aux jeux de couleurs existants arrivent facilement à l’interpréter. L’équipe du projet M

ESH

a conçu un jeu de couleurs pour la

typologie E

UNIS

(version 2004), que l’on peut utiliser pour les polygones correspondant aux classes d’habitats de la typologie E

UNIS

. Les classes d’habitat des niveaux 4, 5 et 6 de la typologie E

UNIS

sont regroupées de telle sorte que l’on ne peut distinguer les types d’habitat que jusqu’au niveau 3 inclusivement, par exemple A1.1.

Considérer la forme – électronique ou imprimée – sous laquelle la majorité des utilisateurs verront la carte. Si la carte est surtout destinée à être vue sous forme

électronique dans un SIG, le jeu de couleurs peut être assez simple, car les outils standard d’interrogation permettent d’obtenir plus de détails sur demande. Dans le cas d’une carte imprimée, il faut choisir un jeu de couleurs adéquat selon l’échelle d’impression prévue.

Enregistrer le jeu de couleurs et le conserver avec le fichier. Dans ArcGIS

par exemple, on peut créer un style qui permet d’appliquer un même jeu de couleurs à plusieurs cartes. D’autre part, dans le cas d’un jeu de couleurs propre à une carte, on peut créer un fichier de couche (.lyr), mais il faut veiller à ce que ce fichier accompagne toujours le fichier de formes, notamment lorsque ce dernier est transmis

260 4 - Comment réalise-t-on une carte ?

à un tiers ! Si aucune autre option n’est disponible, il est même possible de noter les composantes RVB (rouge, vert, bleu) de chaque couleur dans un fichier texte, afin que d’autres utilisateurs puissent recréer les mêmes couleurs dans un autre logiciel (un autre SIG ou un logiciel graphique utilisé pour produire des publications). Ce serait du gaspillage de définir un jeu de couleurs pour une publication sans pouvoir le reproduire ultérieurement.

À ne pas faire

Définir un jeu de couleurs trop complexe et difficile à interpréter. Même s’il est possible d’utiliser une gamme presque infinie de couleurs et de motifs dans un SIG, cela ne donne pas nécessairement des cartes claires ! Il n’est pas obligatoire d’attribuer une couleur ou un motif propre à chaque structure qui a un attribut différent.

Le regroupement d’habitats benthiques par types semblables est une possibilité pratique. Une règle empirique souvent adoptée limite à environ 15 le nombre de catégories de couleur différentes, soit le maximum qui semble facile à distinguer pour un utilisateur.

Construire une carte symbolique avec des codes d’attribut qui n’ont pas de signification courante (p. ex. des nombres entiers pour représenter des descriptions d’habitat), puis mettre dans la légende un texte décrivant les habitats. Il vaut mieux ajouter à la couche de données vectorielles des attributs descriptifs interprétables par d’autres utilisateurs (p. ex. des descriptions ou des codes d’habitat tirés d’un système reconnu). Le jeu de couleurs est alors utilisable pour n’importe quel attribut, alors que l’information importante est enregistrée dans la couche de données.

Écrire un long texte dans une légende. Il est extrêmement difficile d’interpréter une

carte dont la légende est trop complexe, et l’impact visuel de la carte risque d’en souffrir.

Utiliser des frontières trop foncées qui masquent le contour interne des structures ; ce problème se pose souvent dans le cas de petites structures.

Définir un jeu de couleurs pour une carte imprimée sans vérifier l’aspect des couleurs

à l’impression. Deux couleurs distinctes à l’écran peuvent se ressembler à l’impression (et vice versa).

Présentation

Les éléments traditionnels de présentation d’une carte (titre, texte, légende, échelle graphique, logo) sont parfois omis dans une carte électronique. Ils sont néanmoins essentiels pour qu’une carte soit facile à interpréter. Voici les éléments importants à inclure :

– une flèche orientée vers le nord indiquant l’orientation de la carte ; distances entre structures sur la carte ; l’échelle graphique prend la forme d’une barre généralement subdivisée en plusieurs parties, avec une indication d’unité (p. ex. km, mètre) ; de la carte et des structures qui y figurent (p. ex. 1/10 000, ou 1cm pour 10 km) ;

– le système de coordonnées.

Une légende doit contenir des noms clairs et faciles à comprendre pour les trames de données, les couches, les en-têtes et les classes.

4 - Comment réalise-t-on une carte ? 261

Liens vers des documents

INFOMAR : http://www.marine.ie/home/services/surveys/seabed/

Norvège : http://www.mareano.no/english/index.HTML

CCW intertidal mapping.htm : http://www.marlin.ac.uk/Conference99/Demonstrations/Countryside%20Council%20for%20

Wales/MappinginWales.htm

Guide d'utilisation du logiciel HMP : http://www.searchmesh.net/pdf/GMHM4_Manual_for_Habitat_Matching_Program.pdf

UNIS

_2004_report.pdf : http://www.searchmesh.net/PDF/GMHM4_E

UNIS

_2004_report.pdf

MNCR_04_05_introduction.pdf : http://www.searchmesh.net/pdf/GMHM4_MNCR_04_05_introduction.pdf

WE_Imares_Musselbeds.pdf : http://www.searchmesh.net/default.aspx?page=1756

La typologie des habitats marins de Grande-Bretagne et d'Irlande : http://www.jncc.gov.uk/Default.aspx?page=1584

La typologie européenne E

UNIS

: http://eunis.eea.europa.eu/habitats.jsp

Technical Summary and Examples.doc : http://www.searchmesh.net/pdf/GMHM4_Habitat_Matching_Program_Technical_Summary_

&_Examples.pdf

Manual_for_Habitat_Matching_Program_v2.pdf : http://www.searchmesh.net/PDF/GMHM4_Manual_for_Habitat_Matching_Program.pdf

PRIMER : http://www.primer-e.com/

MVSP (Multi Variate Statistical Package – Logiciel statistique d’analyse multivariée) : http://www.kovcomp.com/)

CLUSTAN (CLUSter ANalysis – Analyse de groupement) : http://www.clustan.com/

UNIS

application v3.doc : http://www.searchmesh.net/PDF/GMHM4_E

UNIS

_application.pdf

UNIS

marine proposal proforma v3.xls : http://www.searchmesh.net/default.aspx?page=1864

Document sur la cartographie des habitats benthiques en zone côtière de petit fond : http://www.searchmesh.net/PDF/GMHM4_Mapping_shallow_coastal_benthic_habitats_(2).pdf

UGent_Multivariate_geostatistics.pdf : http://www.searchmesh.net/pdf/GMHM4_Multivariate_geostatistics.pdf

Dummy_file_WE_TNO_interpolation_fractions.doc : http://www.searchmesh.net/Default.aspx?page=1625

L’indice de position bathymétrique : http://www.searchmesh.net/pdf/GMHM4_Bathymetric_position_index_(BPI).pdf

Dummy_file_WE_TNO_Sand wave height map_DCS.doc http://www.searchmesh.net/Default.aspx?page=1625

WE_Ifremer_lidar.pdf : http://www.searchmesh.net/pdf/GMHM4_Mapping_Substrata_using_LIDAR.pdf

Catalogue de signatures d'habitat : http://www.rebent.org/mesh/signatures/

Manuel d’instructions : http://www.rebent.org/mesh/signatures/search/search.php?mode=habitats

Aperçu des techniques statistiques : http://www.statsoft.com/textbook/stathome.HTML

262 4 - Comment réalise-t-on une carte ?

WE_Ifremer_predictive_modelling_seaweeds.pdf : http://www.searchmesh.net/PDF/GMHM4_Predictive_modelling_seaweeds.pdf

Habitat_suitability_modelling_M

ESH

.pdf : http://www.searchmesh.net/PDF/GMHM4_Habitat_suitability_modelling_M

ESH

.pdf

Maerl regression.pdf : http://www.searchmesh.net/PDF/GMHM4_Mitchell_Collins_2004_maerl_regression.pdf

ENV CS05 Maximum Likelihood Classification of AGDS Data.pdf : http://www.searchmesh.net/PDF/GMHM4_Maximum_Likelihood_Classification_of_AGDS_D ata.pdf

ENV CS09 Prior Probability Classification.pdf : http://www.searchmesh.net/pdf/GMHM4_Prior_Probability_Classification.pdf

Définition des réseaux neuronaux : http://www.statsoft.com/textbook/stathome.HTML

Définition de l'analyse discriminante : http://www.statsoft.com/textbook/stdiscan.HTML

WE_UGent_Habitatsuitability_E

UNIS

.pdf : http://www.searchmesh.net/PDF/GMHM4_Habitat_suitability_modelling_M

ESH

.pdf

Highland Shellfish Management.pdf : http://www.searchmesh.net/pdf/ENV%20CS07%20Highland%20Shellfish%20Management.pdf

Worked Example - M

ESH

UNIS