% Template GRASS newsletter - Article
% Language: Latex
%


% 
% TODO reference code snippets, try to use a set of examples that people can try on their own
% might be good to post the inputs on the website.
% 

% 
% TODO how can we include long URLs ?
% 

% 

\title{Créer des cartes prêtes à être publiées avec GRASS et GMT}
% \subtitle{An alternative approach to the production of press-ready maps}
\author{par Dylan Beaudette, traduit par Yves Jacolin}

\maketitle

\section{Aperçu}
\label{sec:overview}
La publication de cartes imprimables de haute qualité est un composant important de la plupart des analyses géographiques. Bien que GRASS n'ait pas été écrit pour la production de matériels imprimables, les commandes du type \texttt{ps.map} et plus récement un wrapper bien utile \texttt{G-ps.map}, lui permettent de sortir des cartes postscripts de haute qualité. Cependant, la syntaxe et les possibilités plutôt limitées de l'approche \texttt{ps.map} produisent souvent une carte qui doit être finalisée dans un logiciel de PAO (Publication Assisté par Ordinateur) tel que Inkscape, Scribus, ou The GIMP. La fonctionnalité composer une carte trouvée dans QGIS peut être une bonne alternative dans un proche futur, mais la version actuelle manque de flexibilité, de stabilité, et de la possibilité d'exporter des données dans des formats tels que EPS ou PDF. Avec de telles options limitées pour la production de cartes à imprimer de grande qualité dans un processus open source, de nombreuses personnes ont bricolé ensemble le nécessaire requis pour interfacer GRASS avec de nombreux programmes comme le paketage Generic Mapping Tools. Le projet GMT est très bien décrit par ses auteurs :

