Dévelopement de l’outil « Qmax_BV »

L’outil « Qmax_BV » est dédié à fournir l’information nécessaire pour procéder aux calculs hydrologiques provenant de l’ancien outil « Qmax_PBV » (Michaud et al., 2013). Ce dernier procède aux calculs des débits à récurrence variable selon plusieurs méthodes.

2.4.2.1. Identification des données nécessaires

Puisque l’outil « Qmax_PBV » est celui devant être alimenté de données, il est possible de déterminer les données nécessaires pour procéder au calcul des débits selon l’équation qu’il utilise.

33 𝑄 = 𝐶𝑟 ∗ 𝐴 ∗ 𝑖 =𝑅𝑢 ∗ 𝐴 𝑡𝑐 [Équ. 9] 𝑂ù 𝑄 = 𝐷é𝑏𝑖𝑡 (𝑚 3 𝑠 ) 𝐴 = 𝐴𝑖𝑟𝑒 𝑑𝑒 𝑙𝑎 𝑠𝑢𝑟𝑓𝑎𝑐𝑒 𝑑𝑟𝑎𝑖𝑛é𝑒 (ℎ𝑎) 𝐶𝑟 = 𝐶𝑜𝑒𝑓𝑓𝑖𝑐𝑖𝑒𝑛𝑡 𝑑𝑒 𝑟𝑢𝑖𝑠𝑠𝑒𝑙𝑙𝑒𝑚𝑒𝑛𝑡 (−)

i = Intensité de précipitation pour une durée égale au temps de concentration du territoire (mm

h ) 𝑅𝑢 = 𝑅𝑢𝑖𝑠𝑠𝑒𝑙𝑙𝑒𝑚𝑒𝑛𝑡 (𝑚𝑚)

𝑡𝐶 = 𝑇𝑒𝑚𝑝𝑠 𝑑𝑒 𝑐𝑜𝑛𝑐𝑒𝑛𝑡𝑟𝑎𝑡𝑖𝑜𝑛 (ℎ) 2.4.2.2. Identification des résultats à produire

Afin d’obtenir les données nécessaires pour que « Qmax_PBV » puisse procéder à ses calculs, les données nécessaires doivent être produites. Certaines de ces variables disposent d’une ou plusieurs méthodes pour les obtenir. C’est en analysant les méthodes pour obtenir les données nécessaires qu’il est possible d’identifier les résultats à produire. Le tableau 4 présente quelques méthodes de calcul pour tc et Ru, ainsi que quelques variables qui les constituent. Pour les autres variables de l’équation 9, ils font automatiquement partie de la liste d’éléments à produire.

Les résultats à produire ainsi identifiés sont : la superficie drainée (A), la longueur maximale de parcours de l’eau (L), la pente (S) et l’occupation du sol (CN moyen et C moyen).

34

Tableau 4 : Méthodes de calcul de tc, Ru, CN et C.

Variable Méthode Équation Source

𝒕𝑪 Kirpich 0.000325 𝐿0.77 𝑆0.385 Kirpich, 1940 Mockus 𝐿0.8( 1000 𝐶𝑁−9) 1.67 20837 𝑆0.5 MAPAQ, 1988 SCS-LAG 𝐿0.8₍( 1000 𝐶𝑁 − 9) 0.7 4407𝑆0.5 ) SCS, 1990; Fangmeier et al., 2006 Bransby-Wiliams 0.000378 𝐿 𝑆0.2_𝐴0.1 MTQ, 2004 Aéroport 0.01188(1.1 − 𝐶) ∗ 𝐿0.5 𝑆0.33 MTQ, 2004 Ru Monfet * 0.33 ∗ 𝑆 − 2 Monfet, 1979 SCS** (S − 0.2 ∗ Rm) 2 S + 0.8 ∗ Rm SCS, 1990 CN Tables Fonction de S et tc Monfet, 1979; USDA-NRCS,2004; USDA-NRCS,2009 CN 25400 𝑆𝑠 + 254 NRCS, 1950 CN (I) 4.2 𝐶𝑁(𝐼𝐼) 10 − 0.058𝐶𝑁(𝐼𝐼) SCS, 1986; Chow et al., 1988 CN (III) 23CN(II) 10 + 0.13CN(II) SCS, 1986; Chow et al., 1988

