Académie de Montpellier
Université Montpellier II
Sciences et Techniques du Languedoc
RAPPORT DE STAGE MASTER 2
Effectué à ...
TABLE DES MATIÈRES TABLE DES MATIÈRES
Table des matières
1 Remerciements 5
2 Introduction 6
2.1 Présentation de l’organism...
TABLE DES MATIÈRES TABLE DES MATIÈRES
7 Réalisations 21
7.1 Données et Base de données . . . . . . . . . . . . . . . . . ....
TABLE DES MATIÈRES TABLE DES MATIÈRES
Avant propos
« Agir d’abord, rectifier ensuite s’il y a lieu, re-
prendre tout à zéro...
1 REMERCIEMENTS
1 Remerciements
Je tiens tout d’abord à exprimer ma profonde gratitude à tous mes tuteurs et à ceux qui on...
2 INTRODUCTION
2 Introduction
Nous allons donner en introduction la description de l’équipe d’accueil au sein de laquelle ...
2.2 Lettre de mission 2 INTRODUCTION
2.1.2 Station SEAS-OI
La station SEAS-OI (Surveillance de l’Environnement Assistée pa...
3 CONTEXTE SCIENTIFIQUE
3 Contexte scientifique
3.1 Accès aux soins
L’accessibilité est la capacité de la population ou d’u...
3.2 Ile de la Réunion 3 CONTEXTE SCIENTIFIQUE
heures d’ouverture des services de santé, du temps d’attente en salle d’atte...
3.3 Calcul de temps de parcours 4 ÉTUDE DE L’EXISTANT
3.3 Calcul de temps de parcours
Historiquement, la problématique du ...
4.1 Applications Web 4 ÉTUDE DE L’EXISTANT
4.1.1 Owlapps Geomarketing
Owlapps 1
est une application web cartographique qui...
4.1 Applications Web 4 ÉTUDE DE L’EXISTANT
4.1.6 Walkit
Walkit 7
est conçu spécialement pour le calcul d’itinéraire pour l...
4.2 Environnement de Développement : Frameworks 4 ÉTUDE DE L’EXISTANT
4.2 Environnement de Développement : Frameworks
Dans...
5 PLANIFICATION
4.2.6 NetworkX
NetworkX 19
est une libre application très complète développée sous Python, qui manipule to...
6 MÉTHODOLOGIE
d’elles, en mettant le point sur les avantages et les inconvénients de leurs différents services. Paral-
lèl...
6.2 Les outils de gestion et de visualisation des données spatiales 6 MÉTHODOLOGIE
Figure 2 – Le diagramme UML du modèle O...
6.3 PgRouting et ses fonctionnalités 6 MÉTHODOLOGIE
PostgreSQL dispose d’une extension géographique PostGis. Cette extensi...
6.3 PgRouting et ses fonctionnalités 6 MÉTHODOLOGIE
Figure 3 – Lien entre PostgreSQL, PostGis, QGis et PgRouting
PgRouting...
6.3 PgRouting et ses fonctionnalités 6 MÉTHODOLOGIE
jusqu’à épuisement des sommets ou jusqu’à sélection du sommet d’arrivé...
6.3 PgRouting et ses fonctionnalités 6 MÉTHODOLOGIE
La communauté PgRouting est relativement dynamique : soutien de l’OSGé...
7 RÉALISATIONS
7 Réalisations
7.1 Données et Base de données
Comme indiqué dans la section précédente, nous avons besoin d...
7.1 Données et Base de données 7 RÉALISATIONS
Nom
Prénom
Carte vitale {O/N}
Honoraire
Tel
Num_voie
Nom-Voie
CP
Ville
Compl...
7.1 Données et Base de données 7 RÉALISATIONS
Figure 7 – Aperçu de la page d’AMELI
Un prétraitement de ces données était n...
7.1 Données et Base de données 7 RÉALISATIONS
(SELECT med.id_med, med.nom, med.prenom, med.honoraire,
med.carte_vitale,
me...
7.1 Données et Base de données 7 RÉALISATIONS
7.1.2 Centre de soins
Pour les structures sanitaires, nous avons récupéré le...
7.2 Installation de PgRouting et ses fonctions 7 RÉALISATIONS
7.2 Installation de PgRouting et ses fonctions
7.2.1 Install...
7.2 Installation de PgRouting et ses fonctions 7 RÉALISATIONS
Figure 10 – Modéle du graphe construit par PgRouting
Lors de...
7.2 Installation de PgRouting et ses fonctions 7 RÉALISATIONS
III, afin de bien vérifier la création des tables dans notre b...
7.2 Installation de PgRouting et ses fonctions 7 RÉALISATIONS
Figure 12 – Réseau de points (noeuds) de l’île de la Réunion...
7.3 Isochrones 7 RÉALISATIONS
correspondant à l’id du nœud destination choisi et deux booléens directed vrai si le graphe ...
7.3 Isochrones 7 RÉALISATIONS
Pour résoudre ce problème, il faut calculer dans un premier temps, le(s) point(s) du réseau ...
7.3 Isochrones 7 RÉALISATIONS
7.3.2 Calcul sur réseau étendu
L’idée est d’enrichir le réseau initial en découpant le terri...
7.4 Visualisations des résultats 7 RÉALISATIONS
7.4 Visualisations des résultats
Cette partie sera dédiée à la visualisati...
7.4 Visualisations des résultats 7 RÉALISATIONS
Figure 15 – Boite de dialogue du plugin Contour
On peut visualiser le résu...
7.4 Visualisations des résultats 7 RÉALISATIONS
7.4.3 Isochrones obtenues
Isochrone réseau initial La carte isochrone avec...
7.4 Visualisations des résultats 7 RÉALISATIONS
Figure 18 – Carte isochrone avec un temps de parcours entre 0 et 15 minute...
7.4 Visualisations des résultats 7 RÉALISATIONS
Figure 19 – Carte isochrone avec un temps de parcours entre 0 et 15 minute...
8 CONCLUSION ET PERSPECTIVES
8 Conclusion et Perspectives
Ce travail a permis de développer une méthode pour mesurer les t...
9 ANNEXES
9 Annexes
9.1 Principe de la méthode de calcul des Isochrones
Ci dessous le code exemple pour le calcul des isoc...
9.1 Principe de la méthode de calcul des Isochrones 9 ANNEXES
SELECT isochrone();
# Enfin, création de la table "isochrone...
RÉFÉRENCES RÉFÉRENCES
Références
[COMA10] Coquel et Mazeran, Conception d’un démonstrateur d’analyse géographique des rése...
Prochain SlideShare
Chargement dans…5
×

rapport_stage_issame

1 122 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 122
Sur SlideShare
0
Issues des intégrations
0
Intégrations
17
Actions
Partages
0
Téléchargements
24
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

rapport_stage_issame

  1. 1. Académie de Montpellier Université Montpellier II Sciences et Techniques du Languedoc RAPPORT DE STAGE MASTER 2 Effectué à : ESPACE-DEV - Montpellier et Station SEAS-OI - L’île de la Réunion Spécialité : D.E.C.O.L Proximité d’un « aléa » sanitaire et accessibilité aux soins : implications pour le risque leptospirose à la Réunion. par Issame AMAL Date : 31 Août 2014 Sous la direction de Vincent HERBRETEAU, Christophe RÉVILLION et la contribution de Thérèse LIBOUREL Tuteur pédagogique Michel LECLERE
  2. 2. TABLE DES MATIÈRES TABLE DES MATIÈRES Table des matières 1 Remerciements 5 2 Introduction 6 2.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1 UMR Espace Dev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2 Station SEAS-OI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Lettre de mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3 Contexte scientifique 8 3.1 Accès aux soins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Ile de la Réunion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Calcul de temps de parcours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4 Étude de l’existant 10 4.1 Applications Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1 Owlapps Geomarketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.2 Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.3 Bing Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.4 Mappy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.5 ViaMichelin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.6 Walkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.7 MoodWalkR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.8 Calculitinéraires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.9 Géovélo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.10 YourNavigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.11 OpenRouteService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 Environnement de Développement : Frameworks . . . . . . . . . . . . . . . . . . . . 13 4.2.1 RouteFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2 SmartRoutingServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.3 ArcGis Network Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.4 OSRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.5 Gosmore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.6 NetworkX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.7 GRASS Network Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5 Planification 14 6 Méthodologie 15 6.1 Les données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2 Les outils de gestion et de visualisation des données spatiales . . . . . . . . . . . . . 16 6.3 PgRouting et ses fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2
  3. 3. TABLE DES MATIÈRES TABLE DES MATIÈRES 7 Réalisations 21 7.1 Données et Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1.1 Médecins généralistes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1.2 Centre de soins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.2 Installation de PgRouting et ses fonctions . . . . . . . . . . . . . . . . . . . . . . . . 26 7.2.1 Installation de PgRouting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.2.2 Principales fonctions de PgRouting . . . . . . . . . . . . . . . . . . . . . . . . 29 7.3 Isochrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.3.1 Calcul sur réseau initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.3.2 Calcul sur réseau étendu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.4 Visualisations des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.4.1 Méthode de coloration « Graduée » . . . . . . . . . . . . . . . . . . . . . . . 33 7.4.2 Méthode avec le plugin « Contour » . . . . . . . . . . . . . . . . . . . . . . . 33 7.4.3 Isochrones obtenues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8 Conclusion et Perspectives 38 9 Annexes 39 9.1 Principe de la méthode de calcul des Isochrones . . . . . . . . . . . . . . . . . . . . 39 3
  4. 4. TABLE DES MATIÈRES TABLE DES MATIÈRES Avant propos « Agir d’abord, rectifier ensuite s’il y a lieu, re- prendre tout à zéro s’il le faut, mais ne jamais rester inactif à la recherche du parfait » Jean COCTEAU 4
  5. 5. 1 REMERCIEMENTS 1 Remerciements Je tiens tout d’abord à exprimer ma profonde gratitude à tous mes tuteurs et à ceux qui ont participé à ce stage. Mme Libourel pour ses cours, ses conseils judicieux et sa bonne humeur. M. Leclère pour son implication et sa préoccupation pour mon stage. M. Herbreteau et M. Révillion qui m’ont en ef- fet donné des conseils à la fois nombreux, divers et utiles ainsi pour leurs idées et leur aide précieuse. Je tiens aussi à remercier toute personne qui a donné les orientations de ce projet en endossant au moment propice la veste du chercheur avide de science, celle de l’ingénieur efficace ou celle du client exigeant. Sans oublier bien évidemment les remerciements non distribués (quelle injustice !). Ils s’adressent à toutes ces personnes, informaticiens de génie ou programmeurs du dimanche qui ont rédigé, col- lecté, trié, classé et mis en ligne tous les documents dont je me suis servi allègrement pour mon travail, notamment les développeurs de PgRouting. Je salue aussi la communauté OpenStreetMap pour le travail de création de données effectué. Enfin, un spécial merci à toute l’équipe de SEAS-OI pour leur accueil et leur soutien tout au long de mon stage à la station. Le meilleur des remerciements est bien sûr pour tous mes co-stagiaires : Annabelle, Artadji, Emmanuelle, Guy, Julien l’opérateur, Julien le breton, Lucas, Mathilde, Ophélia, Sabine et Stéphane pour la précieuse aide que vous m’avez apportée, l’ambiance du travail, les sorties qui m’ont permis de découvrir l’île. 5
  6. 6. 2 INTRODUCTION 2 Introduction Nous allons donner en introduction la description de l’équipe d’accueil au sein de laquelle le stage s’est déroulé et rappeler les grandes lignes de la lettre de mission. 2.1 Présentation de l’organisme d’accueil 2.1.1 UMR Espace Dev L’UMR Espace Dev (IRD, UM2, UAG, UR) développe et met en œuvre des méthodologies innovantes de spatialisation des connaissances en environnement, par télédétection spatiale, pour le développement durable des territoires aux échelles locales, régionales, globales, depuis l’acquisition des données jusqu’au processus décisionnel. Elle est constituée de trois équipes pluridisciplinaires de recherche : • Equipe Observation Spatiale de l’Environnement (OSE) : Traitement, analyse et exploita- tion de flux de données, indicateurs spatialisés bio-géophysiques, extraction et modélisation d’objets/processus à partir de données satellitaires. • Equipe Approche Intégrée des Milieux et des Sociétés (AIMS) : Paysage et observatoire pour la gestion environnementale, environnement et santé, gestion intégrée des territoires insulaires et littoraux. • Equipe Système d’Information et de Connaissance (SIC) : Acquisition, gestion, représenta- tion, partage et intégration de données et connaissances, modélisation de dynamiques spatio- temporelles, cartographie sémantique, diffusion et aide à la décision. Elle dispose aussi d’un service technique Télédétection, Informatique et Modélisation. Les tutelles de l’UMR ont des spécificités notamment l’Institut de Recherche pour le Développement. C’est un organisme de recherche français qui répond, avec ses partenaires des Suds , aux enjeux internatio- naux du développement. Améliorer les conditions sanitaires, comprendre l’évolution des sociétés, préserver l’environnement et les ressources constituent les piliers de son action dans la perspective d’atteindre les objectifs du millénaire pour le développement. Établissement public français à caractère scientifique et technologique, l’IRD est placé sous la tutelle conjointe des ministères chargés de la Recherche et des Affaires étrangères. Il déploie ses activités à l’international depuis son siège, à Marseille, et ses deux centres métropolitains de Mont- pellier et de Bondy. Grâce à son action de recherche, de formation et d’innovation en partenariat, il rayonne dans plus d’une cinquantaine de pays, en Afrique, sur le pourtour méditerranéen, en Asie, en Amérique latine et en outre-mer. Fondés sur l’interdisciplinarité, les projets menés conjointement traitent de questions cruciales pour les Suds : maladies tropicales et de civilisation, relations entre santé et environnement, changements climatiques, ressources en eau, sécurité alimentaire, écosystèmes tro- picaux et méditerranéens, risques naturels, pauvreté, vulnérabilité et inégalités sociales, migrations, évolution du marché du travail ... 6
  7. 7. 2.2 Lettre de mission 2 INTRODUCTION 2.1.2 Station SEAS-OI La station SEAS-OI (Surveillance de l’Environnement Assistée par Satellite pour l’Océan Indien) de Saint-Pierre de La Réunion est à la fois une station de réception d’imagerie satelli- taire et un centre d’excellence en télédétection, développant une expertise thématique concernant principalement : Le suivi des dynamiques agro-forestières et de la biodiversité en relation avec le changement des conditions climatiques. L’environnement côtier, sociétés et changement climatique. La santé et l’environnement, thématique dans lequel s’intègre ce stage. Les risques naturels. Dans un rayon de 2 500 km autour de la Réunion, SEAS-OI reçoit des images satellites optiques (SPOT 5) et RADAR (RADARSAT-2) haute résolution. Au sein de SEAS-OI, l’IRD (Institut de Recherche pour le Développement), l’Université de la Réunion et la Région Réunion mettent en œuvre des projets de coopération scientifique et opérationnelle dans le domaine de la télédétection. Dans cet optique, les données acquises par SEAS-OI sont disponibles gratuitement pour les institutions publiques et les laboratoires de recherche du sud-ouest de l’Océan Indien. SEAS-OI est un programme financé par la Région Réunion, l’Etat, l’IRD, l’Université de la Réunion, et soutenu par l’Europe. 2.2 Lettre de mission Dans le cadre des projets de recherche sur l’étude des liens entre les sociétés, l’environnement et la leptospirose menés par l’équipe de l’unité Espace-Dev, ce stage s’intègre entre deux projets : Le projet LeptOI à la Réunion et aux Seychelles, qui a pour objectif la modélisation du risque de la maladie de la leptospirose humaine dans les îles du Sud-Ouest de l’Océan Indien. Le projet ISSE (Intersections Santé - Sociétés - Environnement ) à Mayotte, qui propose une approche pluridisciplinaire pour comprendre les mécanismes de construction des maladies vectorielles et de leurs rapports avec l’environnement, le climat et les sociétés. Dans ce contexte, il s’agit en premier lieu de mettre en place un outil permettant de créer des cartes isochrones (courbes de temps de parcours identique) par rapport aux structures sanitaires (cabinets médicaux et établissements de santé) ou à des lieux dits « à risque ». Pour cela, la pre- mière étape est la conception et la réalisation d’une base de données spatiales relative aux structures sanitaires et aux lieux dits à risque, avec le logiciel Postgres/Postgis. L’étape suivante consiste à mettre en place le framework PgRouting qui permet la mise en œuvre des méthodes d’analyse spatiale basées sur la prise en compte de la topologie et des graphes sous-jacents afin d’élaborer à partir d’une méthode de calcul d’itinéraire des cartes isochrones. 7
  8. 8. 3 CONTEXTE SCIENTIFIQUE 3 Contexte scientifique 3.1 Accès aux soins L’accessibilité est la capacité de la population ou d’une partie de la population d’obtenir des renseignements relatifs au temps d’accès aux services de santé disponibles. Cette capacité est déterminée par des facteurs de localisation, culturels, économiques, temporels, organisationnels et informationnels, qui peuvent être des barrières ou des facilitateurs à l’obtention des services [RAPPORT CREDES]. « L’accès aux soins est-il seulement géographique ou financier ? ». Depuis les années 60, plusieurs géographes se sont appliqués à définir ce concept clé pour améliorer la performance de tout système de santé. Le concept d’accès se définit comme le rapport entre les besoins en soins d’une population (caractéristiques socio-démographiques) et l’utilisation du système de soins (prise en charge effec- tive des patients). Il correspond à l’adéquation entre les caractéristiques des professionnels de santé et les attentes des patients évaluées à travers leur satisfaction. Ainsi, il ne s’agit plus seulement d’accès géographique ou financier mais d’un accès multidimensionnel. Il faut souligner également l’importance du rapport entre l’offre de soins et la demande de la population sur un espace géogra- phique donné, mais aussi la relation entre les caractéristiques et les attitudes des patients et celles des professionnels de santé (âge, sexe, culture, religion, attitude, moyen de paiement, lieu et type d’installation, etc.). Bien choisir son médecin est primordial pour se soigner. On peut distinguer deux types de mé- decins : les médecins généralistes, qui s’occupent et apportent des soins généraux (notre exemple d’étude qu’on va voir par la suite), et les médecins spécialistes, qui sont compétents dans des domaines de santé particuliers comme les épidémiologistes, ophtalmologues, dermatologues, etc. Le premier droit d’une personne malade est d’avoir accès aux soins. De ce fait, les acteurs de santé doivent mettre en œuvre les moyens nécessaires pour apporter au patient malade le meilleur trai- tement dont l’efficacité est reconnue par rapport aux risques encourus. Ces dernières années, la recherche médicale et sociale a beaucoup progressé. Cependant, l’accès aux soins reste difficile pour certaines personnes comme les handicapés et les malades chroniques en raison de leur dépendance physique et psychique, de leurs modalités particulières de communi- cation, des caractères propres de leur pathologie nécessitant une compétence technique et humaine du soignant, des aménagements matériels ou encore d’une réorganisation de l’espace, ainsi que le manque d’offre de services et de soins adaptés. Le taux de personnel médical par habitant doit être pondéré par sa répartition géographique. La facilité d’accès aux soins peut être notablement plus faible dans des zones rurales ou à faible densité de population, voire dans des banlieues à forte population minoritaire. Cela concerne en premier lieu les soins spécialisés, mais aussi l’accès à des soins de première nécessité ou para-médicaux. C’est le cas en France avec l’existence de déserts médicaux (manque de praticiens dans le domaine de santé au niveau d’une zone donnée), aux États-Unis, mais plus encore dans les pays offrant de faibles ressources médicales. Enfin, une autre dimension de l’accès concerne l’organisation des services de santé pour accueillir le patient et la capacité de celui-ci à s’adapter à cette offre. Il s’agit par exemple, des jours et 8
  9. 9. 3.2 Ile de la Réunion 3 CONTEXTE SCIENTIFIQUE heures d’ouverture des services de santé, du temps d’attente en salle d’attente, du système de paiement, de la possibilité de prendre des rendez-vous ou être pris en urgence, etc. Ces dimensions sont étroitement liées et constituent autant de difficultés potentielles pour le patient qui souhaite obtenir une consultation. 3.2 Ile de la Réunion Le stage s’inscrit dans le contexte de l’ile de la Réunion dont nous donnons quelques caractéris- tiques ci-dessous. L’île de la Réunion est un département français d’outre-mer situé dans l’océan Indien, au large de Madagascar. Elle doit son existence à l’activité volcanique, qui a donné naissance à deux édifices. Le plus élevé, le piton des Neiges (3 069 m), est aujourd’hui éteint, alors que le piton de la Fournaise (2 631 m) présente une activité permanente, avec des éruptions en moyenne chaque année. Le relief est particulièrement vigoureux et accidenté : les altitudes sont fortes, les pentes raides, les rivières encaissées au fond de gorges abruptes, ce qui explique que les flancs Sud-Est de l’île sont restés en grande partie vierges. Les pentes de l’île sont incisées par un réseau dense de ravines qui représente une forte contrainte à la circulation. Néanmoins, elle valorise ses spécificités culturelles issues d’un fort métissage (immigration ta- moule, chinoise, indiens musulmans du Nord de l’Inde...), les différentes communautés ayant par ailleurs gardé leurs traditions. La plus grande partie de la population se concentre sur le littoral. L’espace agricole trouve sa place entre le littoral urbanisé et les massifs montagneux. La préserva- tion des terres agricoles face à la pression urbaine est donc un enjeu fort. La faiblesse des activités productives caractérise l’île. Le secteur de la construction est essentiel, car soutenu par le besoin en logements et la défiscalisation ainsi que par les grands travaux entrepris depuis une dizaine d’années. Les services sont les vrais moteurs de l’économie : l’emploi public représente plus de 40 % des emplois totaux et le secteur de la consommation des ménages est en constante progression. Le tou- risme est important : les atouts de l’île sont nombreux, culturels et paysagers. Chaque année environ 400 000 touristes (les 3/4 de métropole) fréquentent l’île, mais la part du tourisme affinitaire est encore très forte et la clientèle étrangère peu nombreuse. Si l’agriculture a longtemps été le pilier de l’économie avec la production de sucre de canne, deux autres filières, fruits et légumes et élevage, sont désormais significatives. Cependant la production reste au même niveau alors que les consommations et les importations augmentent. Tous ces aspects géographiques, financiers et socio-démographiques constituent les éléments les plus importants à prendre en compte pour mieux décrire l’accessibilité aux soins notamment étayer le calcul de temps de parcours. [SANTE] 9
  10. 10. 3.3 Calcul de temps de parcours 4 ÉTUDE DE L’EXISTANT 3.3 Calcul de temps de parcours Historiquement, la problématique du calcul du temps de parcours est parmi l’une des plus cé- lèbres dans le domaine des mathématiques et statistiques depuis le XIXième siècle connue sous le nom du problème du fameux voyageur de commerce, dont le but était de trouver un ordre de parcours de plusieurs villes minimisant le temps de trajet . Le temps de parcours d’un véhicule ou d’un piéton entre un point A et un point B peut être trivialement défini par le temps qui lui est nécessaire pour relier l’un à l’autre. Il est susceptible de varier selon plusieurs facteurs qui influencent ce calcul : la variation des conditions d’espace (pente, chemin inaccessible, etc.), les conditions du trafic au cours du temps, le comportement des conduc- teurs et les caractéristiques des véhicules ... Il est considéré comme l’un des éléments majeurs dans l’étude d’accès aux soins. Le temps d’accès aux soins, en zone métropolitaine, est globalement satisfaisant : 95 % de la population française a accès à des soins de proximité en moins de quinze minutes. De même, la plupart des médecins spécialistes libéraux et les équipements médicaux les plus courants sont accessibles en moyenne à moins de 20 minutes par la route. Concernant les soins hospitaliers cou- rants, 95 % de la population française peut y accéder en moins de 45 minutes, les trois quarts en moins de 25 minutes. Comme le précise la lettre de mission, nous devons donc nous attacher à des calculs d’itinéraires et de temps de parcours dans le contexte spécifique du système de santé de la Réunion. 4 Étude de l’existant Selon Wikipédia,« Le routage est le mécanisme par lequel des chemins sont sélectionnés dans un réseau afin d’acheminer une route en partant d’un point de départ vers une destination ». Le rou- tage est une tâche exécutée dans de nombreux réseaux, tels que le réseau téléphonique, les réseaux de données électroniques comme l’Internet, ou encore les réseaux de transports ... En s’inspirant de ce mécanisme, il s’agit de donner aux utilisateurs sous forme, généralement, d’une application web connectée à une base de données géographique une représentation carto- graphie des chemins optimaux d’accès aux soins par exemple. La principale fonctionnalité de ces systèmes est basée sur des algorithmes de parcours de graphe, qu’on va étudier en détail par la suite. Nous énumérons ci-dessous tout d’abord les exemples d’applications existantes et ensuite les environnements de développement (framework) qui ont retenu notre attention. 4.1 Applications Web De nombreuses applications web proposent des services de calcul d’itinéraire dans un réseau routier. Les différents algorithmes utilisés donnent des résultats très satisfaisants pour les plus courts trajets de parcours. Dans cette partie, on va s’intéresser à une comparaison entre les différentes solutions les plus utilisées qui sont proposées sur le web, tout en mettant parallèlement le point sur les aspects qui caractérisent chaque cas. 10
  11. 11. 4.1 Applications Web 4 ÉTUDE DE L’EXISTANT 4.1.1 Owlapps Geomarketing Owlapps 1 est une application web cartographique qui sert à rechercher les points d’intérêt grâce au web service Google Places 2 et en utilisant les données OpenStreetMap aussi. Il permet, dans une zone donnée, de créer des isochrones (parcours en voitures) ou des isodistances (distance à vol de oiseau) avec un point de départ et un temps de parcours que l’utilisateur peut définir. 4.1.2 Google Maps Google Maps 3 est un service gratuit de cartographie en ligne, et sans doute l’application la plus utilisée et consultée sur le web pour le calcul d’itinéraire. Cela est dû à l’accès facile à l’application, sa disponibilité sur toutes les plateformes (ordinateur, tablette et mobile), la qualité des données géographiques utilisées, qui sont produites par Google lui-même, et sa couverture du monde entier. L’une des principales caractéristiques de Google Maps c’est qu’il prend en considération l’attri- but d’altitude pour son calcul d’itinéraire piéton. Exemple : un trajet qui contient une montée sera plus long qu’un autre qui contiendra une descente. 4.1.3 Bing Maps L’auto-description de Bing Maps 4 : « Explorez la Terre à l’aide de cartes interactives, d’affichages d’itinéraires et de trafic, d’images satellite et aériennes, de cartes 3D et de villes 3D. » nous donne une idée générale sur les principaux service qu’offre cette application web. Bing utilise les données de Nokia comme source de données. Les itinéraires pour les piétons sont pris en compte sur Bing Maps. 4.1.4 Mappy Mappy 5 est un service de cartographie et d’informations géolocalisées sur web et mobile. Il offre des services tels que la recherche des plans et d’itinéraire ainsi que des solutions de navigation pour mobile. Il utilise des sources de données propriétaires. 4.1.5 ViaMichelin ViaMichelin 6 est une solution créée par le groupe Michelin afin de proposer des services d’aide à la mobilité sur supports numériques : Internet, PDA, mobile et GPS portables. Il utilise ses propres sources de données et celles provenant de Tele Atlas. Toutefois, les chemins piétons ne sont pas tenus dans l’application. 1. http ://www.owlapps.net/application-geomarketing 2. https ://developers.google.com/places/documentation/ 3. http ://www.maps.google.com/ 4. http ://www.bing.com/maps 5. http ://fr.mappy.com/ 6. http ://www.viamichelin.fr/ 11
  12. 12. 4.1 Applications Web 4 ÉTUDE DE L’EXISTANT 4.1.6 Walkit Walkit 7 est conçu spécialement pour le calcul d’itinéraire pour les piétons. C’est une initiative lancée au Royaume-Uni et qui couvre actuellement 40 villes. Il offre plusieurs options pour le calcul, comme l’option de sélectionner un itinéraire « moins occupé », qui évite les routes principales toutes les fois où cela est possible. Quelques villes ont également les caractéristiques supplémentaires, telles que les profils de colline, et les itinéraires avertis de pollution atmosphérique. 4.1.7 MoodWalkR MoodWalkR 8 est une solution de calcul d’itinéraire pour les piétons qui propose des parcours piétons en fonction des choix de balade (culture, nature, shopping...). Il est disponible pour Toulouse et son agglomération, et se base sur OpenStreetMap comme source de données. 4.1.8 Calculitinéraires Calculitinéraires 9 permet de calculer la distance totale, ainsi que le dénivelé, des parcours spor- tifs, effectués à pied, à vélo ou à roller, en les traçant sur une carte Google Maps ou IGN Géoportail. L’application permet aussi de calculer la vitesse moyenne sur le parcours, la dépense en calorie et affiche le profile topographie de votre parcours. 4.1.9 Géovélo Géovélo 10 est un site qui propose de calculer le trajet de l’utilisateur et lui proposer un itinéraire adapté à sa pratique du vélo et à ses souhaits : du parcours le plus sécurisé au parcours le plus rapide. Sa source de données est basée sur OpenStreetMap et il est considéré comme l’un des principaux contributeurs français à l’enrichissement de la base OSM : qui collecte et corrige les données sur le territoire français. 4.1.10 YourNavigation YourNavigation 11 est un service web permettant de proposer deux types d’itinéraire : le plus court et le plus rapide. Il propose ainsi de choisir le type de transport ou de déplacement (voi- ture, motos, piétons ..). Les données géographiques OpenStreetMap sont les principales sources de données. 4.1.11 OpenRouteService OpenRouteService 12 est un projet développé au sein de l’Université de Heiedelberg en Alle- magne. C’est une grande réalisation dans le domaine du routage et du calcul d’itinéraire. Source de données : OpenStreetMap. 7. https ://www.walkit.com/ 8. https ://www.moodwalkr.makina-corpus.net/ 9. https ://www.calculitineraires.fr/ 10. https ://www.geovelo.fr/ 11. https ://www.yournavigation.org/ 12. https ://www.openrouteservice.org/ 12
  13. 13. 4.2 Environnement de Développement : Frameworks 4 ÉTUDE DE L’EXISTANT 4.2 Environnement de Développement : Frameworks Dans cette partie on va présenter les principaux outils disponibles qui permettent de calculer un itinéraire, et leurs différentes propriétés, ainsi que les algorithmes implémentés pour chaque framework. Une section spéciale sera réservée à l’analyse du framework que nous avons sélectionné : PgRouting. 4.2.1 RouteFinder RouteFinder 13 est une application soutenue par RouteWave pour les utilisateurs de MapInfo pour le calcul de cheminement et de calcul d’itinéraire. Il permet aussi de calculer un itinéraire d’un point à l’autre, avec un certain nombre de points intermédiaires que l’utilisateur peut définir sur la carte. C’est une application payante, avec une édition démo gratuite sur le site. Les algorithmes utilisés ne sont pas indiqués. 4.2.2 SmartRoutingServer SmartRoutingServer 14 est un composant de calcul dédié au calcul d’itinéraires, ainsi que plu- sieurs options telles que la recherche de proximité ou encore la recherche de position au cours d’un itinéraire. C’est un projet soutenu par GeoConcept, qui est une application payante. 4.2.3 ArcGis Network Analyst ArcGis Network Analyst 15 permet de calculer des itinéraires plus efficaces. Il offre aux utili- sateurs la possibilité de modéliser des conditions de réseau réalistes comprenant des restrictions d’intersection, des limitations de vitesse, des restrictions de hauteur et des conditions de circulation à différentes heures de la journée. Soutenu par ESRI France et utilisé sur ArcGis, Network Analyst est un service payant qui utilise des algorithmes de calcul : "Dijkstra" et "Contraction Hierarchies". 4.2.4 OSRM Open Source Routing Machine 16 est un projet OpenSource de Dennis Luxen pour le calcul d’itinéraire, développé en C++ et qui se base sur OpenStreetMap comme source de ses données. Il fait de "Contraction Hierarchies" son principal algorithme de calcul. Le code source est disponible sur GitHub. 17 4.2.5 Gosmore Gosmore 18 est un module de calcul d’itinéraire et de visualisation des données XML d’OpenS- treetMap. Disponible sur Android, Linux, MacOs-X et Windows, il permet d’obtenir la localisation GPS courante ainsi la que visualisation de la carte géographique. Il est gratuit, peu actif et utilise l’algorithme de "Dijkstra" pour ses calculs. 13. https ://www.routino.org/uk/router.html 14. https ://www.geoconcept.com/scheduling-optimisation/smartrouting-route-calculation-engine 15. https ://www.esri.com/software/arcgis/extensions/networkanalyst 16. https ://project-osrm.org/ 17. https ://github.com/DennisOSRM/Project-OSRM 18. https ://wiki.openstreetmap.org/wiki/Gosmore 13
  14. 14. 5 PLANIFICATION 4.2.6 NetworkX NetworkX 19 est une libre application très complète développée sous Python, qui manipule tous les algorithmes de calcul qui se basent sur les graphes, y compris le routage, comme "Dijkstra", "Bellman-Moore", "Ford-Bellman", A* ... 4.2.7 GRASS Network Analysis GRASS est un logiciel de système d’information géographique (SIG) libre développé par OSGeo. Il contient le module Network Analysis 20 qui permet de calculer le plus court ainsi que le plus rapide chemin entre deux noeuds (points), à l’aide de l’algorithme implémenté "Djikstra". 5 Planification Figure 1 – Le diagramme de Gantt prévisionnel Le stage a été subdivisé en trois parties : La première phase, qui s’est déroulée à Montpellier, était destinée à une mise à niveau et à l’initiation avec les outils de gestion des données spatiales (PostgreSQL/QGis), en suivant les cours de Mme Libourel ainsi que les TPs du module « base de données spatiales ». Ensuite, la deuxième partie, la plus importante, se passe à la station de SEAS-OI de Saint Pierre à l’île de la Réunion. Elle consiste, en premier lieu, à prendre en main et manipuler le framework PgRouting à l’aide de la documentation officielle en ligne. Puis à réaliser une étude sur les applications déjà disponibles et faire une comparaison bien détaillée entre chacune 19. https ://networkx.github.io/ 20. http ://grasswiki.osgeo.org/wiki/Vector-network-analysis 14
  15. 15. 6 MÉTHODOLOGIE d’elles, en mettant le point sur les avantages et les inconvénients de leurs différents services. Paral- lèlement, sont menées les étapes d’élaboration de la base de données des médecins généralistes et la mise en œuvre de la méthode de calcul d’isochrones avant de visualiser les résultats obtenus via le plugin QGis. Enfin, la troisième phase, de retour à Montpellier a pour but de finaliser le travail réalisé ainsi que la préparation pour la soutenance et mettre les dernières retouches et corrections sur le rapport, qui a été rédigé au fur et à mesure tout au long du stage. Si en théorie tel était le planning, je n’ai en réalité pas pu le suivre à la lettre étant donné que certaines étapes m’ont pris plus de temps que prévu initialement. J’ai néanmoins fait preuve d’esprit stratégique et ai réorganisé le travail de manière à garder un certain rythme sans déséquilibrer l’ensemble du projet. 6 Méthodologie Pour atteindre notre objectif, nous devions : • Réunir l’ensemble des données nécessaires : données liées aux structures sanitaires, et données routières de l’île de la Réunion et structurer celles-ci dans une base de données spatiale. • Présenter les outils nécessaires pour la partie base de données et visualisation spatiale. • Présenter les fonctionnalités de PgRouting. 6.1 Les données Pour les données "routières", afin d’être le plus exhaustif possible, nous avons utilisé OpenS- treetMap. De plus le format d’OSM est adapté à la vision graphe. OpensStreetMap : 21 OpenStreetMap est une initiative privée à but non lucratif visant à produire une cartographie vectorielle en libre-diffusion du monde entier et en particulier du réseau routier. Partie d’Angle- terre, OSM a désormais largement franchi les frontières et la qualité des données qui s’améliorent de manière spectaculaire depuis 2008. L’utilisation des moyens informatiques basés sur Internet permet l’intervention et la collaboration de tout utilisateur volontaire. Ces données sont librement redistribuables. Grâce à des outils de saisie très évolués, open source et l’effort des bénévoles, les données disponibles en France, notamment autour des principales agglomérations, sont désormais assez complètes. Les données sont échangées soit selon un modèle semi-structuré (format XML), soit sous format shapefile (format de fichier issu des SIG, devenu standard de facto et utilisé par un grand de nombre de logiciel libre dont QGis). Les données de l’île de la Réunion ont été téléchargées depuis un site web qui propose des mises à jour quotidiennes pour le réseau de l’île 22 . Les entités spatiales du modèle OpenStreetMap sont : Nœud (Node), Chemin (Way) et Relation. Le schéma UML ci dessous 21. http ://www.openstreetmap.org/ 22. http ://www.osm974.re/osm-shp/ 15
  16. 16. 6.2 Les outils de gestion et de visualisation des données spatiales 6 MÉTHODOLOGIE Figure 2 – Le diagramme UML du modèle OSM présente partiellement le modèle OpenStreetMap. Un nœud est caractérisé par un identifiant et sa localisation (latitude, longitude). Un chemin est un agrégat de nœuds (Un chemin peut être fermé si le nœud de départ correspond au nœud d’arrivée). Une relation est en fait un objet composite regroupant les trois types d’entités (nœud, chemin et relation), par exemple : Une commune peut être une entité relation avec un nœud correspondant à la mairie et un ensemble de nœud et de chemin donnant accès à la commune. Base de données Adresse IGN : 23 La BD adresse fournit une information en tout lieu pour positionner les données. Elle nous servira donc à la structuration des données liées aux médecins. Elle intègre les limites administratives et le réseau routier de la BD TOPO restreint à une géométrie en 2D et renseignée des noms de rues. Elle est disponible au format shapefile, MIF/MID, Geoconcept export, et utilise la projection Lambert- 93 en métropole et UTM en outre-mer. Elle est commercialisée, donc non diffusable. Nous les avons gratuitement dans le cadre de la recherche en partenariat avec l’IRD. 6.2 Les outils de gestion et de visualisation des données spatiales PostGreSQL/PostGis : 24 PostgreSQL est un des principaux système de gestion de base de données relationnelle et objet (SGBDRO) open source. Il est concurrent d’autres systèmes, qu’ils soient libre ( ex : MySQL) ou propriétaire (ex : Oracle, Sybase). Il est fondé sur une communauté mondiale de développeurs et d’entreprises. C’est un système très utilisé par plusieurs services du ministère et des instituts d’état. 23. http ://www.ign.fr/ 24. http ://www.postgresql.org/ 16
  17. 17. 6.3 PgRouting et ses fonctionnalités 6 MÉTHODOLOGIE PostgreSQL dispose d’une extension géographique PostGis. Cette extension permet le traitement des objets spatiaux dans les serveurs PostgreSQL (les at- tributs qui sont de type géométrique ou géographique), de manière à pouvoir les visualiser sous forme de couche dans un SIG (Système d’information Géographique), et pouvoir les manipuler à l’aide des requêtes spatiales. Pendant mon stage, j’ai utilisé la version 9.3 de PostgreSQL ainsi que la version 2.1 de PostGis. PgAdmin III : 25 PgAdmin III est un logiciel libre sous license PostgreSQL. Il sert comme interface graphique pour l’utilisateur afin de manipuler et travailler sur PostgreSQL. Pour réaliser ce projet, j’ai utilisé la version 1.18.1. Quantum Gis : 26 QGis ou Quantum Gis de son nom complet était destiné, à l’origine, à n’être qu’un outil de visua- lisation des données de GRASS (Geographic Resources Analysis Support System). Aujourd’hui, ce SIG généraliste est capable de lire et de modifier des données géographiques, de faire des analyses thématiques simples et les mettre en page. Le nombre de ses fonctionnalités font de lui un bon outil de SIG bureautique, proche de la plupart des standards payants et d’autant plus intéressant qu’il est multi-plateformes, compatible en lecture et en écriture avec de nombreux formats « classiques » de données géographiques. J’ai utilisé la version Valmiera 2.2. OSGéo Live : 27 OSGeo-Live est un DVD, une clé USB bootable ou une image disque virtuelle indépendante basée sur Xubuntu, qui permet d’essayer une large variété de logiciels opensource géospatiaux sans avoir à installer quoi que ce soit. Il repose entièrement sur des logiciels libres, ce qui permet de le redistribuer, dupliquer gratuitement et de le passer à n’importe qui. 6.3 PgRouting et ses fonctionnalités PgRouting 28 a été choisi comme outil de calcul du plus court chemin. Comme PostGis, PgRou- ting est une librairie de fonctions SQL qui constitue une extension de PostGreSQL/PostGis dédiée au routage géo-spatial. C’est un projet open source. Cette librairie travaille sur des graphes qui doivent être créés au préalable à partir des données du réseau routier. 25. http ://www.postgresql.org/ 26. http ://www.qgis.org/ 27. http ://live.osgeo.org/fr/ 28. http ://pgrouting.org 17
  18. 18. 6.3 PgRouting et ses fonctionnalités 6 MÉTHODOLOGIE Figure 3 – Lien entre PostgreSQL, PostGis, QGis et PgRouting PgRouting permet le calcul d’itinéraire ainsi que le temps de parcours. Il prend en considération tous les types de chemin : route, voie rapide, piéton ... En prenant en compte tous les différents aspects qui peuvent influencer sur le calcul de parcours ou de chemin (les feux, les restrictions, la pente ...). La nouveauté dans la version 2.0 c’est que le calcul est dynamique. Par exemple : si y a un accident ou une restriction sur une route ou un mauvais temps, il suffit juste d’ajuster le « coût » pour cette route en particulier et le calcul va vous proposer un autre chemin équivalent sans avoir à reconstruire tout le réseau routier. PgRouting peut être utilisé aussi pour différents types de réseau : sentiers de randonnée, canaux et rivières ou autre types de réseaux. Pgrouting inclut la solution pour le problème du voyageur de commerce (TSP), le calcul de distance de conduite (indique, pour chaque arc et chaque noeud du graphe, s’il peut être atteint en moins d’un temps donné, à partir d’un point (noeud) donné) et aussi l’implémentation de plusieurs algorithmes sur lesquels ils se base pour calculer le plus court chemin. Une application fréquente de ces algorithmes est par exemple le routage dans un réseau informatique, pour sélectionner les meilleurs chemins permettant d’acheminer des données. Plusieurs algorithmes courants de recherche du plus court chemin dans un graphe sont présentés ci-après : Dijkstra : En théorie des graphes, l’algorithme qui porte le nom de son inventeur, l’informaticien néerlan- dais Edsger Dijkstra, et a été publié en 1959 et sert à résoudre le problème du plus court chemin. Il s’applique à un graphe connexe dont le poids lié aux arêtes est un réel positif. Son principe est relativement simple, la première étape consiste à sélectionner le sommet de départ et à lui attribuer une distance de 0. Les sommets qui lui sont adjacents sont mis à jour avec une valeur égale au poids de l’arc qui les relie au sommet de départ (ou à celui de poids le plus faible si plusieurs arcs les relient) et les autres sommets conservent leur distance infinie. Le plus proche des sommets ad- jacents est alors ajouté au sous-graphe. La seconde étape consiste à mettre à jour les distances des sommets adjacents à ce dernier. Encore une fois, on recherche alors le sommet doté de la distance la plus faible. On l’ajoute au sous-graphe, puis on continue ainsi à partir du dernier sommet ajouté, 18
  19. 19. 6.3 PgRouting et ses fonctionnalités 6 MÉTHODOLOGIE jusqu’à épuisement des sommets ou jusqu’à sélection du sommet d’arrivée (extrait de Wikipedia Algorithme de Dijkstra) Une variante de l’algorithme de Dijkstra est l’algorithme de Dijkstra bidirectionnel : deux par- cours sont lancés simultanément depuis les points de départ et d’arrivée, et l’algorithme s’arrête lorsque les deux parcours de graphe se rencontrent au milieu. Cet algorithme est généralement plus rapide que l’utilisation simple de l’algorithme de Dijkstra. [Bon13] A* (A star) : L’algorithme de recherche A* est une extension de l’algorithme de Dijkstra de 1959 proposé pour la première fois par Peter E. Hart, Nils Nilsson et Bertram Raphael en 1968. C’est un algorithme de recherche de chemin dans un graphe entre un n ?ud initial et un n ?ud final tous deux donnés. De par sa simplicité il est souvent présenté comme exemple typique d’algorithme de planification, domaine de l’intelligence artificielle. L’algorithme A* a été créé pour que la première solution trouvée soit l’une des meilleures, c’est pourquoi il est célèbre dans des applications comme les jeux vidéo privilégiant la vitesse de calcul sur l’exactitude des résultats. A l’instar de l’algorithme de Dijkstra bidirectionnel, il est également possible d’utiliser l’algorithme A* de façon bidirectionnelle. (extrait de Wikipedia Algorithme A*) Shooting* (Shooting star) : L’algorithme Shooting* a été conçu pour calcul de plus court chemin pour les réseaux routiers réels avec prise en charge du sens giratoire, des feux et des routes à sens unique. Il est très recom- mandé pour les réseaux denses. Les fonctions sont écrites en PL/pgSQL, un langage permettant d’écrire des procédures Post- GreSQL, qui est facilement compréhensible. Au contraire, d’autres solutions intéressantes comme OSRM (cf. 5.2.4) sont écrites en C ou C++, langages relativement bas niveau plus difficiles à appréhender. Figure 4 – Processus de fonctionnement de PgRouting 19
  20. 20. 6.3 PgRouting et ses fonctionnalités 6 MÉTHODOLOGIE La communauté PgRouting est relativement dynamique : soutien de l’OSGéo, participation au Google Summer of Code, développement actif etc ... Ce qui garantit le développement de ce framework afin d’offrir beaucoup plus de fonctionnalités et améliorer celles déjà existantes. 20
  21. 21. 7 RÉALISATIONS 7 Réalisations 7.1 Données et Base de données Comme indiqué dans la section précédente, nous avons besoin des informations liées aux struc- tures sanitaires et au réseau routier. Nom Adresse Structure sanitaire Prénom Carte vitale {O/N} Honoraire Tel Complément adresse Médecin généraliste Tel Complément adresse Centre de soins Réseau routier Geométrie : Point Vertice Geometrie : Line Classe Longueur Nom Maxspeed (aller) Maxspeed (retour) Way1 source 1 target * * * * Figure 5 – Schéma conceptuel des données Dans ce schéma, deux types de structures sanitaires nous semblaient intéressantes : les médecins généralistes et les structures hospitalières. Pour les médecins, les données ont dû être vérifiées et complétées, car les données stockées dans la base relatives aux médecons vont provenir de deux sources : le site officiel de l’Assurance Maladie 29 , et la BD adresse de l’IGN. Pour les structures hospitalières les données proviennent d’un fichier shapefile issu de la base de données BDTOPO de l’IGN. Au niveau du réseau routier, la source est OpenStreetMap, les données récupérées au format OSM seront cependant traitées par le framework PgRouting, afin de stocker d’une part les vertices (noeuds carrefours) et les chemins. La base de données spatiale créée comportera donc quatre tables représentées dans le schéma ci-dessous : 29. http ://ameli-direct.ameli.fr/ 21
  22. 22. 7.1 Données et Base de données 7 RÉALISATIONS Nom Prénom Carte vitale {O/N} Honoraire Tel Num_voie Nom-Voie CP Ville Complément adresse Géometrie {calculée} Table Médecin généraliste id_Vertice : sequence Geométrie : Point Table Vertice Id-Way : integer Geometrie : Line Classe Longueur Nom Maxspeed (aller) Maxspeed (retour) Source {identifiant du vertice source} Target {identifiant du vertice target} Cost {coût de traversée} Reverse_cost {coût de traversée inverse} Table Way Nature {Hôpital, Centre Hospitalier} Origine Importance Géométrie Table Centre de soins Figure 6 – Schéma relationnel des données Les diverses commandes nécessaires pour la création de la base et l’ajout de l’extension Postgis à Postgres sont : # login as user "postgres" psql -U postgres # create routing database CREATE DATABASE routing; # Connect to database c routing # Add Postgis functions CREATE EXTENSION postgis; 7.1.1 Médecins généralistes Comme il a été précisé dans le paragraphe précédent, toutes les informations concernant les médecins ont été extraites du site de l’Assurance Maladie. Ces données ont été saisies à la main et ne respectent pas certaines normes suivies par celles de la BD Adresse de l’IGN (qui est la référence). 22
  23. 23. 7.1 Données et Base de données 7 RÉALISATIONS Figure 7 – Aperçu de la page d’AMELI Un prétraitement de ces données était nécessaire. Il consiste à réécrire les adresses afin qu’elles soient identiques à celle de la BD Adresse. Soit en éliminant les espaces inutiles, les doublons, en réécrivant les numéros en chiffre standard, en utilisant les abréviations .. Nom Abréviation ALLE ALL CHEMIN CHE RUE R BOULEVARD BD ROUTE RTE PLACE PL VOIE VOI Ensuite l’étape suivante est relative à la création et au calcul de l’attribut géométrique the_geom de la table médecins. Pour cela, nous avons réalisé la jointure entre les deux tables med (table des médecins initiale, données site Ameli) et la table bdadr table adresse issue de base BD Adresse IGN à partir des champs qui constituent l’adresse (numero, nom-voie, rep et code-post). La requête SQL de jointure est la suivante : CREATE TABLE medadr AS 23
  24. 24. 7.1 Données et Base de données 7 RÉALISATIONS (SELECT med.id_med, med.nom, med.prenom, med.honoraire, med.carte_vitale, med.tel, med.numero, med.nom_voie, bdadr.rep, med.ville, med.code_post, bdadr.type_loc, geom FROM med, bdadr WHERE med.numero=bdadr.numero AND med.rep=bdadr.rep AND med.code_post=bdadr.code_post AND med.nom_voie=bdadr.nom_voie ORDER BY med.nom ); On peut à ce stade visualiser la carte superposant la vision générale de l’ile (obtenue à partir du plugin OpenLayers en utilisant une couche OpenStreetMap) et les données de la table Médecins (cf. figure 8). Figure 8 – Carte des médecins généralistes dans l’île de la Réunion 24
  25. 25. 7.1 Données et Base de données 7 RÉALISATIONS 7.1.2 Centre de soins Pour les structures sanitaires, nous avons récupéré les donnés relatives aux centres de soins. Nous disposons d’un fichier shapefile qui contient toutes les informations sur les centres de soins de l’île qui nous a était communiqué par l’IGN, que l’on peut visualiser sur QGis. Ensuite, on importe ces données grâce au l’outil (plugin) SPIT (Shapefile to PostGIS Import Tool ou outil d’import Shapefile vers PostGIS) disponible dans les extensions de QGis. Il suffit de spécifier le le chemin du fichier .shp et indiquer la base de données dont laquelle la table doit être stockée, en précisant la projection SRID 32740. Nous pouvons visualiser comme précédemment, la superposition de la vision générale de l’ile et des données centre de soins (cf. figure 9). Figure 9 – Cartes des centres de soins de la Réunion La visualisation des ces deux tables nous permet une première remarque : les médecins sont bien présents dans les principales localités de l’ile et sur le pourtour de l’ile et ponctuellement dans la zone de Cilao, les centres de soins sont aussi présents dans les principales localités mais aussi au niveau de la région centrale (Mafate, Cilaos) cependant aucun médecin libéral dans le secteur Mafate. 25
  26. 26. 7.2 Installation de PgRouting et ses fonctions 7 RÉALISATIONS 7.2 Installation de PgRouting et ses fonctions 7.2.1 Installation de PgRouting Comme c’est mentionné dans la partie 6.2, OSG Géo Live dispose déjà de tous les logiciels open source (libres) géospatiaux, y compris PgRouting et toutes ses fonctionnalités. Pour l’installation sur Ubuntu, il suffit d’exécuter la commande suivante : # Install pgRouting packages sudo apt-get install postgresql-9.3-pgrouting Ensuite, vient l’étape d’ajout des fonctions PgRouting à la base de donnée créée en tant qu’uti- lisateur postgres. # login as user "postgres" psql -U postgres # Connect to database c routing # Add PgRouting functions CREATE EXTENSION pgrouting; L’importation des données à partir du fichier OpenStreetMap (.osm) (que l’on a déjà téléchargé) vers PostgreSQL s’effectue à l’aide de l’outil osm2pgrouting. La commande suivante permet d’ins- taller ce dernier et ajouter toutes les fonctions nécessaires : # Install osm2pgrouting package sudo apt-get install osm2pgrouting Un fichier XML .osm nous rappelons contient trois types de données majeurs : • nœuds • chemins • relations osm2pgrouting construit le réseau routier automatiquement et crée les tables suivantes : Types (définition de grands types de voies), Classes ( définition des diverses caractéristiques des voies) , Nodes (point défini par latitude, longitude), Vertices (noeud du réseau) et Ways (arcs du réseau). 26
  27. 27. 7.2 Installation de PgRouting et ses fonctions 7 RÉALISATIONS Figure 10 – Modéle du graphe construit par PgRouting Lors de l’utilisation d’osm2pgrouting, le fichier mapconfig.xml permet de préciser le fait que l’utilisateur souhaite conserver uniquement les nœuds et les chemins ayant pour types et classes celles stipulées dans qui seront importées dans notre base de données routing : osm2pgrouting -file "notre-fichier.osm" -conf "/usr/share/osm2pgrouting/mapconfig.xml" -dbname routing -user postgres -clean L’exécution de la commande osm2pgrouting peut prendre un peu de temps selon la taille du fichier OSM. Une fois celle-ci terminée, on peut visualiser le résultat à l’aide de l’interface PgAdmin 27
  28. 28. 7.2 Installation de PgRouting et ses fonctions 7 RÉALISATIONS III, afin de bien vérifier la création des tables dans notre base de données. Une fois que les données sont enregistrées, il reste encore une étape afin de créer la topologie du réseau. Pour cela, il faut ajouter dans la table « ways » deux colonnes (source et target) afin de pouvoir exécuter la fonction pgr_createTopologyqui permet de créer une topologie de notre réseau. Pour cela, on utilise la fonction : assign_vertex_id(’<table>’, float tolerance, ’<geometry column>’, ’<gid>’) # Ajouter les colonnes "source" et "target" ALTER TABLE ways ADD COLUMN "source" integer; ALTER TABLE ways ADD COLUMN "target" integer; # Utiliser la fonction de contruction de topologie SELECT assign_vertex_id(’ways’, 0.00001, ’the_geom’, ’gid’); Arrivé à cette phase, on peut visualiser nos tables « ways »(arcs) et « vertices » (nœuds) à l’aide du logiciel QGis, car chacune dispose d’une géométrie stockée dans un attribut spécifique (the_geom). Figure 11 – Réseau routier de l’île de la Réunion 28
  29. 29. 7.2 Installation de PgRouting et ses fonctions 7 RÉALISATIONS Figure 12 – Réseau de points (noeuds) de l’île de la Réunion 7.2.2 Principales fonctions de PgRouting Dans cette partie, on présente toutes les fonctions qu’on a utilisé pour la réalisation de ce projet. Ainsi que toutes les configurations et les spécifications définies pour nos données. PgRouting dispose de plusieurs algorithmes (6.3). On ne s’intéressera qu’aux deux fonctions qu’on a utilisé : Djikstra et DrivingDistance. La fonction pgr_dijkstra calcule le plus court chemin entre deux points Fonction pgr_dijkstra : pgr_dijkstra (text sql, integer source, integer target, boolean directed, boolean has_rcost); Elle peut être utilisée sur des graphes orientés ou non. Si le graphe est orienté, Il est possible de spécifier que le réseau a, en sus d’un coût de parcours direct (to_cost)un coût de parcours inverse (reverse_cost) ou non. Pour cela, il faut ajouter une colonne dans la table ways . ALTER TABLE ways ADD COLUMN reverse_cost double precision; La fonction nécessite une requête sql text relative à la table ways et à ses attributs source et target, id et length, l’entier source correspondant à l’id du nœud de départ choisi, l’entier target 29
  30. 30. 7.3 Isochrones 7 RÉALISATIONS correspondant à l’id du nœud destination choisi et deux booléens directed vrai si le graphe est orienté, has_rcost utilisant le coût de traversée inverse. Exemple : Calcul du plus court chemin entre le nœud 1 et le nœud 5110, graphe non orienté SELECT seq, id1 as node, id2 as edge, cost, b.the_geom FROM pgr_dijkstra(’ SELECT gid AS id, source::integer AS source, target::integer AS target, length::double precision AS cost FROM ways’, 1, % Noeud du départ 5110, % Noeud d’arrivée false, false) a LEFT JOIN ways b ON (a.id2 = b.gid); La deuxième fonction pgr_drivingdistance calcule les points accessibles à la distance d donnée à partir d’un point donné. Fonction pgr_drivingdistance : pgr_drivingDistance( sql text, source integer, distance double precision, directed boolean, has_cost boolen) ; La fonction nécessite une requête sql text relative à la table ways et à ses attributs source et target, id et length, l’entier source correspondant à l’id du nœud de départ choisi, le réel distance correspondant à la distance d voulue en km et deux booléens directed vrai si le graphe est orienté, has_cost utilisant le coût de traversée inverse. Exemple : calcul de l’ensemble des points situés à 10km du point 1203 SELECT id, id1 AS node, id2 AS edge, cost, the_geom FROM pgr_drivingdistance(’SELECT gid as id, source, target, length as cost FROM ways’, 1203, % Noeud de départ 12.5,% Distance de parcours pour 15 mn false, false) as di JOIN vertices_tmp pt ON di.id1 = pt.id); 7.3 Isochrones Les isochrones permettent de représenter graphiquement les temps d’accès à des endroits sur une carte, et de comparer les différents modes de déplacements dans un lieu donné en délimitant les points accessibles par un véhicule (terrestre ou aérien), un piéton .. en un temps donné. 7.3.1 Calcul sur réseau initial Pour exécuter les fonctions de PgRouting, il est obligatoire que les nœuds de départ (source) et d’arrivée (target) soient sur le chemin routier. Alors que les adresses des médecins généralistes ainsi que les constructions sanitaires (centres de soin), ne figurent pas forcément sur le réseau routier, et ne font donc pas forcément partie du graphe, comme le montre l’image suivante. 30
  31. 31. 7.3 Isochrones 7 RÉALISATIONS Pour résoudre ce problème, il faut calculer dans un premier temps, le(s) point(s) du réseau les plus proches du point correspondant au médecin ou au centre de soin ensuite créer l’arc (les arcs) obtenus (entre point réseau et point médecin ou centre de soin), afin d’enrichir le réseau. Dans un premier temps, nous avons pris l’hypothèse simplificatrice qui consiste à remplacer chacun des points adresses (médecins, centres de soin) par le nœud le proche proche qui appartient au réseau et le considérer en tant que point de départ pour nos calculs. Algorithme de calcul des noeuds les plus proches dans le cas des médecins Entrée : Table des noeuds du réseau, table des points médecins (770 points) Sortie : Tables des points les plus proche aux médecins Début Ajouter une colonne dans la table médecin : nearest_node Pour tous les enregistrements de la table médecin faire Calculer min(ST_distance(medecin.the_geom,vertices.the_geom) Récupérer l’id du noeud avec la distance la plus courte Insérer l’id du noeud dans la table médecin Fin Créer une table Node_tom avec tous les points récupérés (770 noeuds) Fin L’exécution de cet algorithme permet de créer la table des points-réseau les plus proches des médecins que l’on pourra visualiser sur QGis, vu qu’elle contient l’attribut géométrique qu’on a récupéré de la table vertices. A ce stade, on peut effectuer les calculs d’isochrone en considérant que les points de départ (médecin) sont nearest_node dans la table des médecins. Pour tracer des isochrones de 5, 10, 15 mn le calcul de pgr_drivingDistance se fera avec des distances évaluées selon la vitesse de parcours (nous considérons la vitesse d’un véhicule par défaut 50km/h) soit 4,17 km, 8,33 km et 12,5km Le calcul général est présenté dans l’annexe 9.1. 31
  32. 32. 7.3 Isochrones 7 RÉALISATIONS 7.3.2 Calcul sur réseau étendu L’idée est d’enrichir le réseau initial en découpant le territoire en pixels réguliers et en ajoutant les segments reliant le centroïde de ces pixels au point le plus proche du réseau initial. Pour celà on crée grâce aux outils Vecteur de Qgis une grille de pixel de 10 km de côté et les centroïdes de chaque pixel et on sauvegarde le fichier shapefile obtenu dans la base de données. Ensuite on calcule les proches voisins du réseau routier pour chaque centroïde. Il ne reste qu’à créer les segments liant chaque centroide et son voisin le plus proche et les stocker dans une table segment de géométrie Linestring. L’étape suivante consiste à insérer les centroïdes dans la table vertices et les considérer comme des nouveaux nœuds du réseau, et insérer les segments dans ways. Tout en gardant la cohérence et la compatibilité des données ajoutées avec celles déjà existantes, et en respectant toutes les contraintes de la base de données. 30 . Une fois toutes ces instructions effectuées, la méthode de calcul d’isochrones peut s’appliquer sur le nouveau réseau routier étendu. Figure 13 – Modélisation du réseau étendu 30. Un travail complémentaire a consisté à supprimer tous les segments ayant comme extrémité un centroïde situé hors du territoire terrestre de l’ile 32
  33. 33. 7.4 Visualisations des résultats 7 RÉALISATIONS 7.4 Visualisations des résultats Cette partie sera dédiée à la visualisation des cartes isochrones diverses. On peut visualiser le résultat du calcul des isochrones avec 2 méthodes : 7.4.1 Méthode de coloration « Graduée » : Il suffit d’ajouter la table résultante du calcul d’isochrones sur QGis, puis de modifier les propriétés de la couche de points obtenus, en appliquant le mode gradué sur la colonne « cost ». Ce qui peut être visualisable comme ci-dessous : Figure 14 – Carte isochrone avec un temps de parcours entre 0 et 15 min d’un médecin 7.4.2 Méthode avec le plugin « Contour » Le plugin « Contour » est disponible dans les extensions de QGis. Il permet de générer un nombre fixé de contours (isolignes) et / ou des polygones de contours précédents à partir des informations de la table résultante du calcul d’isochrones et de son attribut cost. 33
  34. 34. 7.4 Visualisations des résultats 7 RÉALISATIONS Figure 15 – Boite de dialogue du plugin Contour On peut visualiser le résultat sous la forme suivante : Figure 16 – Carte isochrone avec un temps de parcours entre 0 et 15 min d’un médecin, en utilisant Contour 34
  35. 35. 7.4 Visualisations des résultats 7 RÉALISATIONS 7.4.3 Isochrones obtenues Isochrone réseau initial La carte isochrone avec un temps de parcours entre 0 et 15 minutes, à partir d’un médecin généraliste sur le réseau routier initial : Figure 16. La carte isochrone avec un temps de parcours entre 0 et 15 minutes, à partir d’une construction sanitaire sur le réseau routier initial : Figure 17 – Carte isochrone avec un temps de parcours entre 0 et 15 minutes d’un hôpital, réseau initial Isochrone réseau étendu La carte isochrone avec un temps de parcours entre 0 et 15 minutes, à partir d’un médecin généraliste sur le réseau routier étendu : 35
  36. 36. 7.4 Visualisations des résultats 7 RÉALISATIONS Figure 18 – Carte isochrone avec un temps de parcours entre 0 et 15 minutes d’un médecin, réseau étendu La carte isochrone avec un temps de parcours entre 0 et 15 minutes, à partir d’une construction sanitaire sur le réseau routier étendu : 36
  37. 37. 7.4 Visualisations des résultats 7 RÉALISATIONS Figure 19 – Carte isochrone avec un temps de parcours entre 0 et 15 minutes d’un centre de soin, réseau étendu La carte isochrone avec un temps de parcours entre 0 et 15 mn d’un centroïde de la grille .. ou de tous superposée avec les médecins puis avec les centres de soin. 37
  38. 38. 8 CONCLUSION ET PERSPECTIVES 8 Conclusion et Perspectives Ce travail a permis de développer une méthode pour mesurer les temps de parcours vers l’offre de soins, ce qui caractérise l’accessibilité aux soins. Cette méthode pourra être appliquée de la même façon pour calculer les distances à un aléa sanitaire (par exemple, un lieu identifié comme propice à la leptospirose). Le choix de travailler sur l’offre de soins s’est fait avec les encadrants et nous avons maintenu le titre puisque cela implique les mêmes méthodes. Les cartes et les algorithmes fournis constituent donc un premier apport. Les tracés d’isochrones obtenus pourraient être affinés d’une part en ajustant le réseau étendu avec une grille de pixels plus précis (1km) et d’autre part en prenant en compte la topologie de l’île (par exemple à partir d’un modèle numérique de terrain) ce qui nous permettrait de moduler les vitesses. Pour l’instant nous n’avons raisonné que sur des déplacement effectués par des véhicules de vitesse moyenne 50km/h. Il serait judicieux de traiter aussi les autres modes de déplacements. De plus des renseignements sur la population et ses taux de concentration seraient un plus pour affiner l’analyse. Sur le plan technique, le sujet de stage a porté essentiellement sur les bases de données et les traitements spatiaux avec les SIG (QGis). Les diverses procédures mises en oeuvre peuvent aisément être génériques et donc réutilisables dans divers contextes. Sur le plan personnel, ce stage m’a offert la possibilité d’acquérir et d’approfondir des connais- sances sur le monde de la Géomatique. Cela m’a aussi permis d’acquérir et d’enrichir mes compé- tences de travail sur les bases de données spatiales sous PostgreSQL/Postgis et de manipuler aussi des outils (PgRouting) que j’ignorais auparavant. Il faut enfin noter que beaucoup de détails restent souvent à élucider dans les documentations en ligne (Pgrouting a, par de nombreux points, un côté un peu « boite noire »). 38
  39. 39. 9 ANNEXES 9 Annexes 9.1 Principe de la méthode de calcul des Isochrones Ci dessous le code exemple pour le calcul des isochrones à partir de la table médecin et du réseau stocké dans la table ways pour une distance de 12.5 km (temps de parcours 15 mn) # D’abord, il faut créer la table intermédiaire "time_frommed" # qui stockera le résultat de l’exécution de la fonction isochrone () CREATE TABLE time_frommed ( id integer, node integer, edge integer, cost double precision, the_geom geometry(Point,32740) ) # Ensuite créer la fonction avec la boucle sur tous les médecins virtuels CREATE OR REPLACE FUNCTION isochrone() RETURNS VOID AS $BODY$ DECLARE i RECORD; BEGIN FOR i IN SELECT nearest_node FROM medecin_adr LOOP INSERT INTO time_frommed (SELECT id, id1 AS node, id2 AS edge, cost, the_geom FROM pgr_drivingdistance(’SELECT gid as id, source, target, length as cost FROM ways’, i.nearest_node, 12.5, % Distance équivalente à celle parcourue en 15 min false, false) as di JOIN vertices_tmp pt ON di.id1 = pt.id); END LOOP; RETURN; END; $BODY$ Language ’plpgsql’; # Une fois la fonction créée, elle peut s’exécuter via la commande 39
  40. 40. 9.1 Principe de la méthode de calcul des Isochrones 9 ANNEXES SELECT isochrone(); # Enfin, création de la table "isochrone_medecin_final" afin de récupérer # la valeur minimale de la distance parcourue pour chaque médecin CREATE table isochrone_medecin_final AS SELECT id, the_geom, min (cost) AS cost FROM time_frommed GROUP By id, the_geom; La méthode générique pourrait facilement être concue comme l’exécution d’un script Isochrone(table_origine, table_reseau,t, v) avec table_origine celle de la base contenant les points centres des isochrones, table_reseau celle de la base contenant le réseau choisi, t la valeur du temps de parcours, v valeur de la vitesse) 40
  41. 41. RÉFÉRENCES RÉFÉRENCES Références [COMA10] Coquel et Mazeran, Conception d’un démonstrateur d’analyse géographique des réseaux de voirie et transports collectifs d’Aix en Provence, 2010 [BARetal12] Barlet M., Coldefy M., Collin C., Lucas-Gabrielli V., L’Accessibilité potentielle locali- sée (APL) : une nouvelle mesure de l’accessibilité aux soins appliquée aux médecins généralistes libéraux en France, 2012 [RAPPORT CREDES] Collectif, Territoires et accès aux soins, 2013 [Bon13] Bonifas Frédéric, MooWalkR : conception et réalisation d’une application de calculs d’iti- néraires adaptés aux piétons, Mémoire master Géomatique. [SANTE] Denise Bauer et Nathalie Goyaux, Santé est accès aux soins, Groupe de travail, 2012 [1] Dropbox est un service de stockage et de partage de copies de fichiers locaux en ligne. dropbox.com [2] Documentation officielle postgresql.org [3] Documentation officielle pgrouting.org [4] Documentation officielle qgis.com [5] Stackoverflow : la plus grande communauté d’entraide informatique du web. Bon nombre de nos questions y trouvaient leurs réponses. gis.stackexchange.com [6] Forum personnel d’Anita GRASER, experte en SIG, exposant tous ses travaux dans le domaine de routage et des traitements spatiaux http://anitagraser.com 41

×