Du changement pour RAQC

Randonnée à Québec (RAQC) change ses catégories. Désormais, la catégorie Lien piétonnier est scindée en 2 groupes : Les sentiers et les liens piétonniers proprement dits. La première catégorie regroupe les liens piétonniers appartenant à des sentiers nommés les plus souvent rattachés à un parc. La deuxième catégorie regroupe les autres liens piétonniers le plus souvent isolés et de petite dimension.

De plus, tous les segments de type Trottoir sont maintenant ignorés par l’application. Ceux-ci en plus d’être très lourds à gérer à cause de leur nombre et de la place qu’ils prenaient sur la carte n’apportaient pas de réelle valeur ajoutée pour les amateurs de randonnée pédestre.

Cette catégorisation a permis d’ajouter un nouvel outil : Sélection rapide d’un sentier nommé qui présente une liste des sentiers des parcs de la ville. La sélection d’une des options entraîne la sélection de tous les segments qui composent le sentier en question.

Cette catégorisation est fortement liée à l’interprétation du contenu des données téléchargées de Données-Québec et pourrait être modifiée à la suite d’une mise à jour des données par la ville de Québec.

CRAQ quitte les tables de fusion

En dépit de ce que j’avais annoncé, j’ai pu migrer l’application web CRAQ des tables de fusion à une BD MySQL. Le plus difficile a été de remplacer le layer des tables de fusion par un data layer conventionnel alimenté par la base de données.

En effet, l’API du Fusion Table layer était on ne peut plus efficace pour gérer l’affichage de milliers de points sur la carte Google map. Aucune optimisation n’était nécessaire. Tout était pris en charge par l’API. En utilisant un Data layer conventionnel, l’affichage de quelques milliers de points devenait tout à coup une tâche très lourde.

Pour optimiser l’affichage, la représentation des arbres à petite échelle utilise maintenant une carte thermique moins gourmande en ressources. Pour les niveaux supérieurs, l’application gère l’affichage en ne conservant dans le Data layer que la partie visible à l’écran. De plus, ce module n’affiche pas plus de 2 000 points simultanément à l’écran pour diminuer le décalage entre les mouvements de la carte et son affichage à l’écran.

Malgré tout, l’affichage des points même à grande échelle est moins fluide qu’il pouvait l’être avec l’utilisation de l’API du Table Fusion Layer. Par contre, l’utilisation d’une carte thermique (heat map) s’est avérée une façon très efficace de représenter la distribution des arbres à petite échelle.

La mise à jour s’accompagne également d’une modification de l’interface du filtre dont la fenêtre modale a été remplacée par un menu latéral qui s’affiche lorsque le curseur de la souris touche la limite gauche de l’écran ou l’icône de l’application. Finalement, une fenêtre « À propos de CRAQ » qui détaille l’application et la source des données a été ajoutée. Elle s’affiche en utilisant le lien hypertexte du même nom situé en haut à droite sur la carte.

Exit les tables de fusion pour ODOPQ

Comme ce fut le cas pour odonymie – ville de Québec, les données d’Odonymes du Québec (ODOPQ) quittent les tables de fusion pour la BD MySQL.

L’exercice ne se fit pas sans douleur. Le transfert des données de toponymes du fichier CSV à la table MySQL fut marqué par de nombreuses reprises causées par l’absence de certaines dates d’officialisation dans le fichier CSV. Pour la couche géométrique des municipalités, certains territoires possédant des géométries grandes ou complexes refusaient de se convertir avec l’extension Python de QGIS. J’ai donc choisi d’ignorer ces territoires ne comprenant pas d’odonyme de toute façon et de limiter le territoire de l’application au Québec méridional.

Finalement, les fichiers de l’application ont été transférés dans la zone sécurisée (https) du serveur de GéoPraTIC. Une page de redirection automatique a été mise en place.