Étiquette : osm

  • 🚗 OSM vs IGN : et si nous repensions la manière de mesurer les virages ?

    Sur le papier, un virage routier OSM ou IGN, c’est juste “la route qui tourne”. Dans la réalité métier, c’est un indicateur critique. C’est là que les conducteurs freinent tard, que la voiture prend du roulis, que la consommation explose, que les sinistres arrivent. Aujourd’hui, on s’en remet à des cartes qui décrivent ces virages de façon plus ou moins fidèle. Problème : si la géométrie est approximative, tout ce qu’on calcule derrière est faux — évaluation du risque conducteur, scoring d’éco-conduite, calibration ADAS, simulation inertielle. Dans ce billet, on montre pourquoi deux sources pourtant « sérieuses » (OpenStreetMap et l’IGN) ne racontent pas exactement la même route, et pourquoi ça compte pour l’industrie, pas juste pour les géomaticiens.

    Pour plus d’informations, consultez la base OpenStreetMap ou la BD TOPO® de l’IGN.
    Retrouvez également notre article sur la simulation inertielle 10 Hz avec RoadSimulator3.

    Comparaison OSM vs IGN des virages routiers

    Pourquoi comparer OSM et IGN ?

    Les virages sont bien plus que de simples courbes sur une carte. Ils influencent directement la sécurité routière, le confort des passagers, la consommation énergétique. Ils ont aussi un impact sur l’efficacité des systèmes d’aide à la conduite ou des simulateurs. Pourtant, une question simple reste ouverte : quelle est la vraie géométrie d’un virage ?

    Une même route, deux géométries différentes

    Dans notre étude, nous avons comparé deux grandes sources de données cartographiques :
    • OpenStreetMap (OSM) : une base mondiale, collaborative et ouverte.
    • BD TOPO® de l’IGN : une base nationale française, construite par des géomaticiens professionnels.

    Premiers résultats : les deux sources ne décrivent pas les virages de la même manière. OSM tend à simplifier les géométries (les virages apparaissent plus « anguleux »), tandis que l’IGN conserve une description plus fine. Ces différences sont invisibles à l’œil nu sur une carte. Elles ont un impact direct sur le calcul du rayon de courbure, et donc sur tout ce qui en dépend (sécurité, simulation, éco-conduite).

    Ces différences de courbure routière OSM influencent directement la perception du virage et les modèles de simulation.

    Vers un référentiel géométrique des virages

    🎯 Notre ambition : construire un référentiel des virages
    Nous ne voulons pas seulement comparer des chiffres. Notre ambition est plus large : créer un véritable référentiel des virages. Ce sera un cadre géométrique robuste qui s’appuie sur les principes de l’ingénierie routière (clothoïdes, arcs, lignes droites).

    Pourquoi ?
    • Pour mieux évaluer la qualité des données cartographiques.
    • Pour fournir une base de travail cohérente et exploitable par les chercheurs, les industriels et les collectivités.
    • Pour améliorer les simulations inertielles de RS3, en les rapprochant de la réalité physique des routes.

    Impacts pour la simulation inertielle et la sécurité flotte

    🚀 Une étude structurante
    Ce travail est structurant pour le projet RoadSimulator3 : il ne s’agit pas d’un simple module technique, mais d’un socle commun qui permettra d’évaluer, comparer et exploiter différentes sources de données routières.

    En résumé, une meilleure compréhension de la courbure routière OSM ouvre la voie à des modèles plus robustes et à une analyse fine du comportement conducteur.

    Conclusion

    Notre conviction : en construisant un référentiel de virages robuste, nous poserons les bases d’une meilleure compréhension des routes. Nous ouvrirons la voie à des applications concrètes — de la sécurité routière à l’éco-conduite, en passant par la simulation et la mobilité intelligente.

    👉 Vous pouvez retrouver notre premier post sur le sujet ici : OSM vs IGN : tous les virages ne se ressemblent pas.

  • Formats de données liés à OpenStreetMap

    Format PBF OpenStreetMap : pourquoi l’utiliser ?

    Illustration du format PBF OpenStreetMap

    Le format PBF OpenStreetMap est un format de fichier binaire compressé permettant de stocker efficacement les données géographiques issues d’OpenStreetMap. Il est devenu incontournable pour les développeurs, cartographes et spécialistes SIG à la recherche de performance.

    💾 Un format compact et rapide

    Contrairement au format XML .osm, le format PBF est plus léger et plus rapide à charger. Il convient parfaitement aux analyses massives et à l’intégration dans des pipelines automatisés. Sa structure binaire permet un traitement plus fluide, en particulier avec des outils comme Osmium ou osmconvert.

    📌 Quand utiliser le format PBF ?

    Le format PBF OpenStreetMap est recommandé dans les situations suivantes :

    • Importation rapide dans des bases de données cartographiques (ex. PostGIS).
    • Traitement de grandes régions géographiques (> 100 Mo de données OSM).
    • Simulation de trajets avec des outils comme RoadSimulator3.

    🔗 Pour aller plus loin

    Consultez la documentation officielle du format PBF sur le wiki OpenStreetMap pour découvrir ses spécifications détaillées et outils compatibles.

    Article rédigé par l’équipe RoadSimulator3. Sources : OpenStreetMap Wiki, Osmium Tool.

    Mots-clés : format PBF, OpenStreetMap, OSM, fichier cartographique, données géographiques, osmconvert, osmium

  • Le Format PBF d’OpenStreetMap : Stockage Cartographique Efficace

    Format PBF OpenStreetMap : stockage compact pour la cartographie

    Le format PBF OpenStreetMap (Protocolbuffer Binary Format) est une version binaire compressée du célèbre format XML d’OpenStreetMap. Il permet d’alléger considérablement la taille des fichiers tout en accélérant leur traitement. Cette efficacité le rend particulièrement adapté aux systèmes embarqués ou aux plateformes de simulation comme RoadSimulator3.

    Pourquoi le format PBF est-il utile ?

    Le format PBF est pris en charge par de nombreux outils, notamment Osmconvert pour les extractions et conversions rapides, ou encore Osmium et Osmosis pour la gestion et le filtrage des données.

    Applications dans RoadSimulator3

    Dans notre projet RoadSimulator3, le format PBF est utilisé comme source de vérité géographique. Grâce à sa structure optimisée, il facilite l’interpolation, la construction de graphes routiers et la génération de trajets réalistes à haute fréquence.

    Téléchargement des fichiers PBF

    Les fichiers au format PBF sont disponibles sur Geofabrik, une plateforme de référence proposant des découpes régionales d’OpenStreetMap. Il est recommandé de choisir des extractions régionales adaptées à vos besoins pour réduire la charge mémoire.

    Mots-clés : format PBF OpenStreetMap, données cartographiques compressées, OSM, Osmconvert, Osmosis, Geofabrik, simulation

  • OSMnx : une API puissante mais coûteuse en temps sans graphes locaux

    OSMnx : Un outil essentiel pour l’analyse et la simulation routière

    OSMnx est une bibliothèque Python incontournable pour la récupération et l’analyse de réseaux routiers basés sur OpenStreetMap. Elle permet en quelques lignes de code de :

    • Télécharger des graphes routiers par ville, département ou région.
    • Générer des graphes orientés ou non orientés pour les modes de déplacement (voiture, vélo, piéton).
    • Calculer des itinéraires, des centralités, la densité urbaine, etc.
    • Exporter les graphes au format GraphML ou shapefile.

    Cependant, son usage repose sur des appels API à OpenStreetMap, ce qui entraîne plusieurs limites en pratique.

    La dépendance à l’API et ses inconvénients

    Utiliser OSMnx en direct nécessite une connexion Internet constante et expose à plusieurs risques ou contraintes :

    1. Limitations API OSM : OSM impose des quotas pour éviter les abus. Cela limite la récupération de graphes volumineux comme un département entier.
    2. Délais de téléchargement : Extraire un réseau routier dense (ex : Île-de-France) peut prendre plusieurs dizaines de minutes, voire échouer.
    3. Données dynamiques : Les données peuvent varier au fil du temps, rendant la reproductibilité difficile si l’on ne stocke pas les versions utilisées.
    4. Pas de graphes pré-construits publics : Il n’existe pas de dépôt officiel proposant les graphes OSMnx prêts à l’emploi au format GraphML pour les régions françaises ou mondiales.

    Générer ses propres fichiers GraphML : un processus long

    La solution classique consiste à générer soi-même les fichiers GraphML à partir des données OSM. Mais cela présente plusieurs inconvénients :

    • Il faut maîtriser la configuration d’OSMnx pour obtenir un graphe filtré et cohérent.
    • Le processus est lent pour des régions étendues.
    • Le stockage et la maintenance des fichiers deviennent une charge pour les utilisateurs non experts.

    ReadyData : l’alternative immédiate pour les graphes par département

    Pour contourner ces limitations, ReadyData, proposé avec RoadSimulator3, met à disposition une collection complète de graphes OSMnx pré-calculés par département français :

    • Chaque graphe est fourni en format GraphML, prêt à l’emploi.
    • Les graphes incluent les typologies routières, nécessaires pour la simulation inertielle et contextuelle.
    • Gain de temps immédiat : pas besoin de script ou de connexion API OSM pour travailler sur un territoire donné.

    Cette approche permet aux utilisateurs de RoadSimulator3, ou de pipelines data science, d’accélérer leur prototypage et d’assurer la reproductibilité des analyses géographiques et routières.

    Conclusion

    OSMnx reste une bibliothèque fondamentale pour la recherche et l’ingénierie routière, mais sa dépendance à l’API et l’absence de graphes publics pré-construits freinent son adoption directe à grande échelle. ReadyData comble ce vide en fournissant des graphes prêts par département, contribuant à une exploitation immédiate pour les simulations, la mobilité intelligente ou la recherche en IA embarquée.

  • Qu’est-ce que le SRTM ?

    Définition

    Le SRTM (Shuttle Radar Topography Mission) est un projet international mené par la NASA et la NGA (National Geospatial-Intelligence Agency).
    Il a pour objectif de cartographier la topographie de la surface terrestre en haute résolution à l’aide de radars embarqués à bord de la navette spatiale Endeavour en février 2000.


    Données produites

    • Modèle Numérique d’Élévation (MNE) mondial.
    • Résolutions :
    • 30 mètres (~1 arc-second) pour les États-Unis.
    • 90 mètres (~3 arc-seconds) pour le reste du monde (version initiale).
    • Depuis 2015, les données à 30m sont disponibles mondialement.
    • Format : fichiers raster au format GeoTIFF.

    Applications

    • Études de terrain et d’altitude.
    • Modélisation hydrologique.
    • Simulation de propagation radio ou télécom.
    • Visualisation 3D des paysages.
    • Calculs de pentes, dévers et courbures dans des applications comme :
    • SIG (QGIS, ArcGIS)
    • simulation inertielle ou géographique

    Accès

    Les données SRTM sont :

    • Gratuites.
    • Téléchargeables via :
    • Le portail de la NASA Earthdata.
    • USGS Earth Explorer.
    • Plateformes comme OpenTopography.

    Résumé

    Le SRTM est une source essentielle pour les modèles d’altitude globale, bien qu’il existe désormais des alternatives plus précises comme :

    • Copernicus DEM
    • ASTER GDEM

  • Python et la cartographie

    Python est très utilisé en cartographie et en géomatique pour plusieurs raisons clés :


    ✅ 1. Écosystème riche de bibliothèques géospatiales

    • Geopandas : manipulation de données géographiques comme des DataFrames.
    • Shapely : géométrie (intersection, union, distances).
    • Fiona : lecture/écriture de fichiers SIG (Shapefile, GeoJSON…).
    • Pyproj : projection et transformation de coordonnées.
    • OSMnx : extraction et analyse de graphes routiers OSM.
    • Folium / Leaflet : visualisation cartographique interactive.
    • H3-py : indexation hexagonale.
    • Rasterio : traitement des images satellites ou MNT.

    ✅ 2. Langage simple et accessible

    • Syntaxe claire, rapide à prendre en main.
    • Communauté très large et active.
    • Adapté aux non-informaticiens comme les géographes ou urbanistes.

    ✅ 3. Interopérabilité avec les outils SIG

    • QGIS intègre Python pour les scripts et plugins.
    • API Python pour ArcGIS.
    • Capacité à lire/écrire des formats standards : Shapefile, GeoJSON, KML, PBF, etc.

    ✅ 4. Puissance pour l’analyse de données spatiales

    • Intégration facile avec PandasNumPyscikit-learn.
    • Compatible avec les frameworks Big Data : Spark, Dask.
    • Outils de visualisation : Matplotlib, Seaborn, Plotly.

    ✅ 5. Utilisé dans la recherche et l’industrie

    • Projets de mobilité, de logistique, de planification urbaine.
    • Projets de simulation de trajets, comme RoadSimulator3.
    • IA géospatiale : détection d’anomalies, segmentation d’imagerie satellite.

    En résumé : Python s’impose en cartographie car il allie puissance, flexibilité, accessibilité, et un écosystème très complet de librairies géospatiales.

  • OSRM et ses concurrents directs

    OSRMGraphHopperValhalla
    LangageC++JavaC++
    Focus principalRoutage ultra-rapide (voiture)Routage rapide, isochronesRoutage multi-modal avancé
    Trafic Temps Réel
    Multi-modalitéLimitéPartiel (vélo, piéton)Complet (vélo, bus, ferry, horaires)
    API REST
    AlgorithmeContraction Hierarchies (CH)Contraction Hierarchies (CH)Algorithmes flexibles, plus lents
    LicenceBSDApache 2.0MIT
    Cas d’usage typiqueNavigation GPS, logistique rapideApps mobiles, calculs vélo/piétonTransports publics, isochrones complexes

    ✅ Synthèse

    • OSRM : la vitesse pure, surtout pour la voiture.
    • GraphHopper : rapide et polyvalent, idéal pour applications mobiles et le vélo/piéton.
    • Valhalla : le plus adapté aux besoins avancés multi-modaux et au trafic en temps réel.
  • OSMnx

    OSMnx est une bibliothèque Python open-source qui permet de :

    • Télécharger des réseaux routiers ou piétons depuis OpenStreetMap directement via API.
    • Construire des graphes géographiques : intersections = nœuds, rues = arêtes.
    • Analyser ces graphes avec des outils de graph theory (réseaux, centralités, longueurs, etc.).
    • Visualiser les réseaux sous forme de cartes graphiques.
    • Exporter les graphes au format GraphML, shapefile ou géodataframe.

    Exemples d’utilisation :

    • Créer un réseau routier d’une ville :

    import osmnx as ox graph = ox.graph_from_place("Paris, France", network_type="drive")

    • Calculer un itinéraire, des indicateurs (densité, longueur totale, centralité).

    Limites :

    • Dépend d’une connexion Internet et de l’API OpenStreetMap.
    • Extraction lente pour de grandes zones (département, région entière).
    • Pas de dépôt officiel avec des graphes déjà prêts pour tout un pays.

    En résumé :

    OSMnx est un outil puissant pour extraire, analyser et visualiser les réseaux de transport, mais son usage à grande échelle nécessite de générer ses propres fichiers localement, faute de bases de graphes toutes prêtes.

  • Le MNT d’iGN – compliqué à intégrer

    Le MNT (Modèle Numérique de Terrain) de l’IGN, comme RGE Alti®, est parfois difficile à intégrer dans des projets comme RoadSimulator3 pour plusieurs raisons :


    ✅ 1. Format complexe et spécialisé

    • Les MNT IGN sont souvent fournis en formats raster géoréférencés (GeoTIFF) ou en grilles ASCII.
    • Ces formats nécessitent des outils spécialisés comme GDALRasterio, ou QGIS pour être lus et traités correctement.

    ✅ 2. Poids et résolution élevée

    • Les données IGN sont en très haute résolution (jusqu’à 1 mètre), générant des fichiers très volumineux (plusieurs Go) par département.
    • Cela implique :
      • Un stockage conséquent.
      • Des temps de traitement longs pour interpoler ou extraire l’altitude en temps réel.

    ✅ 3. Projection et reprojection

    • Les MNT IGN sont souvent en projection Lambert 93 ou CC (Conforme Conique), qui nécessite une conversion en WGS84 pour être utilisé avec des données GPS.
    • Ce reprojection nécessite des outils comme Pyproj et peut être source d’erreurs si mal paramétrée.

    ✅ 4. Couverture départementale

    • Les fichiers MNT sont fournis par département, donc pour couvrir un trajet qui traverse plusieurs zones, il faut :
      • Télécharger et concaténer plusieurs MNT.
      • Implémenter une logique de sélection spatiale dynamique.

    ✅ 5. Pas de serveur API prêt à l’emploi

    Contrairement à des services comme Mapbox Terrain ou Open-Elevation API, l’IGN ne propose pas de service cloud simple pour interroger l’altitude :

    • Il faut héberger et indexer soi-même les données.
    • Cela ajoute une complexité d’infrastructure.

    ✅ Conclusion

    Le MNT IGN est très précis, mais :

    • lourd,
    • difficile à manipuler sans expertise SIG,
    • et sans API standardisée.

    👉 Pour des besoins temps réel ou large échelle, beaucoup préfèrent :

    • Des MNT globaux moins précis mais légers (ex : SRTM 30m).
    • Ou un pré-calcul local des altitudes avant intégration dans une simulation.

  • H3

    H3 est un système de géocodage spatial hexagonal développé par Uber. Il divise la surface de la Terre en une grille de cellules hexagonales hiérarchiques, ce qui le rend très utile en géospatial.

    ✅ Caractéristiques principales

    • Grille hexagonale : contrairement aux grilles carrées classiques, les hexagones couvrent mieux la surface terrestre sans distorsion majeure.
    • Hiérarchique : chaque cellule peut être subdivisée en hexagones plus petits à des résolutions croissantes (15 niveaux de zoom).
    • Index géospatial : chaque cellule possède un identifiant unique (index H3) qui encode sa position et sa résolution.

    ✅ Usages

    • Analyse spatiale : clusterisation, heatmaps, comptage d’occurrences par zone.
    • Télématique : suivre les véhicules ou objets par cellule H3.
    • Simulation et logistique : optimiser les zones de livraison, coverage.
    • Data Science géospatiale : simplification des calculs et jointures spatiales.

    ✅ Avantages

    • Facile à manipuler.
    • Efficace pour les calculs de proximité.
    • Compatible avec des systèmes big data (Spark, etc.).