[OSM-talk-fr] routage surfacique

[Phyks]

Bonjour,

> casser en disant "yaka faire du routage surfacique",
> c'est méconnaître ce que cela implique techniquement :
> il y a un gros travail de prétraitement à faire.
> je ne retrouve plus hélas l'article qui était publiée sur osmweekly
> mais la moindre place avec qlq rues est transformée en un nuage
> de way qui connectent tous les paires de points de la surface.
> en passant, cela veux dire aussi qu'une place surfacique
> avec 8 nœuds consomme 9x l'espace disque et mémoire
> comparé à sa version linéaire et ce n'est pas en un claquement
> de doigt qu'on augmente la puissance d'un serveur gratuit.
> 
> je pense que les outils continueront de s'améliorer simplement
> à la demande de leur utilisateur, en fonction des ressources dispo.

Dans la plupart des cas, le routage surfacique n'est pas un problème 
quand même. Je mets volontairement de côté une place aussi complexe que 
https://www.openstreetmap.org/relation/8365033 (même le rendu a du mal 
au passage…) pour se concentrer sur des espaces sans trous (tels que les 
espaces dans l'erreur Osmose initiale 
https://osmose.openstreetmap.fr/fr/map/#item=1270&zoom=18&lat=47.497894&lon=-0.580999&level=1%2C2%2C3&tags=&fixable=).


La plupart des moteurs de routage ne vont pas gérer le routage 
surfacique à travers la place (qui est un problème compliqué). En 
revanche, tous vont pouvoir traiter la place comme un way fermé (le 
contour) et tous savent a priori emprunter des portions de way. Du coup, 
le routage ne sera pas "joli" (on ne va pas traverser la place comme on 
le voudrait, simplement contourner en suivant la bordure), mais le 
routage restera néanmoins fonctionnel.

Dans un cas simple comme ceci, à mon avis, il n'y a aucune raison de 
tracer des continuités des chemins à travers les places, si ce n'est 
alourdir la base avec des ways inutiles (et qui n'existent pas sur le 
terrain). La description en termes d'air a une réelle plus value 
(notamment pour le rendu, mais pas que), et reste parfaitement 
utilisable, à condition que les aires portent bien les attributs 
corrects (highway et droits d'accès).

Sur un cas similaire à l'exemple initial d'Osmose :
* BRouter suit le contour, 
http://brouter.de/brouter-web/#map=19/45.77393/3.08337/standard&lonlats=3.083773,45.77412;3.083596,45.773869
* Géovélo aussi, 
https://www.geovelo.fr/clermont/itinerary/search?profile=MEDIAN&bikeType=TRADITIONAL&wayPoints=45.774108,3.08372%7C45.7739,3.0836
* GraphHopper et OSRM aussi, 
https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=45.77411%2C3.08376%3B45.77387%2C3.08360


Mon avis serait donc que sur des places simples (sans trou), il suffit 
de connecter le polygone aux chemins voisins et tout tracé de chemin en 
travers du polygone relève plutôt du "tag to router", en créant des 
chemins qui amélioreront le rendu du routage, mais en aucun cas sa 
justesse.

D'ailleurs, malgré l'erreur Osmose, le routage se fait très bien 
http://brouter.de/brouter-web/#map=19/47.49783/-0.58158/standard&lonlats=-0.581248,47.497738;-0.581433,47.498012.


Ma remarque ne tient plus évidemment lorsqu'on considère des surfaces 
avec des trous (multipolygone) où le routage est épouvantable et 
catastrophique s'il n'y a pas de chemins intérieurs "fictifs", comme le 
montre 
http://brouter.de/brouter-web/#map=17/48.84022/2.32019/standard&lonlats=2.319813,48.841791;2.321146,48.841137&profile=hiking-beta 
par exemple (BRouter ne gère pas le routage surfacique). Ce point est 
beaucoup plus sujet à débat à mon avis et des chemins "fictifs" 
pourraient être justifiés, même si certains ont des avis assez tranchés 
sur la question https://www.openstreetmap.org/note/1654211.
-- 
Phyks