driving-carGraphe construit
readyrouting · matrix · isochrones
API
Intégrateur OpenRouteService API : routing, matrices et isochrones maîtrisés
OpenRouteService transforme des données OpenStreetMap en directions, matrices temps-distance, isochrones et points rattachés au réseau. Dawap choisit entre l’API publique et un backend auto-hébergé, puis rend explicites profils, limites, date du graphe, services satellites, erreurs et décision métier.
APIs, données et infrastructures que nos projets savent connecter
Du besoin métier au run mesurable
01
Contrat
versionné
02
Sécurité
explicite
03
Reprise
testée
04
Supervision
actionnable
Réponse immédiate
OpenRouteService doit relier un graphe connu à une décision vérifiable.
Dawap intègre Directions, Matrix, Isochrones ou Snapping via l’API publique, ou exploite un backend avec ses profils et graphes. Pelias, POI, élévation et VROOM restent séparés. Aucun cas client OpenRouteService nommé n’est publié à ce jour.
- Choisir API publique ou instance propre selon zone, volume, fonctions, exploitation et fraîcheur attendue.
- Conserver l’ordre longitude–latitude, les index sources/destinations et les cellules impossibles.
- Garder affectation, éligibilité, prix et promesse hors du moteur de routing.
Le calcul dépend du graphe
Self-hoster ORS, c’est exploiter une donnée routable.
Une instance prête ne se résume pas à un conteneur vert. Le poste de recette relie fichier OSM, profils construits, capacité et santé au véhicule réel qui doit passer — ou être refusé.
Scénario de graph buildRhône-Alpes · production cible
simulation de recette
Source OSM PBFauvergne-rhone-alpes-latest.osm.pbfdate exemple · 2026-09-07 · hash conservé
8.4 GB
driving-hgvRecette restrictions
testhauteur · poids · essieux · matières
cycling-regularProfil désactivé
offhors périmètre du premier lot
Health + StatusMoteur disponible · graph_date traçable
200
Recette driving-hgvLe véhicule peut-il emprunter la route ?
scénario · HGV-042
Restriction détectéePont · hauteur 3,80 msegment exclu du résultat
Alternative retenue42,8 km · 51 mindétour +8,4 km · profil driving-hgv
Verdict de recetteLa route respecte le gabarit déclaré.Le moteur explique le détour ; le SI décide si délai et prix restent acceptables.
Quand le graphe devient une dépendance
Trois angles morts rendent un calcul ORS trompeur.
L’endpoint peut répondre alors que le profil ne décrit pas le véhicule, que l’instance privée n’embarque pas les services attendus ou que le graphe ne représente plus le terrain utile.
01
Profil & véhicule
Une route HGV est calculée avec des contraintes incomplètes
Type, dimensions, poids, essieu, matières dangereuses et évitements doivent décrire le véhicule réellement engagé.
02
Backend & satellites
Le self-hosting est supposé recréer tout le service public
ORS, Pelias, POI, élévation et VROOM restent des briques distinctes avec leurs propres données et responsabilités.
03
Donnée & fraîcheur
Une décision ne sait plus quel graphe l’a produite
PBF, date OSM, profils, build, health et version moteur doivent rester liés aux routes, matrices et isochrones.
Architecture OpenRouteService
L’API publique et le backend OpenRouteService ne portent pas le même périmètre
Directions, Isochrones, Matrix, Snapping et Export appartiennent au moteur OpenRouteService. Sur le service public, géocodage, POI, élévation et optimisation sont fournis par des briques distinctes ; les retrouver sur une instance privée exige de les déployer et de les exploiter séparément.
Directions API v2
Envoyer des coordonnées longitude–latitude, sélectionner un profil et demander JSON, GeoJSON ou GPX avec géométrie, instructions, attributs ou extra_info utiles.
Matrix API v2
Référencer sources et destinations par leurs index dans locations, choisir duration et/ou distance, puis conserver les null quand une paire ne peut pas être calculée.
Isochrones API v2
Construire des polygones GeoJSON par temps ou distance, origine, profil et intervalles sans transformer automatiquement leur frontière en zone commerciale.
Profils et contraintes HGV
Avec driving-hgv, préciser vehicle_type et les restrictions nécessaires — dimensions, poids, charge par essieu ou matières dangereuses — avant d’utiliser la route.
Backend auto-hébergé
Dimensionner Java, mémoire, stockage, fichier OSM PBF, profils et construction des graphes ; exposer health/status et organiser les mises à jour sans rupture.
Services satellites
Architecturer Pelias pour géocoder, openpoiservice pour les POI, openelevationservice pour l’altitude et VROOM pour l’optimisation au lieu de les attribuer au backend ORS.
Méthode
On choisit le mode d’hébergement après avoir cadré fonctions et charge
L’API publique donne rapidement accès au moteur et à des services complémentaires sous limites. Une instance propre retire certaines limites configurables mais ajoute données, graphes, capacité, mises à jour et astreinte ; le choix se fait sur des mesures, pas sur l’étiquette open source.
Qualifier le calcul
Route, matrice, isochrone ou snapping avec l’objet métier et le seuil attendus.
Décrire le terrain
Zone OSM, points, profil, véhicule, restrictions, intervalles et cas impossibles.
Choisir l’exploitation
API publique ou backend, capacité, satellites, données, attribution et propriétaires.
Prouver la reprise
Valeur null, graphe en reconstruction, service absent, surcharge et validation humaine.
Premier lot OpenRouteService
Prouver un calcul ORS sur le véhicule, le graphe et la zone réels.
Nous choisissons une décision — route HGV, affectation ou zone accessible — puis la rejouons avec profils, limites, cas impossibles et données OSM réellement exploitées.
1 zone réelle
1 profil vérifié
1 cas impossible testé
Décisions de sortie
Calcul & décision Endpoint, profil, options, métrique, objet métier et propriétaire du verdict.
Terrain & exceptions Coordonnées, détours, restrictions, cellules null et cas de frontière réels.
Graphe & périmètre API publique ou privée, zone OSM, build, satellites, limites et attribution.
Run & reprise Santé, capacité, traces, fallback, recette et règle de généralisation.
Recette OpenRouteService
Trois contre-tests propres à OpenRouteService
La recette vérifie les zones où une intégration apparemment valide peut produire une décision fausse : matrice mal indexée, périmètre self-hosted surestimé ou frontière d’isochrone traitée comme une certitude.
Une matrice carrée par défaut peut calculer trop de paires et masquer des null
Si sources et destinations sont omis, toutes les locations servent des deux côtés. Sur l’API publique, le plafond actuel porte sur 3 500 paires source×destination et tombe à 25 locations avec des arguments dynamiques ; une cellule impossible reste null.
- Entrée
- Ordre longitude–latitude, index locations, sources, destinations, metrics, resolve_locations, options dynamiques, nombre de paires et valeurs null.
- Sortie
- Contrat Matrix avec sous-ensemble minimal, correspondance index–objet métier, limite pré-calculée et statut explicite de chaque cellule.
- Décision
- Ne jamais affecter sur une position de tableau supposée ; bloquer ou dégrader si les paires indispensables manquent.
Installer OpenRouteService ne recrée pas toute l’API publique
Une équipe migre Directions et Matrix vers son propre backend, puis découvre que géocodage, POI, élévation et optimisation ne sont pas inclus. Pelias, openpoiservice, openelevationservice et VROOM sont des services autonomes.
- Entrée
- Inventaire des endpoints publics appelés, dépendances, schémas, authentification, URLs, couverture, données, licences, santé et responsables de run.
- Sortie
- Matrice fonction × composant × mode d’hébergement avec architecture, ownership, capacité et procédure de reprise pour chaque brique.
- Décision
- N’annoncer la parité qu’après test de chaque fonction ; conserver ou remplacer explicitement les services absents.
Un polygone accessible ne constitue pas une zone d’éligibilité
Une adresse proche de la frontière change de côté après évolution OSM, reconstruction du graphe, profil ou lissage. Le GeoJSON exprime un calcul de réseau, pas la capacité, les horaires ni le SLA du service.
- Entrée
- Origine, range_type, ranges ou interval, profil, options, smoothing, date OSM, build du graphe, point frontière et règle commerciale.
- Sortie
- Version d’isochrone reliée à son graphe, tests de bord, marge métier, raison d’acceptation et parcours de validation manuelle.
- Décision
- Utiliser le polygone comme entrée de décision ; revalider les cas limites et garder capacité, prix et promesse dans le SI.
Maillage API
Poursuivre dans le bon univers API
Ces liens permettent de repartir vers la page principale ou vers les univers proches quand le besoin dépasse le seul connecteur.
Avis & exigence projet
Ce que l’on sécurise avec OpenRouteService
5/5★★★★★Avis clients Dawap
“
Coordonnées, profil, options, graphe, métriques et résultat restent liés au même objet métier.
“
Backend ORS, Pelias, POI, élévation et VROOM gardent des responsabilités distinctes.
“
Clés, quotas, limites, graphes, cellules null, erreurs, mises à jour et fallback sont supervisés.
Attractivité-locale.fr rassemble des données publiques d’entreprises dans une carte territoriale utile aux citoyens, élus et acteurs économiques. Dawap a normalisé les sources, fiabilisé les fiches et rendu la recherche plus exploitable pour transformer des API dispersées en service local lisible au quotidien.
openrouteservice calcule routes, matrix, isochrones, snap, geocoder public, POI, elevation et optimization. La méthode cadre API key, Authorization, profils, restrictions, quotas, HTTP 413, 503, codes internes, cache, retry, mode opératoire, retour arrière, support et intégration CRM, OMS, TMS, WMS ou application terrain.
Une API cartographie et géoloc fiable doit arbitrer entre géocodage, ETA, cache, quotas et fallback, sinon la promesse client se dégrade vite. Cette synthèse met l'accent sur le vrai point de contrôle : garder la précision, la source et le coût sous surveillance avant de promettre un itinéraire ou une zone pour chaque flux.
Questions d’achat
Questions fréquentes sur l’intégration OpenRouteService API
Questions fréquentes sur OpenRouteService API v2, Directions, Matrix, Isochrones, profils HGV, API publique, self-hosting et services satellites.
01OpenRouteService est-il adapté à une intégration de production ?
Oui, si la zone, les profils, le mode d’hébergement, les limites, les données OSM, les erreurs et le fallback sont cadrés. L’étiquette open source ne supprime ni les coûts d’infrastructure ni le travail de run.
02L’instance self-hosted offre-t-elle les mêmes services que l’API publique ?
Non. Le backend OpenRouteService porte Directions, Matrix, Isochrones, Snapping et notamment Export ; l’API publique ajoute des services autonomes pour Pelias, POI, élévation et VROOM. Health et Status servent l’instance propre mais ne sont pas exposés sur le live public.
03Comment dimensionner une requête Matrix ?
On sélectionne les index sources et destinations nécessaires au lieu de laisser un all-to-all implicite. La limite publique actuelle est de 3 500 produits source×destination par requête, avec 25 locations au maximum lorsque des arguments dynamiques sont utilisés.
04Comment gérer les restrictions d’un poids lourd ?
On utilise le profil driving-hgv avec vehicle_type, puis les dimensions, poids, charge par essieu, matières dangereuses et évitements utiles. Une route calculée sans ces entrées ne prouve pas la compatibilité du véhicule réel.
05Une isochrone peut-elle définir directement une zone de livraison ?
Non. Elle représente une accessibilité calculée pour une origine, un profil, un range et un graphe. Capacité, horaires, marge, SLA et traitement des adresses proches de la frontière restent des règles du SI.
06Comment sécuriser les clés, données et résultats OpenRouteService ?
On garde les clés publiques côté serveur lorsque le parcours le permet, suit quotas et erreurs, conserve l’attribution demandée, vérifie les droits de cache et trace version moteur, build et date OSM avec chaque décision sensible.
Intégration routing fondée sur OpenStreetMap
Vous voulez intégrer OpenRouteService sans confondre moteur et promesse ?
On peut cadrer l’API publique ou votre instance, livrer un premier flux Directions, Matrix ou Isochrones et rendre données, limites et run vérifiables.
Cadrer mon intégration OpenRouteService