Bonjour, > De : "Christian Quest" > > Le 11 mars 2014 12:06, François Lacombe a > écrit : >> Ceci étant dit, je comprends bien que les routeurs regardent avant tout la >> nature des >> chemins et c'est bien légitime. >> Comment tu affiches ensuite à l'utilisateur le nom de la route à prendre si >> celui-ci >> est indiqué dans une relation dont la route est membre et non sur la route >> elle-même ? >> >> Il faudrait parcourir toutes les relations pour voir si la route est membre >> de l'une >> d'entre-elles mais il doit bien exister un moyen plus optimal. > > C'est le préprocessing. > osm2pgsql le fait à sa façon > osrm le fait à sa façon > etc > Le schéma des données OSM est un schéma que je qualifie de "brut". C'est en > fonction de > l'usage final qu'on va restructurer les données selon ses besoins. > Ce qui par contre nous manque vraiment c'est un moyen de garder des liens > stables entre > des données qui ne le sont pas.
Il n'y a pas forcément de moyen plus optimal. Ce que soulève Christian, c'est que la donnée brute OSM est potentiellement loin, dans sa forme, de la donnée optimale pour un usage donné. Il faut prendre le parti de raffiner la donnée brute, de la mettre en forme pour ton usage. Ça passera, notamment, par la prise en charge de modèles de données multiples pour une même thématique : untel a modélisé un objet sur un way, quand un autre a produit une relation, pour au final la même sémantique. Si tu ne veux pas passer à côté de l'info, tu te dois d'appréhender les objets ways et les objets relations. C'est une situation flagrante pour les adresses (le débat entre relation associatedStreet et tag addr:street) mais il ne faut pas voir ce cas comme une exception. C'est intrinsèque au modèle OSM et à la liberté qu'il offre, cette même liberté qui te permet de saisir des IDs métiers directement dans la base. Je prendrais plutôt le parti, là dessus, de saisir tes IDs métier dans OSM plutôt que de te baser sur une comparaison de géométrie voire d'IDs OSM, exercice fastidieux et fragile, en tout cas plus fragile qu'une comparaison 'stricte' sur un ID externe. vincent _______________________________________________ dev-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev-fr