\begin{quotation}
GMT est une collection open source d'une soixantaine d'outils pour la manipulation de jeux de données Cartesian et géographiques (comprenant les filtres,  l'ajustement de la direction, la création de grilles, la projection etc.) et la production dans des fichiers PostScript Encapsulé (EPS) d'illustrations qui vont du simple graphe x-y en passant par des cartes de contour à la surbrillance articielle des surfaces et des vues en perspective en 3D. GMT gère environ 30 projections et transformations cartographiques et est fourni avec des données telles que la ligne des côtes, les rivières, les limites politiques. GMT est développé et maintenu par Paul Wessel et Walter H. F. Smith avec l'aide d'une équipe de volontaires, et est géré par la Fondation Nationale des Sciences. Il est diffusé sous la licence GNU General Public.
\end{quotation}

\noindent
Cet article décrit les efforts combinés de plusieurs personnes (David Finlayson, Hamish Bowman, Brent Wood, moi-même, et d'autres) pour créer le moyen d'interfacer GRASS à GMT. Plusieurs permutations des commandes du style \texttt{*.out.gmt} ont été créées, en utilisant à la fois des scripts Python et Bash, pour réaliser l'export nécessaire, la configuration, et l'exécution des commandes GMT. Aprés avoir lu cet article vous devriez avoir une idée générale pour composer de simples cartes dans GMT, avec des scripts modèles pour l'utilisation de données exportées de GRASS. L'article suivant présentera des exemples spécifiques à Spearfish (le jeu de données standard de GRASS) de création de cartes avec GMT.

\subsection{GMT}
\label{sec:GMT}
Les applications des Outils de Cartographie Générique (GMT) peuvent être installées sur n'importe quelle plate-forme soit par des binaires préparés ou en compilant le code source. Les outils GMT peuvent aussi être installés à partir de votre système de gestion de paquets de votre distribution (par exemple aptitude), cependant cette méthode n'est pas recommandée puisque le paquet a de grandes chances de ne pas être à jour. Si vous êtes sur un système d'opération de type UNIX, compiler à partir des sources est relativement aisé, et assure que vous avez une version à jour. En supposant que vous avez un ensemble d'outils de développement en fonctionnement (gcc, make, etc.) à allez sur la page 'Download' \footnote{\url{http://gmt.soest.hawaii.edu/gmt/gmt_download.html}}, et suivez les instructions. GMT est distribué avec un manuel compréhensible, des cours pour créer des cartes, et des données pour des cartes à différentes échelles. Une fois que vous avez une copie fonctionnelle de GMT installée sur votre machine, et que vous avez téléchargé les données d'exemple \footnote{\url{http://169.237.35.250/~dylan/GRASS/newsletter/sample_data.tar.gz}} vous pouvez suivre les exemples de cet article. Cette archive contient également un ensemble de scripts approfondis dans plusieurs exemples dans cet article. Le script \texttt{template.sh} peut être utilisé pour démarrer pour une approche automatisée pour exporter et tracer des données Raster et vecteur de GRASS avec des outils de GMT. Remarquez que ce script est un point de démarrage et est loin d'être complet.

Les commandes GMT sont lancées depuis la console (avec un jeu complexe de paramètres, switches et d'autres arguments) et envoient les fragments Postscript qui en résultent vers la sortie standard. Le comportement par défaut de toutes les applications GMT peut être ajusté avec la commande \texttt{gmtset}. Cette commande est habituellement utilisée avant toute commande qui produit un rendu, ainsi des éléments clé tels que la taille du papier, l'espace des polices etc. sont établis. La première commande de traçage lancée (généralement \texttt{psbasemap}) crée le fichier de sortie initial avec l'opérateur standard ``>'', tandis que chaque appel suivant ajoute à ce fichier avec l'opérateur d'ajout double -``>''. Le premier paramètre \texttt{-K} est utilisé avec toutes les commandes GMT avant la dernière commande, ainsi le fichier Postsript en sortie n'est pas finalisé prématurément. Nous utiliserons des données échantillons d'une application Mapserver pour illustrer divers aspects d'utilisation de GMT, avec une idée de comment coupler cela avec GRASS et GMT.

\subsection{Application échantillon}
\label{sec:sample_application}

\label{code:simple_example}
\begin{footnotesize}
\begin{verbatim}
# define some global settings:
gmtset ANNOT_FONT_PRIMARY Times-Roman \
HEADER_FONT_SIZE 16 \
ANNOT_FONT_SIZE_PRIMARY 12 \
LABEL_FONT_SIZE 14 \
BASEMAP_TYPE plain \
PLOT_DEGREE_FORMAT DF \
PAPER_MEDIA letter+

# sample map centered on the western USA
pscoast -JB-116/36/30/42/7i \
-R-125/-108/31/44 -B5 \
-Gwhite -W0.5p \
-A250 -Dh -Na -Xc -Yc -P -K > query_centers.eps

# plot mapxy points:
psxy sample_data/mapxy_locations.latlong -J -R \
-Sc0.075c -W1/1/200/1 -G1/200/1 -O -K >> query_centers.eps

# plot ka-map points 
psxy sample_data/ka-map_locations.latlong -J -R \
-Sc0.075c -W1/255/1/1 -G255/1/1 -O >> query_centers.eps
\end{verbatim}
\end{footnotesize}

%% talk about the parameters
\noindent
L'exemple ci-dessus crée un graphique de l'Est des États-Unis, avec des points rouges et verts symbolisant l'activité spécifique à l'endroit d'un site Internet. Le cadre de la carte est créé avec la commande \texttt{psbasemap}, les lignes de côtes et limites politiques sont créées par \texttt{pscoast}, et les points sont créés avec la commande \texttt{psxy}. La localisation des points est stockée comme des paires simples de longitude-latitude au format texte, tandis que la ligne de côte est dessinée à partir du jeu de données inclus dans GMT. Le résultat peut être vu à la Figure \ref{fig:example1}.


\noindent
Une explication complète des diverses options des lignes de commandes peut être trouvée dans la page de manuel de chaque commande. De plus, un exemple plus complet de GMT réalisé en dehors de GRASS peut être trouvé sur le site de l'auteur \footnote{\url{http://casoilresource.lawr.ucdavis.edu/drupal/node/102}}. Dans l'exemple ci-dessus, les paramètres de projection et de région sont définis manuellement par l'utilisateur. Des éléments de formattage additionnels (tel que le paramètre \texttt{-P} pour un affichage en portrait) doivent être définis manuellement et définis en ligne de commande. La génération automatique d'une carte dépend alors, en partie, d'une approche dynamique pour définir les options passées aux commandes GMT. Un langage de script, capable d'extraire les informations de région de GRASS à partir d'une session de GRASS en cours est une approche idéal pour automatiser cette tâche.

\setkeys{Gin}{width=1\textwidth}
\begin{figure}[tbp]
   \centering
   %name of your graphic, without the path AND in EPS format:
   \includegraphics[scale=0.4]{integration/beaudette/query_centers}
   %caption of the figure
   \caption{Localisations de requête, symbolisé par une application cartographie active. Les points verts représentent une application Mapserver basée sur LandView, les points rouges représentent une application Mapserver basée sur Ka-map.}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:example1}
\end{figure}


\section{Coupler GRASS et GMT}
\label{sec:GRASS_GMT}
L'approche générale pour interfacer GRASS et GMT peut être résumée comme suit :

\begin{small}
\begin{itemize}
\item collecter des informations à partir d'utilisateurs sur :
	\begin{itemize}
	\item les données en entrées
	\item les options de formatage
	\item les options du rendu
	\end{itemize}

\item collecter des paramètres géographiques à partir de la région GRASS
\item calculer les paramèters clés de mise en page
	\begin{itemize}
	\item information sur la projection
	\item limites d'échelle
	\item intervales des échellons
	\end{itemize}

\item exporter les données raster de GRASS vers le format .gd de GMT
\item exporter les données vecteurs de GRASS vers le format ASCII de GMT
\item lancer les commandes GMT avec les paramètres ci-dessus
\end{itemize}
\end{small}


\subsection{Collecter des informations à partir de l'utilisateur}
Le parseur de script GRASS fournit une approche aisée à la création de commandes GRASS pesonnalisées, sans la nécessité de comprendre le langage C. Un script habile et rigoureux peut être utilisé pour parser des détails sur le jeu de données de GRASS comme des informations sur les paramètres de la région en cours aux commandes GMT, en utilisant la syntaxe familière et la structure de l'interface d'un module GRASS. Avec ces options sauvées dans des variables locales il est possible de modifier les paramètres par défaut tels que la taille du papier, la taille des polices et l'orientation du texte en lançant le programme \texttt{gmtset} avec nos variables locales substituées par l'interpréteur de script \footnote{On peut trouver plus d'informations sur l'interpréteur de script GRASS ici \url{http://grass.itc.it/gdp/html_grass63/g.parser.html}}.


\subsection{Collecter des informations géographiques}
Extraire des informations clé des paramètres de la région en cours (pour une utilisation des paramètres plus tard dans GMT) peut être réalisé de plusieurs manières. Parmi celles-ci une implique les outils \texttt{g.region} et de traitement de texte, grâce à Bruce Raup pour la suggestion élégante de \texttt{eval}. Remarquez que tous les exemples suivants nécessitent que vous soyez dans une session GRASS active.

% 
% might not want to include all of this.
% 
\begin{footnotesize}
\begin{verbatim}
# need to be in an active GRASS session for this to work.
#
# region extents: used with -R flag
# resolution: used with the -I flag
#
# elegant approach to extracting extent and 
# region resolution as suggested by
# Bruce Raup - National Snow and Ice Data Center
#
region_assignments=`g.region -g`
eval $region_assignments

# setup flags for GMT commands
region="-R$w/$e/$s/$n"
inc="-I$ewres/$nsres"

# extract extent values for calculating map aspect ratio
extent_assignments=`g.region -ge`
eval $extent_assignments

# preserve aspect ratio from UTM E,N coordinates:
aspect_ratio=`echo $ns_extent $ew_extent 
| awk '{printf("%f", $1 / $2)}'`

# calculate the map length based on the 
# original aspect ratio
map_length=`echo $map_width $aspect_ratio 
| awk '{printf("%f", $1 * $2)}'`

# calculate the y location (in paper units)
# for the field sheet title
field_sheet_title_y=`echo $map_length 
| awk '{printf("%f", $1 + 0.33)}'`

#compile the projection string, with 
# width/length variables
#linear projection, width inches / length inches
projection_string="X${map_width}i/${map_length}i"
\end{verbatim}
\end{footnotesize}

\noindent
Une approche plus robuste impliquerait la liaison GRASS-Python pour extraire directement les paramètres de la région. Une fois que les données de la région ont été extraites et sauvées dans des variables locales, nous pouvons réaliser les calculs nécessaires pour obtenir les autres paramètres tels que l'échelle de la carte, le rapport de l'aspect de la carte, la taille de la carte sur le papier, etc. Les paramètres de la région sont utilisés pour le paramètre \textit{de traçage de la région} (\texttt{-R\$w/\$e/\$s/\$n}), souvent utilisé seulement dans la première fonction de traçage. Toutes les fonctions de traçages suivantes peuvent hériter de ces valeurs en définissant des paramètres vides \texttt{-J} et \texttt{-R} en fonction du paramètre \texttt{-O} (superposition).

% 
% talk a bit about how GMT operates with unprojected vs. projected data.
% 
\subsubsection{Les projections des cartes dans GMT}
L'approche traditionnelle pour utiliser les outils GMT implique le traçage de données, encodé en paire longitude-latitude, dans une projection définie avec le paramètre \texttt{-J}. Les coordonnées sont transformées au fur et à mesure que la sortie Postscript est générée. Comme noté dans l'exemple de code ci-dessus, une projection Alber Equal Area centrée sur (116$^\circ$W, 36$^\circ$N), en ayant des parallèles standards à 30$^\circ$N et 42$^\circ$N, et qui a 7 pouces de large est encodé par \texttt{-JB-116/36/30/42/7i}. Lisez le manuel de GMT pour une liste complète de projections gérées et de leurs paramètres.

Lorsqu'on travaille dans GRASS, les données sont habituellement (mais pas toujours) dans une projection géographique et donc le mode de projection \textit{linear} doit être utilisé. Une fois qu'une largeur et une longueur appropriées de la carte (dans ce cas en utilisant des pouces) ont été établies les paramètres de la projection linéaire sont encodées par \texttt{-JX\$\{map\_width\}i/\$\{map\_length\}i}. Remarquez que les unités métriques ou impériales peuvent être utilisées dans GMT et passer de l'un à l'autre implique seulement l'ajout d'un 'c' pour centimètre et 'i' pour pouces ([NdT] inches en anglais) après le nombre.


\subsection{Exporter et tracer des données raster GRASS}
Exporter une donnée raster GRASS vers un format compatible GMT peut être réalisé avec une combinaison de \texttt{r.out.bin} et \texttt{xyz2grd} (inclu dans la distribution GMT). 
L'utilisation correcte de \texttt{xyz2grd} nécessite des connaissances dans les données raster en entrée : c'est à dire entier ou virgule flottante, etc. Pour une cellule raster exportée avec \texttt{r.out.bin}, le paramètre \texttt{-ZTLh} pourrait être utilisé pour renseigner \texttt{xyz2grd} que le flux de données en entrées est une donnée entière courte orientée. %For a CELL raster exported with \texttt{r.out.bin}, the flag \texttt{-ZTLh} would be used to instruct \texttt{xyz2grd} that the input data stream is scanline oriented short integer data.
Pour les cartes FCELL et DCELL les paramètres correspondants pourraient être respectivement \texttt{-ZTLf} ou \texttt{-ZTLd}. Le paramètre \texttt{-F} instruit \texttt{xyz2grd} pour utiliser l'enregistement des pixels des grilles des cellules, le même enregistrement utilisé pour les rasters GRASS. Une simple déclaration CASE peut être utilisée dans nos exemples de scripts pour créer automatiquement l'appel à \texttt{xyz2grd}. Un paramètre optionnel dans notre exemple de script peut être utilisé pour sauter cette étape pour faciliter la récupération des autres paramètres sans perdre de temps de traitement pour exporter les données raster. L'auteur a trouvé que définir la région par une résolution entière entraîne l'opération la plus fiable de \texttt{xyz2grd}.

\begin{footnotesize}
\begin{verbatim}
# obtenir le type de la carte d'un raster donnée
MAP_TYPE=`r.info -t "$output_raster" | cut -f2 -d'='`

# exporter le raster basé sur son type,
# ses paramètres de régionde l'exemple ci-dessus
# et les paramètres de résolution de l'exemple plus haut :
case "$MAP_TYPE" in
	CELL)
		r.out.bin input=$output_raster output=- null=-9999 \
		| xyz2grd -G$output_raster.grd \
		$region $inc -ZTLh -F -N-9999 ;;
	FCELL)
		r.out.bin input=$output_raster output=- null=-9999 \
		| xyz2grd -G$output_raster.grd \
		$region $inc -ZTLf -F -N-9999 ;; 
	DCELL)
		r.out.bin input=$output_raster output=- null=-9999 \
		| xyz2grd -G$output_raster.grd \
		$region $inc -ZTLd -F -N-9999 ;; 
esac
\end{verbatim}
\end{footnotesize}

\noindent
Une fois que les données rasters ont été exportées au format .grd nous somme presque prêts pour leur utilisation avec les commandes de dessins de GMT telles que \texttt{psimage}. Cette commande peut soit utiliser un seul fichier grille, avec un fichier de palette de couleurs (.cpt), soit avec des canaux de couleurs séparées rouge, vert, bleu \footnote{Les définitions des fichiers de palette de couleur de GTM peuvent être trouvées sur \url{http://www.soest.hawaii.edu/GMT/gmt/doc/html/GMT_Docs/node57.html}}.


% 
% not sure about the use of footnotes in the newsletter
% 
\subsubsection{Exporter les données des tables de couleur GRASS}
Pour l'instant il n'y a pas de méthode \textit{simple} disponible pour convertir les informations de la table des couleurs de GRASS en un fichier de palette de couleurs fiable pour GMT. Les développements existants sont capables d'approcher le format .cpt, cependant l'auteur n'a pas été capable d'utiliser avec succès ces fichiers générés automatiquement. Un script de conversion fonctionnel (de préférence écrit en un langage de script de haut niveau tel que Python) sera posté prochainement sur le wiki de GRASS dès qu'il sera complet \footnote{De plus amples tests et adaptations du script r.out.gmt.py de David Finlayson pourraient être l'approche la plus rapide).}.

GMT fournit plusieurs outils pour créer manuellement un fichier de palette de couleur dans un domaine de données fourni par l'utilisateur, ou un domaine de données lu à partir d'un fichier grid de GMT. Bien que cela ne soit pas une approche idéale , il peut être utile quand une des palettes de couleur de GMT est appropriée. Dans le cas spécial où l'image exportée est en nuance de gris, la palette de couleur standard ``gray.cpt'' peut être utilisée pour créer un nouveau fichier cpt avec le programme \texttt{makecpt}.

\begin{footnotesize}
\begin{verbatim}
# créer une palette de couleur fiable pour une image
# raster CELL en nuance de gris, les valeurs de grille
# sont des entiers dans un domaine compris de 0-255
makecpt -Cgray -T0/255/1 -V > doqq.cpt

\end{verbatim}
\end{footnotesize}

\noindent
Lorsque l'on travaille avec des canaux de couleurs qui ont déjà été séparés (par exemple, landsat ou d'autres images multispectrales) il est possible d'utiliser \texttt{psimage} sans un fichier de palette de couleurs, au lieu de définir des fichiers de grilles en entrée en rouge, vert et bleu. Cette approche est plus aisée lorsque l'on travaille avec des données qui ont été collectées dans des bandes séparées. Pour des données à une seule bande, la séparation des couleurs peut être créée avec \texttt{r.mapcalc}.

\begin{footnotesize}
\begin{verbatim}
# obtenir les séparations de couleurs prêt pour GMT
 
r.mapcalc "some_raster.red = r#some_raster"
r.mapcalc "some_raster.blue = b#some_raster"
r.mapcalc "some_raster.green = g#some_raster"
\end{verbatim}
\end{footnotesize}

 
\subsection{Exporter et tracer des données vecteurs GRASS}
Le format vecteur de GMT est basé sur un format ASCII basé sur des vertex, très simple, désigné au début pour stocker des données géométriques. Cependant, avec des scripts il est possible d'encoder des données attributs simples dans ce format pour la production de cartes thématiques. Une approche alternative implique que les données vecteurs qui ont été pré-filtrées avec un outil GRASS tel que \texttt{v.extract}, en plusieurs fichiers où chacun représente une classe spécifique. En utilisant la première approche (encoder les attributs dans une fichier vecteur GMT) la symbologie pour chaque point, ligne et polygone est encodée dans le fichier, tandis que la symbologie est définie avec des paramètres en ligne de commande pour la seconde aproche.

\subsubsection{Données points}
Exporter des données ponctuelles est la conversion la plus simple de GRASS $\rightarrow$ Vecteur GMT. Dans la plupart des cas, où un ensemble de points doit être tracé dans GMT en utilisant une symbologie fixe, la sortie de \texttt{v.out.ascii} ou \texttt{v.out.ascii.db}  peut être directement tracée avec la commande GMT texttt{psxy}. Notez que filtrer la sortie avec l'une ou l'autre commande avec des outils de traitement de texte UNIX est une méthode idéale pour convertir des attributs dans une symbologie ou pour ajuster les étiquettes.


\begin{footnotesize}
\begin{verbatim}
# exporter d'un format ASCII de GRASS
v.out.ascii in=points fs=" " > points.xy

# trace les points avec un contour blanc et remplit de
# bleu en utilisant un symbol circulaire de 0.125 
# pouces de diamètre en ajoutant le resultat Postscript
# à 'outfile.eps'
psxy points.xy -R -J -M -Sc0.125 -G255/1/1 \
-W1/255/255/255 -O -K >> output.eps 
\end{verbatim}
\end{footnotesize}

\noindent
L'étiquetage des données points peut être réalisé d'abord en filtrant la sortie de \texttt{v.out.ascii} avec un simple script \texttt{awk}, puis en utilisant la sortie avec la commande \texttt{pstext}. Le format des étiquettes utilisé par GMT est documenté dans la page du manuel de \texttt{pstext}, cependant une simple explication est donnée dans l'échantillon de code ci-dessous.

\begin{footnotesize}
\begin{verbatim}
# export du format de GRASS vers ASCII avec des 
# attributs sélectionnés (colonne 'ID'), sortie
# filtré avec awk, classement des colonnes,
# et insertion des étiquettes dans le formulaire :
# x_coord, y_coord, font_size, rotation_angle, 
# font_number, label_offset, label_text
v.out.ascii.db in=points columns=ID | awk -F"|" 
'{print $2, $3, 10, 0, 4, "BL", $4}' \ 
> points_with_labels.xy

# trace les textes des étiquettes à partir des 
# géométries et des propriétés des étiquettes stockées
# dans 'points_with_labels.xy' les étiquettes seront
# bleu et distante de 0.1 cm dans les directions
# horizontale et verticales définie dans la colonne
# 5 du fichier en entrée
pstext points_with_labels.xy -R -J -Dj0.1c/0.1c 
-G0/0/255 -K -O >> outfile.eps
\end{verbatim}
\end{footnotesize}


\subsubsection{Données ligne et polygone}
Il n'y a pas pour l'instant de méthode directe pour convertir des données lignes et polygone GRASS en un format compatible avec GMT. Cependant, en utilisant une application externe appellée \texttt{shp2gmt} \footnote{ce petit programme utile initialement écrit par (Frank Warmerdam), a été modifié par (Mark Fenbers) pour inclure des informations attributaires à partir d'une shapefile. Le code du \texttt{shp2gmt} modifié peut être trouvé à \url{http://www.arcknowledge.com/gmane.comp.gis.gmt.user/2004-01/msg00121.html}}, il est possible de créer des fichiers vecteurs compatibles avec GMT en exportant d'abord les données GRASS en shapefile puis en les convertissant avec \texttt{shp2gmt}. Le texte issu de \texttt{shp2gmt} contient tous les attributs stockés dans le shapefile en entrée en fonction des coordonnées du vertex, et peut être facilement filtré avec \texttt{awk} pour inclure les paramètres de la symbologie. Un exemple de session GRASS illustrant ce type d'opération est listé ci*dessous.

\begin{footnotesize}
\begin{verbatim}
# export de GRASS vers le format shapefile
v.out.ogr -e in=lines dsn=. olayer=lines
v.out.ogr -e in=polys dsn=. olayer=polys

# convertit du format shapefile vers GMT
shp2gmt lines.shp > lines.xy
shp2gmt polys.shp > polys.xy

# en option filtre le fichier vecteur GMT
# pour inclure la symbologie
awk '
{
# tous les segments lignes avec l'attribut
# 'some_value' sera dessiné avec un pinceau
# rouge
if ($0 ~ /some_value/) printf "> -Wred\n"
# ... ajoute plus d'amélioration pour les autres classes
# pour les lignes qui ne correspondent pas, pour les 
# tracer mot pour mot (c.a.d. les données vertex)
else print
}
' lines.xy > lines-thematic.xy

# traces les lignes, avec la symbologie définie dans 
# le fichier vecteur GMT
psxy lines-thematic.xy -R -J -O -K >> outfile.eps

\end{verbatim}
\end{footnotesize}


\noindent
L'étiquettage des objets lignes et polygones suit la même approche générale que l'étiquettage des objets ponctuels, par l'utilisation de \texttt{pstext}. Pour de simples cartes, une approche presque automatique pour étiquetter les données polygonales implique l'export des centroïdes avec \texttt{v.out.ascii.db}, comme listé au-dessus. Étiquetter les données lignes nécessite plus d'actions de la part de l'utilisateur, puisque chaque étiquette nécessite des coordonnées et un angle associés. Avec un peu de travail il est possible d'utiliser le fichier crée par \texttt{v.label} pour produire un ensemble compatible avec GMT d'instruction de placement d'étiquettes. Un exemple de script \texttt{awk}, utilisé dans une session GRASS, est présenté ci-dessus.

\begin{footnotesize}
\begin{verbatim}
# creer le fichier d'étiquette GRASS : 
# tourner les étiquettes pour correspondre aux segments
# de ligne
v.label -a map=trails column=trail_name labels=trails.lab

# converti le foramt d'étiquette GRASS vers le format GMT
awk '
BEGIN{FS="\n" ; RS="\n\n"}
{ 
split($1, e, ": ") 
split($2, n, ": ")
split($15, r, ": ")
split($16, l, ": ")
# s'il n'y a pas de rotation, nous devons ajouter une
# roration de 0
if(NF == 16) {rotation = r[2] ; label = l[2]} 
else {rotation = 0 ; label = r[2]}
# creation les instructions d'étiquettage GMT
print e[2], n[2], 10, rotation, 4, label
}
' DATABASE/LOCATION/MAPSET/paint/labels/trails.lab 
> labels.xy

# dessin avec pstext
pstext labels.xy -R -J -Dj0.1c/0.1c -G0/0/255 -K -O 
>> outfile.eps

\end{verbatim}
\end{footnotesize}

\noindent
Bien que l'approche au-dessus peut fonctionner pour de simples cartes, une intervention de l'utilisateur est habituellement requise pour des cartes plus complexes. Une approche plus robuste pour l'étiquettage des objets ponctuels, lignes et polygones avec des possiblités avancées telles que la détection des collisions des étiquettes est nécessaire pour une approche entièrement automatisée.


% 
% finishing up, running commands,optionally converting the output to PDF with some tweaks.
% 
\subsection{Divers éléments de cartographie}
Des éléments supplémentaires tels que le contexte de la carte (\texttt{psbasemap} avec \texttt{psxy}), l'échelle graphique (\texttt{psbasemap}), ou la légende (\texttt{pslegend}) peuvent être ajoutés après que les composants de la carte principale aient été ajoutés au fichier en sortie. Vérifier que la dernière commande GMT n'utilise pas le paramètre \texttt{-K} est toujours une bonne idée, afin de s'assurer que le fichier en sortie est finalisé. Par l'utilisation rigoureuse des paramètres \texttt{-O}, \texttt{-X}, et \texttt{-Y} il est possible de redéfinir la région du tracé pour chaque appel d'un programme GMT. Cette approche fonctionne bien pour créer une carte de situation de petite taille, dans une autre carte finalisée. En étendant le premier exemple, vous trouverez ci-dessous un script plus complet pour illustrer l'utilisation de \texttt{psbasemap} pour produire des éléments de la carte tels qu'une échelle graphique, une flèche indiquant le nord, en fonction de la création d'une carte de situation dans la carte principale.


\label{code:complex_example}
\begin{footnotesize}
\begin{verbatim}
# definition de paramètres globaux :
gmtset ANNOT_FONT_PRIMARY Times-Roman \
HEADER_FONT_SIZE 16 \
ANNOT_FONT_SIZE_PRIMARY 12 \
LABEL_FONT_SIZE 14 \
BASEMAP_TYPE plain \
PLOT_DEGREE_FORMAT DF \
PAPER_MEDIA letter+

# carte échantillon centrée sur l'est des USA
pscoast -JB-116/36/30/42/7i \
-R-125/-108/31/44 -B5 \
-Gwhite -W0.5p \
-A250 -Dh -Na -Xc -Yc -P -K 
> query_centers_2.eps

# trace les points mapxy :
psxy sample_data/mapxy_locations.latlong -J -R \
-Sc0.075c -W1/1/200/1 -G1/200/1 -O -K 
>> query_centers_2.eps

# tracve les points ka-map
psxy sample_data/ka-map_locations.latlong -J -R \
-Sc0.075c -W1/255/1/1 -G255/1/1 -O  -K 
>> query_centers_2.eps

# ajout de la barre d'échelle
psbasemap -J -R -Lf-119/32.5/32/150k:"Kilometers": \
-O -K -P -V >> query_centers_2.eps

#créer un contexte à la carte
pscoast -JB-116/36/30/42/7i \
-R-130/-100/25/50 \
-X0.25i -Y1.75i \
-Gwhite -W0.5p \
-A250 -Di -Na -P -K >> query_centers_2.eps

# ajoute la boîte de la région
psxy context_box.xy -M -JB -R  -W3/1/1/0 -P -O 
>> query_centers_2.eps
\end{verbatim}
\end{footnotesize}

\setkeys{Gin}{width=1\textwidth}
\begin{figure}[tbp]
   \centering
   %name of your graphic, without the path AND in EPS format:
   \includegraphics[scale=0.4]{integration/beaudette/query_centers_2b}
   %caption of the figure
   \caption{Ajout d'un contexte à la carte et d'une échelle graphique.}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:example2}
\end{figure}

\subsubsection{Limitations actuelles}
L'approche actuelle par la console unix pour interfacer GRASS et GMT a plusieurs désavantages : manque de portabilité vers les systèmes non-unix, manque d'opérateurs mathématiques sophistiqués, et une dépendance avec des outils plus utiles tels que \texttt{awk}, \texttt{sed}, \texttt{grep}, etc. Ces désavantages sont particulièrement ennuyeux lors qu'on essaye d'automatiser la construction des éléments d'une carte tel que les intervalles ou les décorations basés sur l'échelle. Les exemples dans cet article utilisent des intervalles définis manuellement, cependant lors de la création de cartes à partir de GRASS (qui est habituellement dans un système de coordonnées projeté) cela prendre du temps de rajouter les intervalles annotés ou non pour chaque carte. Regardez le script \texttt{template.sh} inclus dans l'archive des données d'échantilon pour avoir une idée. Encore une fois, une intégration étroite avec GRASS via la liaison Python résoudrait le problème ci-dessus. En attendant qu'un développement entièrement en Python soit terminé, l'estimation des intervalles automatiques peut être simplifiée avec le script perl suivant.

\begin{footnotesize}
\begin{verbatim}
#!/usr/bin/perl -w

# Le 1er argument est l'étendue maximale en unité de la carte
# divisé par un nombre raisonable d'annotations par bord
$x = $ARGV[0] / 10;

print round_up($x) , "\n";

# arrondit à une échelle raisonable
# trouvé à :
# http://www.perlmonks.org/?node_id=599865

sub round_up {
  my $n = shift;
  my $scale = 10**int(log($n)/log(10));
  $n = 9 if $scale == 1; #magic for single digits
  if ($n > $scale) {
    $n = int($n/$scale+1)*$scale;
  }
  $n;
}
\end{verbatim}
\end{footnotesize}

% 
% recap, other examples, proposed system using GRASS Python bindings.
% 
\section{Conclusion}
Cet article résume les conditions actuelles de conversion des données GRASS au format GMT pour la production de carte Postscript de grandes qualités. Bien que plusieurs modèles et exemples existent pour automatiser ce processus, pour la production de cartes complexes de considérables modifications sont nécessaires par l'utilisateur. Après des progrès suffisants sur des projets comme l'interface de GRASS et la liaison Python, il pourrait être possible de créer un système plus complet pour améliorer le processus de GRASS $\rightarrow$ GMT  Il y a actuellement un effort mené par Brent Wood pour réviser le format vecteur de GMT qui pourrait simplifier le processus de cartographie thématique avec GMT. De plus Brent est en train de travailler sur l'inclusion de la gestion en écriture pour le format vecteur GMT dans OGR (GDAL). Une fois terminé, l'export vectoriel de GRASS vers GMT pourrait être aussi simple que \texttt{v.out.ogr format=GMT}. Le travail proposé par Wolf Bergenheim, sur un algorithme général de détection et de correction de collision des étiquettes pour \texttt{v.label}, pourrait être une excellente solution pour les tâches d'étiquettage à la fois dans GRASS et GMT. Nous verrons la prochaine fois un exemple plus en profondeur de création d'une carte complexe en utilisant des données de GRASS à partir de l'échantillon de données Spearfish.

%\subsection{Resources}
%A collection of links to various tutorials, manual pages, and examples of interfacing GRASS and GMT.

%% how do we associate a link to a word?
%\begin{itemize}
%\item SSC 105 example map (\url{http://casoilresource.lawr.ucdavis.edu/drupal/node/102})
%\item Example map illustrating the use of GRASS point, line, CELL raster, and FCELL raster data. (\begin{small}(\url{http://169.237.35.250/~dylan/grass_user_group/map1.html})\end{small}) 
%\item Example used in Where 2.0 Conference (link to script)
%\item The Generic Mapping Tools Home Page (\begin{small}(\url{http://gmt.soest.hawaii.edu/})\end{small})
%\item GRASS Add-ons page
%\end{itemize}



% 
% might be good to acknowlage some people here: Hamish, David F. Brent Wood.
% 


% % Figures, usually in EPS (Encapsulated Postscript)
% to insert an image: ...
% the figure~\ref{fig:label_of_your_image} shows the structure 
% of the project ...
% 
% 
% %\setkeys{Gin}{width=1\textwidth}
% \begin{figure}[htbp]
%    \centering
%    %name of your graphic, without the path AND in EPS format:
%    \includegraphics[scale=0.8]{grasslogo_vector.eps}
%    %caption of the figure
%    \caption{this is the grass logo}
%    %label of the figure, which has to correspond to \ref{}:
%    \label{fig:label_of_your_image}
% \end{figure}
% 



% 
% \begin{footnotesize}
% \begin{thebibliography}{99}
% 
% \bibitem[Herborg et~al. (2003) Herborg, Bentley, Clare, Rushton]{herborg:2003} 
% L.M. Herborg, M.G. Bentley, A.S. Clare, S.P. Rushton (2003)
% \newblock The spread of the Chinese mitten crab (Eriocheir sinensis) in
% Europe; the predictive value of an historical data set.
% \newblock {\em Hydrobiologia} 503: 21-28.
% 
% 
% \end{thebibliography}
% \end{footnotesize}
% 

\address{Dylan Beaudette\\
  Universitée de Californie à Davis\\
  \url{http://casoilresource.lawr.ucdavis.edu}\\
  \email{debeaudette AT ucdavis.edu}}

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: main_document.tex
%%% End: 