CN(II) Table Cho et al., 1988

C

C 0.2 (1 - Imp) + 0.9 Imp MOE, 1987

Tables Fonction de l’occupation du sol

Wright et McLaughlin, 1991; MTQ, 1995;

ASCE/WEF, 1992; ARTC, 1982

*Calcul variable selon CN **Calcul variable selon la pente tc = temps de concentration (h) A = superficie du bassin versant (ha)

L = Longueur maximale du parcours de l’eau dans le bassin versant (m) S = pente moyenne de l’écoulement (m/m)

CN = Numéro de courbe moyen – Indice de ruissellement C = Coefficient de ruissellement

n = Coefficient de Manning du cours d’eau P = Précipitation

Ss = stockage dans le sol (mm)

Imp = Pourcentage de surface imperméable Rm = Rétention maximale (dépend de CN)

35 2.4.2.3. Développement de l’outil

Cette section présente les détails des résultats du développement de l’outil « Qmax_BV » en abordant le processus de traitement qu’utilise l’outil pour procéder aux calculs hydrologiques. La première présente la procédure de manière schématique, tandis que la deuxième partie va plus en profondeur en décrivant les éléments que le script contient.

2.4.2.4. Procédure schématique

Le module « Géotraitement » a permis de déterminer les éléments qui sont réutilisés dans le module « Hydrologie » pour l’outil « Qmax_BV ». Ces éléments permettent de définir la longueur du parcours d’écoulement de l’eau (L), la pente (S) et l’aire drainée (A).

Avec l’outil « ExtractStreams » le réseau hydrographique et les sous-bassins que chaque segment draine sont produits. À partir du réseau hydrographique, la longueur des segments peut être obtenue en interrogeant les lignes représentant chaque segment. En connaissant la correspondance entre chacun de ces segments, les longueurs de parcours peuvent être définies, dont le parcours le plus long du réseau (L). De la même manière, les sous-bassins versants peuvent être interrogés pour connaître l’aire des polygones, ce qui correspond à la superficie drainée. La figure 28 présente un exemple de réseau hydrographique et de sous-bassins versants. Pour la pente, les segments du réseau hydrographique peuvent être réutilisés. Puisque le réseau n’est présenté qu’en deux dimensions, les segments doivent avoir l’élévation de leurs extrémités. L’outil « CulvertsTreatment » crée un MNE dont les ponceaux sont éliminés. De cette carte, l’élévation peut être extraite. L’ajout de la donnée peut alors s’effectuer par correspondance spatiale. Le calcul de la pente du cours d’eau peut par la suite s’effectuer.

Vient finalement la définition de l’occupation du sol. Pour répondre aux définitions de la majorité des méthodes de définition de CN et C, de nombreuses sources sont considérées. Ces sources sont pour la majorité des cartes vectoriels qui peuvent être superposées pour joindre et délimiter les zones dont l’information est uniforme. Le reste des données sont sous forme de bases de données SQLite qui sont joint directement aux tables d’information des zones. Cette méthode donne de nombreuses valeurs pour chaque bassin versant, ce qui nécessite de procéder à une moyenne de CN et C pour obtenir celle des bassins versants. Les cartes considérées pour définir l’occupation du sol sont présentées dans le tableau 2.

2.4.2.5. Procédure détaillée

« Qmax_BV » procède en deux temps. Il commence en complétant l’information que dispose la carte des sous- bassins versants (figure 27) et la carte du réseau hydrographique (figure 28), pour terminer avec le lancement des calculs. L’information ajoutée aux deux cartes provient de plusieurs sources qui sont présentées au tableau

36

2 qui nomme et décrit brièvement les cartes. L’acquisition est effectuée par étape en procédant à l’ajout dans les tables d’attributs des deux cartes jusqu’à l’obtention de toutes les données nécessaires.

