– Présentation d’un prototype – Développement et implantation d’une structure de données permettant la transformation des données routières. Projet de session Réalisation d’applications en SIG Hiver 2006 Karl Guillotte Mardi, le 18 avril 2006

Présentation Problèmes; But et des objectifs; Les tâches : –Analyse de l’existant : Au niveau conceptuel; Au niveau technologique. –Modélisation; –Développement. Fonctionnement; Présentation du résultat; Problèmes rencontrés; Conclusion et commentaires

Problèmes Les solutions commerciales ne sont pas conçues pour traiter l’ensemble des particularités des données routières :  Forte hétérogénéité des modes de localisation des données routières :  Système de référence planaire (SRP);  Système de référence linéaire (SRL).  Différentes méthodes de référence linéaire (LRM);  Différents modes de segmentation utilisées : dynamique ou statique.

But et objectifs Maîtrise : Développer une méthode générique et un logiciel permettant la transformation des données routières avant leur intégration dans une base de données routières. Prototype :Développer et implanter une structure de données permettant la transformation des données routières.  Effectuer le chargement de données routières;  Re-segmenter un réseau routier à la demande.

Les tâches Analyse de l’existant au point de vue conceptuel; Modélisation de la structure de données routières; Développer la structure de données routières de manière qu’elle puisse être la plus génétique;

Les tâches Développer un module de chargement pour les données de la GéoBase routière sous format Shapefile et GML; Développer un module de transformation des données routières. Permettre à l’usager de visualiser différemment son réseau routier sans le modifier. Ne s’arrête pas à une simple requête…

Les tâches Développer une méthode de référence linéaire générique; Développer des fonctionnalités de positionnement d’événements par référence linéaire (générique); Rendre disponible ces modules sous forme de services web.

British Columbia Road Network System (BCRNS) –Modèle conceptuel complet offrant : Modèles de données pour les segments routiers; Méthodes de référence linéaire; Modèle complet de navigation; Application de restrictions (ex. interdiction de virage); Généralisation de réseau routiers (ex. navigation intra va inter urbaine); Génération de réseaux routier selon les demandes d‘un usager. Analyse de l’existant : conceptuel

GeoBase routière –Réseau routier national, Canada, niveau 1 (RRNC1); –Modèles de données routières offrant : Spécifications de produit : vision segmentée (statique) et SRL (dynamique) d’un réseau routier; Modèles conceptuels (vision segmentée et SRL); Catalogue d’entités (entités des visions segmentée et SRL); Spécifications de métadonnées. –RNCan, Centre d’information topographique de Sherbrooke; –Données disponibles gratuitement sur Internet. Analyse de l’existant : conceptuel

Geographic Data File (GDF) –Norme en transport : Permettant la description et l’échange de réseaux routiers et des données y étant reliées; Offrant des règles sur la façon de capter les données routières et défini leurs formes, leurs attributs et leurs relations; Offrant un format d’échange normalisé (format ASCII). Analyse de l’existant : conceptuel

Intégration de l’existant : conceptuel  Méthodologie : analyse des différents modèles de données disponibles afin de proposer un modèle générique afin de répondre aux besoins de ce projet; Voici les composantes ayant été modélisées…

Intégration de l’existant : conceptuel Le schéma de la norme GDF : Mon utilisation simplifiée de la norme GDF; Fournit des définitions sur les phénomènes d’un réseau routier; Permet à l’utilisateur d’effectuer un « mapping » entre la structure de ses données et celle développée pour le RN-ETL.

Intégration de l’existant : conceptuel Système de référence linéaire (datum linéaire) : Basé sur un système de référence spatiale; Formé de deux graphes planaires; Les données géométriques proviennent des données de l’utilisateur et sont supportées par d’autres classes.

Intégration de l’existant : conceptuel Le référencement linéaire : Méthode permettant de positionner des éléments sur le réseau routier; Utilise le système de référence linéaire (datum linéaire); Permet de ne pas copier des données géométriques, mais les utiliser comme référence; Il en existe plusieurs méthodes.

Intégration de l’existant : conceptuel Événements : Éléments survenant sur un réseau routier; Positionner à l’aide d’une méthode de référence linéaire; Trois types : Ponctuel  Accident Linéaire  Section d’une route en construction Surfacique  Zone écologique

Intégration de l’existant : conceptuel Les vues utilisateurs : Représente la possibilité pour un utilisateur de visualiser son réseau routier de différente façon. Formé d’entités virtuels :  Définit par une entité du RN-ETL : ! Puisque dérivé des données descriptives d’une entité RN-ETL  Leur géométrie provient d’événements routiers.

Intégration de l’existant : conceptuel Les dépendances existantes entre les différents paquetages du RN-ETL…

GeOxygene : Utilisation des objets du General Feature Model (ISO) pour la description et la structuration des entités (gestion des valeurs d’attributs). Utilisation des objets FT_Feature & FT_FeatureCollection pour la gestion des entités routières  RNETLFeature & RNETLFeatureCollection. Analyse de l’existant : technologique

JTS (Java Topology Suite) –API Java offrant des opérateurs topologiques sur des objets SFS (OGC). Très complet : plusieurs classes d’objets permettre de traiter les données géométriques; Très simple d’utilisation; Largement utiliser; Stable; Performant. Analyse de l’existant : technologique

JCS (Java Conflation Suite) –API Java, basé sur JTS, offrant des opérations pour l’intégration et le nettoyage de données géométriques; Utilisé pour la manipulation des données routières; Même avantages que JTS. Analyse de l’existant : technologique

