– 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.

Présentation au sujet: "– 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."— Transcription de la présentation:

1 – 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

2 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

3 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.

4 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.

5 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;

6 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…

7 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.

8 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

9 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

10 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

11 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…

12 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.

13 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.

14 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.

15 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

16 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.

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

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25  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

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

27  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

28  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

29 Voici un exemple du fichier de mapping : Fonctionnement : chargement

30  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

31  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

32  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

33 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

34 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 148 6.On ajoute les événements de chacun des entités sélectionnées à l’entité virtuelle…et maintenant, place à la démonstration ! Fonctionnement : transformation

35  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

36  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

37

38  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

39 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;

40 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 !