Plus précisément, la procédure de traitement de l’outil débute avec la carte des sous-bassins versants. La première étape est l’extraction des aires en hectare. Pour ce faire, un champ est ajouté à la table d’attribut avec « v.db.addcolumn », puis peuplée en procédant avec « v.to.db » qui extrait l’information directement de la carte pour compléter selon l’identifiant. Ces deux outils sont ceux du SIG GRASS. Il est possible de reconnaître leur source dans le script grâce à l’appellation « tools.GRASSmodule » qui permet de faire leur appel et de les utiliser. La figure 16 présente l’utilisation de la fonction d’ajout de champs et d’acquisition de données de la carte même.

#Ajout d’un champ dans la table d’attribut

tools.GRASSmodule('v.db.addcolumn', map=vect3, col="area_hec double") #Ajout de l’aire du polygone dans le champ correspondant

tools.GRASSmodule('v.to.db', map=vect3, option="area", columns="area_hec", units="hectares")

Figure 16 : Code pour l'ajout d'un champ dans une table d'attribut associée à une carte et pour le peuplement du champ

L’acquisition de données se poursuit en procédant à l’extraction spatiale de données des cartes « ZonesAgric18 » et « Pédologie ». Des champs du même nom que ceux des cartes sources sont ajoutés à la carte qui procède à l’acquisition comme précédemment. Les informations sont ensuite ajoutées selon la position spatiale de chaque polygone des bassins en questionnant les polygones des cartes superposés en utilisant « v.what.vect ». Les informations extraites sont NOS_CD_SOLS de la carte pédologique qui donne le type de sol constituant le bassin, ainsi que REGADM_S_N et REGADM_S_D de la carte ZonesAgrics18 qui serviront plus tard. La figure 17 présente un exemple de la fonction d’acquisition spatiale de GRASS.

# Ajout des données par acquisition spatiale

tools.GRASSmodule('v.what.vect', map=vect3, column='NOS_CD_SOL', query_map=pedologie, query_column='NOS_CD_SOL')

Figure 17 : Code pour l'extraction spatiale d'une carte vectorielle

La même fonction est utilisée avec la carte des sous-régions agricoles du Québec, la carte écoforestière et une carte produite par la superposition des cartes des cultures assurées de la Financière Agricole du Québec. Les champs ainsi ajoutés sont GROPRO (code identifiant ce qui est cultivé dans les champs), DESGROPRO (description du code GROPRO), TER_CO_FOR (code identifiant le type de territoire (urbain, forestier, agricole)), TCO_DESC (description des identifiants de TER_CO_FOR) et Factruissm (facteur de ruissellement des sous- régions agricoles).

À ce point, des tables provenant de la base de données SQLite doivent être intégrées à la table d’attribut. Cette intégration s’effectue avec un champ qui doit être produit par la concaténation des champs NOS_CD_SOLS et

37

REGADM_S_N doit être faite. Cependant, la procédure de concaténation classique (NOS_CD_SOLS|REGADM_S_N) s’est avérée peu fructueuse lors des tests, le tout causé par les formats différents des champs (texte et valeur numérique). Une méthode détournée a alors été utilisée est basé sur l’utilisation de fichiers CSV.

La procédure crée initialement trois fichiers. Le premier fichier est un fichier CSV qui sert à exporter les données de la table d’attribut (nommé « Qmax.csv »). Le deuxième est aussi un CSV, mais vierge (nommé « editQmax.csv ») et est utilisé pour procéder aux modifications. Le troisième fichier est un fichier CSVT (nommé « editQmax.csvt ») qui est utilisé automatiquement avec le CSV du même nom par la fonction de lecture de GRASS pour déterminer le format des colonnes de la table. Ce dernier est le premier fichier à être défini. Il est ouvert et le contenu écrit est une liste décrivant les formats des colonnes (valeur entière, valeur réelle ou texte). Vient ensuite la lecture de la table initiale d’attribut qui a été transférée dans le premier CSV. À partir de chaque ligne lue de ce CSV, une ligne est écrite dans le deuxième CSV. Cette ligne écrite contient les modifications apportées qui est la concaténation de deux colonnes. Le processus est effectué ligne par ligne jusqu’à ce que toute la table soit traitée. Le tout est par la suite clos et importé dans GRASS avec « db.in.ogr ». Cette intégration crée une table indépendante, ce qui nécessite de joindre la table avec celle des bassins versants en utilisant « v.db.join » basé sur l’identifiant (cat). Cette jointure permet une visualisation du tout, mais ne permet pas une modification permanente puisque la table d’attribut est une table SQL. Pour que la table puisse être conservée avec les ajouts, une requête SQL doit être utilisée, c’est pourquoi la table est mise à jour avec la fonction « v.db.update » qui effectue exactement cette tâche. Les CSV sont ensuite effacés de l’ordinateur avec « os.remove » et la table indépendante éliminés avec « db.droptable ». La figure 18 présente le code utilisé pour la concaténation.