Road Matcher –API Java offrant des opérations pour l’intégration de réseaux routiers, il enrichie les possibilité de JCS; Utilisé pour la structuration des données routières au niveau géométrique (linéaire) et topologique (graphe planaire). Analyse de l’existant : technologique

GeoTools –API Java offrant des opérateurs pour la manipulation des données géospatiales; Utilisé pour la lecture des fichiers Shapefile et la gestion des attributs au niveau méta. Analyse de l’existant : technologique

JDOM Utilisé pour la lecture des fichiers de mapping pour le chargement des données dans la structure de données du RN-ETL; Facilité d’utilisation, surtout lorsqu’on doit scruter un arbre XML; Efficacité. Analyse de l’existant : technologique

SAX Utilisé pour la lecture des éléments GDF; Rapidité : événementiel  pas besoin de lire l’ensemble d’un fichier. Analyse de l’existant : technologique

 Du conceptuel à l’application…pas toujours facile  Très modulaire, je m’inspire du ETL spatial FME;  Vision orienté objet pour du code réutilisable;  Processus itératif…  Environ 60 classes développées, séparées en 15 packages. Développement

 Une classe permet de lancer les trois opérations (méthodes) de base d’un RN-ETL :  E = Extraction;  T = Transformer;  L = Chargement. Fonctionnement

 Structure de données générique pouvant s’adapter à un ensemble de données routières; Par l’utilisation d’un fichier de mapping entre la structure de données du RN-ETL et celle de l’utilisateur; Un fichier de mapping existe pour le chargement automatique des données provenant de la GéoBase routière; Fonctionnement : chargement

 Le fichier de mapping : Fichier de données XML; Permet de rendre les données de l’utilisateur compréhensible par le RN-ETL Pratique pour l’exportation futur des données dans d’autres formats de données;  Structures de données supportées :  Shapefile;  GML. Fonctionnement : chargement

Voici un exemple du fichier de mapping : Fonctionnement : chargement

 Les données géométriques sont conservées en format JTS (OGC) : Plusieurs traitements doivent être apportés aux données lors du chargement; Des processus de traduction permet de convertir les données géométriques dans un format conforme à ISO.  Les valeurs d’attributs originales sont conservées : Pour une interaction avec les données du RN-ETL plus simple pour l’usager; Au besoin, les valeurs pourront être converties afin d’être conforme à la norme GDF. Fonctionnement : chargement

 Le chargement génère :  Un réseau routier formé : D’un datum linéaire incluant : deux graphes et les brins et nœuds topologiques pour chacun; Des méthodes de références linéaires (une seule pour l’instant); Des métadonnées sur le réseau (ISO 19115);  L’ensemble des entités routières : Séparés en collection selon la norme GDF; Guidé par la lecture du fichier de mapping. Fonctionnement : chargement

 La transformation développée permet de visualiser les entités d’un réseau routier différemment sans toutefois les modifier…je les ai appelé entités virtuelles ! Fonctionnement : transformation

Le processus de transformation… 1.Définir des Traversals :  Les plus génériques sont formés entre deux intersections (graphe de navigation);  Les traversals servent à positionner les événements. 2.Calibration des traversals  Ajout des points de références (Point de départ et de fin avec distance associé). 3.Calibration d’un réseau routier avec les traversals :  Chaque entité routière doit pouvoir se positionner sur les traversals au moyen événements. Fonctionnement : transformation

Le processus de transformation… 4.On crée une entité virtuelle :  Il ne faut oublier sa définition (les attributs), elle peut être emprunter d’une entité déjà existante; 5.On requête le réseau routier afin de récupérer les entités routières à faire partie de l’entité virtuelle;  Route On ajoute les événements de chacun des entités sélectionnées à l’entité virtuelle…et maintenant, place à la démonstration ! Fonctionnement : transformation

 Compréhension des concepts théorique : Effectuer une première itération en programmation.  Apprentissage des nombreux APIs : Pas le choix ! Il faut les apprendre. Heureusement que nous avons accès au code source…  Solutions souvent trop compliquées : Acquérir une meilleure connaissance des APIs et au besoin reprendre la programmation de certaines composantes. Problèmes rencontrés

 Passage du schéma conceptuel au schéma applicatif : La première itération permet de s’insérer dans le travail.  Compréhension des graphes planaires et application aux données routières; Pas le choix ! Lecture sur le sujet et tests !  Ordonner des lignes; L’utilisation des graphes topologiques permet de connaître les prédécesseurs et les successeurs aux brins topologiques. Problèmes rencontrés

 Lecture des fichiers GML possédant des schémas spéciaux : Limité la lecture des données en format Shapefile seulement. Il aurait été trop long de régler le problème !  Le manque de temps… Mettre de côté la partie d’accès au RN-ETL via un service Web, et… Travailler fort ! Problèmes rencontrés

Conclusion et commentaires Comment savoir si l’on a vraiment appris quelque chose ? Si on avait à reprendre le même travail et qu’on le ferait différemment ! Lire davantage avant de commencer à programmer; Datum linéaire à l’extérieur d’un réseau routier, ce sont deux éléments différents;

Conclusion et commentaires Dans le futur ! Les entités virtuelles devraient être se limiter aux intersections; Automatiser le processus de re-segmentation; Chaque visualisation différente d’un réseau routier, devra former un autre réseau routier, mais virtuel ! Permettre l’importation de méthodes de référence linéaire… Des questions ? Vos commentaires sont tous les bienvenus ! Merci !