Le projet Territoires Géomatique 2013 a pour objectif de développer une nouvelle application web destinée à améliorer l'aménagement du territoire en se concentrant sur les besoins essentiels des utilisateurs. Les choix technologiques reposent sur l'intégration des connaissances de l'équipe et des services existants, avec un accent sur la performance, la sécurité et l'optimisation des données. Les tests de performance et les ajustements des services cartographiques sont cruciaux pour garantir une navigation fluide et un affichage rapide des données.

1. Debreffage du projet Territoires
Géomatique 2013
3 octobre 2013

2. Plan de match
• Qu’est-ce-que Territoires?
• Nos questionnements, nos choix et
leurs impacts
§ Choix technologiques
§ Sécurité
§ Performance

3. • Nouvelle application Web du MAMROT
• Outil d’aide à la décision en
aménagement du territoire
• Bibliothèque virtuelle + navigateur
cartographique + …
• Pour tous les intervenants de la Loi sur
l’aménagement et l’urbanisme

4. Avant Territoires
• Applications indépendantes
• Entretien et évolution compliqués
• Vulnérabilité du processus interne
« alimentant » la bibliothèque

5. Mars 2012
• Êtes-vous capables de faire une
nouvelle application pour remplacer
SIGAT Texte et SIGAT Géo?
• Êtes-vous capable de revoir les
chaînes de production des
documents d’aménagement?

6. Deux grands principes
1. Se concentrer presque exclusivement
sur les besoins essentiels des
utilisateurs
§ Avoir accès aux documents
d’aménagement soumis par les MRC
dans le plus court délai possible
§ Consulter l’information contextuelle pour
aider à la prise de décision

7. Deux grands principes
2. S’appuyer sur l’équipe de
géomatique pour le développement,
l’entretien, le pilotage, le soutien et
l’évolution de la nouvelle solution
§
§
§
§
1 chargée de projet / pilote
1 aménagiste
1 responsable de la cartographie
4 architectes / analystes / programmeurs

8. Contraintes de la refonte
• Technologies de l’information
imparties au CSPQ
• Délais de réalisation serrés
• Ressources limitées

9. Été
2012

10. Septembre
2012

11. Octobre
2012

12. Besoins des utilisateurs
• Détailler puis prioriser les besoins des
utilisateurs
• Ajouter les autres besoins et les
contraintes
§ Sécurité, interface, données,
ressources disponibles, délais…
• Échanger avec les membres de l’équipe
• Officialiser le tout

13. Choix technologiques

14. Bases de nos choix
technologiques
• S’appuyer sur les connaissances de
l’équipe et s’intégrer à l’environnement
interne de production
§ Diminuer les risques et les délais
§ Assurer la pérennité de l’application
• Négocier avec le CSPQ un nouveau
partage des responsabilités

15. Bases de nos choix
technologiques
• Récupérer et adapter des API et des
services existants
§ clicSÉQUR de Revenu Québec pour
l’authentification
§ GLO du ministère de la Sécurité publique
pour la recherche d’adresses et de lieux

16. Technologies retenues
•
•
•
•
•
Site en ASP.Net et javascript
Services Web en .Net
Base de données Oracle 11g
ArcGIS Serveur
Service d’indexation Windows

17. Janvier
2013

18. Développement modulaire
Site de Territoire
et volet
Bibliothèque
Volet Navigateur
Services
cartographiques
Services Web
(navigateur)
Services
applicatifs
(bibliothèque)
Services
applicatifs
(sécurité)
Autres
composants

19. Utilisation de logiciels
et d’API de tiers
• Accélère grandement le développement, mais
• « Localisation »
§ Communauté surtout anglophone
§ Obligation d’une grammaire et d’une syntaxe
parfaites
• Compatibilité avec la majorité des fureteurs
§ Environnements de tests en cours de développement
• Correction de bogues et adaptation du code

20. Évolution d’ArcGIS Serveur et de
l’API pour javascript
Développement
du navigateur
1re livraison
2012/03
Serveur
API
2012/06
2013/01
2013/08
10.0
2.7
10.1
3.0
10.1
3.3
10.2
3.6

21. Sécurité

22. Sécurité
• clicSÉQUR Entreprise
§ Application intégrée au PGAMR
§ Gestion décentralisée des accès à
l’application
§ Gestion centralisée des privilèges de
consultation des données
• ArcGIS Serveur
§ Services cartographiques et Web

23. Sécurité
• Tests d’intrusion exigés par le CSPQ
avant le déploiement
§ Autant l’application que l’environnement
fourni par le CSPQ
• Deux vulnérabilités identifiées dans
Territoires puis corrigées

24. Performance

25. Performance
• Objectif de 2 à 3 secondes pour
l’affichage des données
• Approche utilisée
§ Tuiler le fond de carte
§ Optimiser les données et les services
• Importance des tests de performance

26. Tuiler la carte de base
« Est-ce qu’on utilise un service
existant? »

27. Tuiler la carte de base
• Oui, car
§ Pas besoin d’espace disque supplémentaire
§ Déjà disponible
§ Plusieurs choix possibles (OSM, Google, ESRI, …)
• Non, car
§ Utilisation payante dans le cas des firmes privées
§ Limites administratives différentes de celles officielles au
gouvernement du Québec
§ Échelle 1 : 1128 pas toujours disponible
§ Palette de couleurs difficilement compatible avec nos données
en aménagement

28. Tuiler la carte de base
« Non, on crée notre propre fond
de carte »

29. Tuiler la carte de base

30. Tuiler la carte de base
• Excellent exercice de réflexion
• Fixe la projection et les échelles de
l’application
§ On a opté pour un schéma courant
• Tuilage ciblé selon l’échelle et la pertinence
§ Réseau routier, cadastre rénové
• Taille sur le disque et temps de création
• Stratégie de mise à jour

31. Tests de performance
• Basés sur les journaux d’utilisation de
SIGAT Texte et SIGAT Géo
• Tests structurés et minutés
§ Navigateur
§ Bibliothèque
§ Territoires
• Usage intensif de 7 à 12 utilisateurs

32. Constats
• La recherche dans la bibliothèque est
exigeante, mais le délai est raisonnable
• La navigation est saccadée et certains
utilisateurs ont continué à avoir des
problèmes lors des autres opérations
« Qu’est-ce qu’on fait maintenant, on livre
dans près d’un mois? »

33. Pistes de solutions
• On ajuste les services cartographiques
§ On désactive le tuilage sur demande
§ On travaille sur les données
• On fait un nouveau test de performance
§ Après ces premiers ajustements, la
navigation est beaucoup plus fluide
• On adapte les procédures de pilotage

34. Exemple d’optimisation
Affectations du territoire
• Produit à 1 : 20 k
• Projection géo.
• 23 400 polygones avec
10,8 M de vertex
• 676 thèmes régionaux
• 40 secondes pour afficher
à l’échelle provinciale
• Mise à jour quotidienne

35. Exemple d’optimisation
Affectations du territoire
• Création de « produits » dérivés
1. Données projetées en WGS84
2. Polygones dissous selon 10 thèmes
provinciaux
3. Polygones de moins de 1 km² éliminés et
géométrie simplifiée

36. Exemple d’optimisation
Affectations du territoire
• Service optimisé avec gestion de
l’affichage selon l’échelle
• Moins d’une seconde de temps de
rendu à toutes les échelles
• 5 à 10 minutes supplémentaires
lors du transfert quotidien automatisé
des données

37. En conclusion
• Échanger avec les utilisateurs et
rester ouvert
• Prévoir du temps pour tout ce qui
entoure le « codage » des fonctionnalités

38. Merci
Des questions?