38 # fichiers temporaires

tmpcat = "tmp_cat" # Fichier temporaire path_original = path_name + "Qmax.csv" path_edit = path_name + "editQmax.csv" path_edit_t = path_name + "editQmax.csvt"

# Exporte les données du fichier vectoriel dans un csv temporaire tools.GRASSmodule('v.out.ogr', format='CSV', input=vect3,

output=path_original)

# Le fichier csvt contient une description des types du fichier csv (utilisé automatiquement par db.in.ogr)

csvtfile = open(path_edit_t, 'w')

csvtfile.write("\"Integer\",\"Real\",\"Real\",\"Integer\"" ",\"Integer\",\"String\",\"String\",\"String\"") csvtfile.close()

# Crée une seconde version modifiée du csv out = open(path_edit, "wb")

outw = csv.writer(out, dialect=csv.excel) # Ouvre le csv pour le lire

csvfile = open(path_original, 'rb')

fichiercsv = csv.reader(csvfile, dialect=csv.excel) #Procédure de concaténation

i = 0

for ligne in fichiercsv: if i == 0:

ligne[8] = ligne[8] else:

REGADM_S_N = ligne[4] NOS_CD_SOL = ligne[5]

expression = str(str(REGADM_S_N) + NOS_CD_SOL) #Création du champ résultat de la concaténation ligne[8] = ligne[8].replace('', expression) #Écriture du résultat

outw.writerow(ligne) i += 1

out.close() csvfile.close()

# Ajoute l'info au fichier GRASS de points aux CS, à partir du fichier csv tools.GRASSmodule('db.in.ogr', nowarnings=True, input=path_edit,

output=tmpcat)

tools.GRASSmodule('v.db.join', map=vect3, column='cat', other_table=tmpcat, other_column='cat_')

tools.GRASSmodule('v.db.update', map=vect3, column='CDSolREG', query_column='concatenation')

# Suppression de fichiers et tables

tools.GRASSmodule('db.droptable', flags='f', table=tmpcat) tools.GRASSmodule('v.db.dropcolumn', map=vect3,

columns='concatenation' + ',' + 'cat_' + ',' + 'label') os.remove(path_original)

os.remove(path_edit) os.remove(path_edit_t)

39

Avec la concaténation et les champs précédents remplis, l’intégration de tables SQL contenant des données par défaut (Fact C, udg_default et SOLS_INTERMS) et des tables de conversion (conv_tercofor et conv_culture) est possible. Ces tables sont ajoutées avec la fonction « db.copy » et intégrées selon les champs précédemment ajoutés. La figure 19 présente un exemple pour une table de conversion des codes écoforestiers.

# Importe les tables sqlite

path_db = path_database + '\spatial.sqlite'

tools.GRASSmodule('db.copy', from_database=path_db,

to_table='conv_tercofor', select="SELECT * FROM conv_tercofor")

# Ajouter [util_terr] provenant de la table [conv_tercofer] a [vect2] # base sur l'attribut [TER_CO_FOR]

tools.GRASSmodule('v.db.join', map=vect3, column='TER_CO_FOR',

other_table='conv_tercofor', other_column='TER_CO_FOR') Figure 19 : Code d'intégration de la table SQL pour la conversion des termes et jointure à la table d'attribut

