Introduction

Depuis quelques temps maintenant, je voulais faire un projet perso sur l'une de mes passions, la géomatique. Travaillant récemment avec un algorithme servant à créer des Polygones de Voronoï, cela m'a donné une idée, faire une carte de proximité à l'aide de ces derniers, tout en se servant d'un Path Finding.

Aimant bien aussi la randonnée, je voulais partir sur quelque chose en lien avec cette autre passion, mais qui n'était pas quelque chose de commercial, (tout en étant accessible en open-source ... A revoir). L'idée à la base était donc de partir sur une "guerre des bancs" (Trouver quels étaient les bancs les plus accessibles au plus grand nombre de personnes). Néanmoins, du fait qu'il y a énormément de bancs, j'ai décidé de prendre un autre élément non commercial ... les points d'eau.

En cherchant différentes EPCI, sur laquelle faire cette étude, je me suis finalement arrêté sur celle de la Communauté de Communes de la Station des Rousses-Haut Jura, dans le Jura. Si vous vous posez la question, pourquoi cette dernière et voici les différents points qui m'ont motivé à la choisir :

• Faible nombre de points d'eau (4), cela permettra de faire une carte, nettement plus lisible.
• Relativement faible population (Avec 7212 habitants en 2021, c'était la 2ème EPCI la moins peuplée du département et au niveau national (Hors DROM-COM), elle se classait à la 1121ème place sur 1231) et étendue (Avec presque 99km², elle était la plus petite EPCI de son département et la 1188 moins étendue de France Métropolitaine (sur 1236)), cela limite son nombre de routes, donc temps de calcul
• Le Jura est un département relativement rural et réputé pour la randonnée, cela rentrait parfaitement dans le sujet et cela permet aussi de mettre en valeur un territoire rural
• Point Bonus : EPCI frontalière avec un autre pays.
• Point Bonus 2 : A fait partie d’un film récemment passé au cinéma (Un Ours dans le Jura).
• Point Bonus 3 : Il y a la principauté d'Arbézie en partie sur le territoire.

Ci-dessous, une carte de localisation de l'EPCI :

Les données

Comme vous avez pu le voir, sur la carte, l'EPCI ne comporte que quatre villes (Ce qui est relativement rare en France (En 2024, cela concernait 7 avec 4 villes ou moins, donc 2 avec seulement 3 communes) et se concentre surtout autour de son siège, la ville des Rousses (Qui regroupe un peu plus de la moitié des habitants, avec 3683 habitants), connue pour être une station de sport d'Hiver. Etant dans le Jura, cette communauté de communes est contrastée par son relief. Son point le plus bas est à 720 mètres (Dans la commune des Rousses) et son plus haut, est quant à lui à 1495m (Commune de Lamoura, avec le Crêt Pela).

Une fois ce choix d'EPCI fait, avec l'aide de l'API d'Open Street Map, j'ai téléchargé les différentes données liées aux routes et points d'eau des communes comprises de cette communauté de communes. Ce qui faisait en tout 4 points d'eau et 2308 éléments pour les routes. Du fait que pas mal de routes n'avaient pas de valeurs "highspeed" (Et que cela m'intéressait particulièrement, du fait que le futur Path Finding sera pondéré selon cette valeur), j'ai dû faire des modifications dans les données téléchargées pour qu'elles aient une valeur. Voici au final ce que cela donne :

Et avec deux cartes, c'est encore mieux :

◀

▶

1 / 2

D'abord la première chose que l'on peut voir cette carte, c'est qu'il y a deux points d'eau sur la même commune, celle de Bois d'Amont, cela est un cas plutôt intéressant je trouve, puisque cela va rajouter un peu de concurrence.

Ensuite sur les routes, on peut noter différents points :

• Réseau assez logique entre les villes de l'EPCI, avec des voies relativement rapides (> 50 km/h en majorité) et qui s'articulent surtout autour de la commune la plus peuplée de la Communauté de Communes
• Hors des villes, cela est plutôt l'inverse avec beaucoup de routes à 30km/h (D'ailleurs elles représentent 72% du réseau routier)
• Plusieurs axes parallèles (D25 / N5 - D29E2 / D415) pouvant faire jouer la concurrence

La géométrie

Une fois que l’on a toutes ces données, il faut les formater afin qu’elle puisse être utilisées pour pouvoir utiliser un algorithme de path-finding, du fait qu’en les parcourant, je me suis aperçu d’un petit problème. Et avec des schémas, c’est plus sympathique donc voici :

Avec nos différentes routes, on a donc 3 possibles cas qui s’offrent à nous :

• Le premier, est celui qui nous plaît le plus, du fait que les 3 chemins se finissent au niveau du même point, donc cela permet à l’algorithme de passer directement d’un chemin à un autre sans le sauter.
• Le second, légèrement plus problématique, mais assez facile à gérer est relativement proche du premier, mais il n’y a pas de liaison entre nos différentes « sections », mais on a quand même un élément qui peut faire la jonction entre nos deux routes. Il faudra donc juste split notre route au niveau de ce point, afin de revenir à une situation relative à notre premier schéma.
• Quant au troisième, c’est le plus problématique pour nous du fait qu’ici, aucun élément ne nous permet de faire la jonction entre nos deux routes. Il faudra donc en créer un, en se basant sur la géométrie de nos éléments.

La question maintenant est … qu’est ce qu’on fait pour gérer cela ?

Dans un premier temps, j’ai parcouru toutes nos routes, afin de prendre tous les points qui les composent et de les rendre uniques et supprimer les doublons (Pour faire cela, j’ai choisi de prendre une tolérance de 1 mètre). Une fois cela fait, j’ai encore une fois parcouru toutes les routes, pour extraire toutes leurs sections, en leur donnant ainsi, une origine et une extrémité avec l’ID de l’un de nos points uniques précédemment créés (tout en gardant l’ID de la route à la base, ces sections appartenaient). Après cela, j’ai reconstruit mes différentes routes, en m’aidant de mes sections, mais en m’arrêtant à chaque point, qui se retrouvait à la limite d’au moins trois sections.

En conséquence, le cas numéro 2 de notre schéma était maintenant réglé, maintenant il va falloir s’attaquer à notre fameux numéro 3 … mais avant un petit schéma représentant l'étape qui vient d'être faite :

Concernant ce troisième et dernier cas, la première tâche va être de savoir comment joindre ces points à leurs nouvelles lignes ? Dans un premier temps, un tri va être fait, en suivant cette méthodologie, afin d’éliminer une par une les relations points / routes, tout en limitant au maximum le temps de traitement :

• La distance du point avec le centroïde de la route, doit être inférieure à la moitié de la longueur de la route.
• Les coordonnées du point doivent être inférieures aux XMax / YMax de la route et supérieures aux XMin / YMin.
• Le point doit se trouver dans la boîte englobante de la route.
• La distance perpendiculaire du point à la route doit être de mois d’un mètre.

Une fois que l’on a fait cela, il suffit de modifier notre route, en créant un nouveau point où il y a le fameux croisement et de split la route en deux.

Pour information, en termes de nombre de routes, on passe de :

• 2276 routes après téléchargement de données de OSM.
• 34019 sections après le découpage à chaque noeud.
• 6364 routes, une fois que l'on a fait le regroupement des sections d'une même route, mais en les splitant dès que leur noeud rencontre 2 autres sections.
• 6988 routes, après avoir traité le cas numéro 3.

Une fois que tous ces pré-traitements ont été réalisés, on peut s'attaquer maintenant au coeur du sujet, le Path-Finding et la construction de nos zones d'influence.

Path-Finding et Voronoï

Dans un premier temps, du fait que notre algo de path-finding va se servir à la fois de la maxspeed de nos routes et de la longueur de ces dernières. Il faut calculer une valeur de temps de trajet pour chacune de nos routes, à l'aide de cette superbe formule :

Une fois que l'on a cette dernière variable, il faut maintenant calculer pour tous nos différents points d'eau, quel noeud de nos routes est le plus proche. Ensuite, on crée un graphique avec tous nos tronçons et enfin, on lance notre algo de path finding en mettant comme valeur de poids, celle que l'on vient de calculer. Bien entendu, pour chacun de nos noeuds, on lance l'algo 4 fois (une fois par point d'eau) et on garde la valeur la plus faible, pour déterminer quel est le point d'eau le plus proche de notre noeud.

Une fois que l'on a toutes ces valeurs. A partir de nos différents points, on calcule nos fameux polygones de Voronoï, tout en les limitant leur expansion à la superficie de notre EPCI. Quand ces polygones sont créés, on fait une jointure spatiale avec nos points, pour savoir à quel point d'eau, notre polygone appartient et enfin, on merge tous nos polygones suivant leur valeur d'appartenance, afin d'avoir les fameuses zones d'influences de nos points d'eau, ce qui nous donne cette carte :

De cet export, on peut déjà tirer plusieurs conclusions :

• Il n'y a pas vraiment eu de concurrence entres les points numéro 2 et 3, puisqu'ils étaient beaucoup trop proches pour que cela n'ait lieu et le 2 a pris toute la priorité sur le 3.
• Le point numéro 4 a su le mieux se développer, du fait qu'il n'y a aucun autre point d'eau au Sud, sur la commune de Lamoura, néanmoins, il a eu d'avantage de concurrence avec le 1, particulièrement au Sud et un peu moins au Nord.
• Enfin le point numéro 1 a su plutôt bien tirer des avantages de sa centralité.

Quelques cartes en plus :

Et voici quelques cartes, pour encore mieux décrire la situation à la fin de cette étude :

◀

▶

1 / 4

Ces différentes cartes peuvent bien entendu, nous éclairer encore un peu plus sur la situation.

• La première carte montre le temps d'accès aux points d'eau depuis les différents noeuds, le tout regroupé en cluster. Et on peut voir que plus on s'éloigne de nos axes principaux, plus le temps augmente assez rapidement. Cela est d'ailleurs le cas pour la zone au Sud entre les points 1/4, car malgré une concurrence assez forte entre ces deux points, le temps pour accéder au point d'eau est relativement important, du fait que les routes ne sont pas vraiment directes. L'autre élément que l'on peut distinguer, est le cas de la commune de Lamoura, du fait qu'elle n'a pas de point d'eau sur son territoire et que le plus proche est celui de la commune de Preymanon, l'ensemble de son territoire a des valeurs relativement importantes.
• La seconde présente le nombre minimal d'occurences (par route) de chaque noeud dans le Path Finding. Plus une valeur est importante, plus elle a donc à servi à étendre l'influence du point d'eau, auquel le noeud est rattaché. Sans surprise, les routes aux alentours du point d'eau numéro 3 ont des valeurs très faibles. Concernant les autres, on peut voir que le point numéro 3, a su plutôt étendre son territoire à l'aide d'un réseau en étoile, ce qui est plutôt logique du fait que la commune des Rousses est à la fois le siège de l'EPCI, mais aussi sa commune la peuplée, donc celle qui est le mieux reliée au réseau routier. Quant au point numéro 4, du fait que c'est le point avec la plus grande d'influence, rien de surprenant à ce que ses routes aient été utilisées le plus grand nombre de fois et l'axe majoritaire est celui qui va vers la commune de Laomura.
• Enfin la troisième carte, elle sert à montrer la différence entre un algo de path finding, basé sur une variable de temps (comme vu plus haut) et un autre basé uniquement sur la longueur des routes, donc quelle que soit la vitesse à laquelle on se déplace dessus, tant qu'elle est homogène entre toutes les routes. La première chose dont on peut s'apercevoir ... c'est qu'il n'y a pas une grande différence ... mis à part pour le point 1, qui a su mieux tirer son épingle du jeu grâce à sa place centrale dans l'EPCI et sa proximité avec des routes avec une valeur relativement élevée.
• Quant à la dernière carte, elle sert à montrer la différence entre un algo pondéré par des valeurs (et avec path finding avant) et un algo de Voronoï se basant uniquement sur la position des points d'eau, et les différentes entre les deux cartes sont flagrantes.

Ouverture / Critique

Voici quelques critiques / ouvertures qui permettent d'aller un peu plus loin dans cette étude :

• Jointure entre lignes : Créer des liens entre tous les éléments se croisant, sans vérifier. Cela peut fausser les relations, par exemple : un pont piéton passant par dessus une autoroute
• Calcul de la vitesse maximum sur les routes : Vu que cela a été fait, en se basant essentiellement sur des vitesses théoriques (Ex : Pour les chemins) et/ou sur des panneaux de limitation sur Google Street View, cette valeur a quand même une forte probabilité d'être fausse. Le mieux aurait été de se baser sur des valeurs officielles
• Relation Point / Route Cas numéro 4 : Je n'ai pas traité un cas (Lorsque j'ai fait le lien entre mes différentes routes), c'en est un qui se rapproche relativement du cas numéro 3, ce sont les points relativements proches, mais pas directement ou à moins d'un mètre d'une route déjà existante. Je ne l'ai pas fait, puisque c'était beaucoup plus difficile à faire que ce que j'ai déjà fait et nécessitait une vérification pour chaque point, au vu de la problématique.
• Les relations extérieures : Je n'ai pas vraiment pris en compte, les relations de l'EPCI avec son extérieur (par exemple, routes sortant de mon EPCI et y rentrant après / Influence d'autres points d'eaux proches)
• Le relief : Etant donné qu'on est au milieu d'un massif montagneux, le Jura, cela aurait pu être intéressant de prendre en compte le dénivelé de la route, du fait que cela jouerait un peu sur les temps. Idem pour les virages ...
• Les éléments liés aux routes : Un autre facteur pouvant impacter sur le temps, sont les éléments qui sont liés aux routes (Ex : Feu tricolore, passage piéton).
• Choix de l’EPCI : Prendre une autre EPCI, avec un réseau routier plus complet (Moins en étoile / Plusieurs pôles / Avec davantage d’axes principaux).
• A compléter : Prendre des données de population (Ex : Carroyage) pour savoir quel est le point d'eau avec le plus d' "attractivité", j'ai essayé de me baser sur des données Open Street Map, mais je n'ai pas trouvé cela vraiment concluant.

Les technos utilisées

Python (Les principales) :

• OSMNX : Téléchargement des données d'OSM
• GeoPandas : Lecture de certaines données géographiques
• OSGEO : Lecture des données qui n'ont pas été lues à l'aide de GeoPandas
• NetworkX : Path Finding
• Shapely : Construction des Voronoï

Angular / TypeScript :

• Materials : Côté esthétique
• ApexCharts : Pour le graph
• svgdotjs : Pour la construction de certaines des légendes
• Openlayers : Pour la carto

Glossaire :

• EPCI : (Aussi appelé Établissement Public de Coopération Intercommunale) C'est une structure administrative en France qui regroupe plusieurs communes pour exercer certaines compétences ensemble 1. Cela permet aux communes de collaborer sur des projets communs comme la gestion des déchets, les transports, ou l'aménagement du territoire (Ex : Communauté de communes / D'agglomération / Métropoles).
• Open Street Map : C'est un projet collaboratif de cartographie en ligne qui vise à créer une base de données géographiques libre et ouverte du monde entier.
• Centroïde : Terme utilisé en mathématiques et en géométrie pour désigner le centre de masse ou le centre de gravité d'une figure géométrique.
• Polygone de Voronoï : C'est une région d'un diagramme de Voronoï, qui est une manière de diviser un espace en plusieurs zones en fonction de la distance à un ensemble de points. Chaque polygone de Voronoï contient tous les points qui sont plus proches de son germe que de tout autre point.