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
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