Finalement, pour la carte des bassins versants, un nouvel identifiant pour l’intégration éventuelle du facteur C est créé en procédant à la concaténation des champs « util_terr » et « TRAV_SOL » provenant des tables SQL. Vient maintenant l’acquisition de données pour la carte des cours d’eau. La procédure débute par l’ajout des champs qui seront éventuellement remplis. Dans ces champs, la première étape est l’intégration des coordonnées des extrémités des segments et de la longueur de chacun d’eux. La longueur est ajoutée en procédant à une interrogation de la carte elle-même avec « v.to.db ».

L’ajout des coordonnées des extrémités des segments nécessite quant à eux quelques étapes. Les extrémités des segments sont d’abord transformées en points avec « v.to.points ». L’élévation (Z) correspondant à leur position est ensuite ajoutée allant chercher l’information sur les pixels du MNE. Les pixels sélectionnés sont ceux situés sous chaque point et cela est effectué avec « v.what.rast ». En parallèle, les coordonnées des extrémités des segments sont ajoutées (Xamont, Yamont, Xaval et Yaval) en questionnant la carte des parcours de

l’eau en utilisant « v.to.db ». Avec les coordonnées des points et des lignes, une correspondance est effectuée pour ajouter à la carte des parcours de l’eau l’élévation acquise avec les points. La figure 20 présente les lignes de code de l’acquisition des coordonnées.

tools.GRASSmodule('v.to.points', input=vect2, type='line', output=tmp_points,

use='node')

tools.GRASSmodule('v.what.rast', map=tmp_points, raster=mne , type='point', layer=2,

column='Zam')

tools.GRASSmodule('v.to.db', map=vect2, type='line', option='start', columns='Xam' + ',' + 'Yam', units='meters')

40

L’acquisition des données se termine en regroupant les données des bassins versants correspondant à chaque segment par jointure spatiale avec la fonction « v.what.vect ». Les champs ainsi ajoutés sont « cat_SB » qui sont les identifiants des sous-bassins qui sert de référence, « area_ha » qui est l’aire de chaque bassin, « CD_Sol_REG » qui est la description des sols, « GROPRO » qui présente les cultures, « util_terr » qui est l’utilisation du territoire et « TER_CO_FOR » qui décrit le type de territoire (urbain, forestier, agricole).

Avec les données regroupées dans la carte du réseau hydrographique, les calculs peuvent être effectués avec le lancement de l’outil « Qmax_PBV » en prenant la carte du réseau hydrographique comme entrée.

Le résultat final produit par l’outil « Qmax_BV » est un fichier CSV nommé « Qmax_calc_results ». Ce fichier contient les résultats des calculs pour différentes récurrences en précisant les méthodes utilisées. La figure 21 présente un exemple de la table.

Figure 21 : Échantillon de résultat contenu dans le fichier CSV « Qmax_calc_results »

L’ensemble du code de l’outil « Qmax_BV » est présenté à l’annexe B. 2.4.2.6. Test des outils

Les tests de tous les outils ont été basés sur quatre tuiles de relevés LiDAR de 1 km2 _{(4 km}2_{) situé sur le territoire}

de la MRC Brome-Missisquoi puisque les données de tout son territoire étaient disponibles. Ce sont des tuiles sélectionnées dans un secteur aléatoire du territoire. Elles devaient répondre à trois critères : être adjacentes les unes des autres, être complètes et contenir un cours d’eau.

Tous les outils ont été testés en boucles en utilisant des données et des configurations variables afin de détecter les failles possibles. De plus, les résultats sont comparés avec des éléments répertoriés lorsque cela est possible (exemple : tracé des cours d’eau).

La majorité des erreurs rencontrées se sont retrouvé être des exceptions d’utilisation qui nécessitent des précisions sur l’utilisation de l’outil. Ce n’est que dans quelques cas isolés que des corrections dans le code ont été nécessaires.

Lorsque les tests sont avancés et que le fonctionnement reste stable, la documentation technique de l’outil est réalisée. Le contenu de la documentation est sommairement présenté à la section 3.4.3. En complément de la

41

documentation dédiée à chaque outil, des informations additionnelles sont ajoutées dans le manuel d’utilisateur du progiciel pour informer et équiper l’utilisateur pour utiliser et comprendre le progiciel.