Comment intégrer la glace de mer dans les routages météo ? Pour simuler des routes en amont de la circumnavigation, cela nous semblait essentiel. Avec Meltemus, nous avons donc créé un module spécifique pour le logiciel de routage maritime qtVlm !
Préparer une circumnavigation arctique à la voile, sans assistance motorisée, impose une exigence particulière : pouvoir naviguer à travers des zones soumises à la présence, parfois massive, de glace de mer, sans pour autant prendre de risques inutiles. Or il est impossible d’intégrer dynamiquement la densité des glaces dans les calculs de routage effectués par les logiciels de routage tels qu'Adrena ou qtVlm.
Le problème : une contrainte "glace" impossible à exploiter
Pour ma part, j'utilise QtVlm, un logiciel de navigation gratuit développé par Meltemus (Philippe Lelong), permettant le routage météo, la gestion de polaires, de gribs, de routes et de nombreux capteurs. En préparant mes routages afin de simuler des routes de la circumnavigation arctique, j’ai constaté que si qtVlm permettait d’afficher les données de densité de glace issues des fichiers GRIB (comme ceux publiés par l'AMSR2 ou le NOAA), il n’était pas possible de les intégrer directement comme contrainte dans le routage. Deux alternatives insuffisantes s’offraient à moi :
- Créer des barrières fixes (par shapefiles) qui ne tiennent pas compte de l’évolution temporelle des glaces ;
- Ou ignorer les glaces dans le calcul du routage, ce qui est évidemment inenvisageable.
Proposition de solution : une vitesse dépendante de la densité de glace
J’ai proposé à Philippe Lelong, développeur principal de qtVlm, une solution simple et exploitable : introduire une formule de ralentissement de la vitesse en fonction de la densité de glace, avec une densité maximale au-delà de laquelle la vitesse tombe à zéro.
Formule proposée :
- Vb : vitesse effective dans les glaces
- Vm : vitesse en eau libre (extrait de la polaire)
- Dg : densité de glace à l’instant T
- Dgmax : densité maximale franchissable définie par l'utilisateur
Cette formule a deux intérêts majeurs :
- Simplicité d’implémentation : un seul paramètre utilisateur à définir.
- Élégance algorithmique : le moteur de routage "évite" naturellement les zones où la vitesse tombe à zéro, sans contrainte artificielle.
Implémentation : une réponse rapide et efficace
Philippe a répondu positivement. En moins d’une semaine, une version bêta de qtVlm intégrant cette nouvelle logique a été publiée. Les apports concrets :
- Nouveau champ "Ice Density" visible dans le tableau de marche et les histogrammes de route.
- Coefficient de réduction de vitesse visible au survol du champ STW.
- Réduction progressive de la vitesse en fonction de la densité de glace.
Le système fonctionne : lors des tests, les routes évitent les zones de forte densité, sans intervention manuelle. La lisibilité est encore entravée par la projection Mercator dans les hautes latitudes, mais cela pourrait évoluer vers une projection Lambert dans le futur.
Retours d’expérience et contributions
Au fil de mes tests, j’ai signalé plusieurs bugs mineurs (disparition de routes à la fermeture, comportement erratique sur certains routages longs) et proposé des améliorations esthétiques (recalibrage du dégradé de couleur pour les glaces). Toutes ces contributions ont été intégrées avec une réactivité exemplaire.