rapport_stage_issame

Académie de Montpellier
Université Montpellier II
Sciences et Techniques du Languedoc
RAPPORT DE STAGE MASTER 2
Eﬀectué à : 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

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 scientiﬁque 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 Planiﬁcation 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

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

Avant propos
« Agir d’abord, rectiﬁer 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

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

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

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

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

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

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

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

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

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

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 Planiﬁcation
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 oﬃcielle 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

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

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

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 aﬁn 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 modiﬁer 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

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

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

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 aﬁn d’oﬀrir beaucoup plus de fonctionnalités et améliorer celles déjà existantes.
20

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

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 {identiﬁant du vertice source}
Target {identiﬁant 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

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 aﬁn qu’elles
soient identiques à celle de la BD Adresse. Soit en éliminant les espaces inutiles, les doublons, en
réécrivant les numéros en chiﬀre 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

(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. ﬁgure 8).
Figure 8 – Carte des médecins généralistes dans l’île de la Réunion
24

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

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

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

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

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

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 diﬀé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 ﬁgurent 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

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

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

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

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

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

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

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

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

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

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

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

rapport_stage_issame

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie rapport_stage_issame

Ähnlich wie rapport_stage_issame (20)

rapport_stage_issame