[OSM-dev-fr] De l'utilisation des relations et l'identification métier
Bonjour, Étant toujours à la recherche de la bonne stratégie pour attacher des identifiants métiers officiels aux infrastructures que je cartographie, les relations se présentent aujourd'hui à moi dans plusieurs cas. Un identifiant métier reste une donnée qui est plus stable que l'identifiant OSM lui-même et peut permettre une identification d'objets constante dans le temps mais aussi vis à vis de référentiels libérés par les opérateurs. L'idée est que ces identifiants ne concernent qu'un objet et un seul (pour un opérateur donné, voire un type d'objet précisé par d'autres tags parfois). C'est bien souvent pas le cas sur OSM et c'est à déplorer, on s'en mordra les doigts un jour. Fort de ce principe, on doit utiliser des relations pour supporter ces identifiants lorsque l'infrastructure en question est représentée par plusieurs primitives OSM (plusieurs bâtiments par exemple, c'est le cas pour des centrales électriques multi-sites, barrages et autres). Bien souvent, la prescription incitant à utiliser une relation dépasse le simple cadre de l'identification mais c'est de toute façon important. Cependant, parcourir une topologie mêlant objets physiques (noeuds, chemins) et virtuels (relations) n'est pas aisée. Prenons l'exemple d'un réseau routier dans lequel certaines départementales posséderaient plusieurs branches (c'est une hypothèse). Je vais vouloir y faire du routage, donc récupérer l'identifiant de ces routes pour indiquer à l'utilisateur final quelles directions prendre (suivez la D12 pendant x km). Une fois l'itinéraire calculé, je vais avoir une succession de chemins. Pour certains on aura un tag ref=* directement sur le chemin, d'autres seront membres de relations supportant ref=*. Je dois pourtant le retrouver dans tous les cas et trouver la relation dont un chemin est un membre n'est pas vraiment facile avec le modèle OSM. Et surtout savoir quand chercher une relation ou quand ne pas la rechercher est déjà difficile à déterminer (la présence du tag ref=* sur le chemin ou non... mouai). Est-ce que des développeurs ont déjà réfléchi à cette question ? Mon exemple du réseau routier ne colle peut-être pas à la réalité (on appose des lettres sur les identifiants de routes lorsqu'elles ont plusieurs branches). J'ai néanmoins un réseau de ce type sous les yeux, qui ne sera pas disponible sous OSM. Merci par avance. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] De l'utilisation des relations et l'identification métier
Merci Pieren pour cette réponse. Cette observation est sensée et j'ai oublié de dire que la plupart du temps, je travaille sur une BDD hors OSM présentant le même modèle. Des liaisons sont donc souvent faites avec les primitives OSM et mes données mais il est difficile de les maintenir : les objets apparaissent et disparaissent et leur identifiant OSM change. Alors qu'un identifiant métier ne change pas, c'est pour moi un moyen plus stable d’interfacer OSM avec d'autres référentiels, même si 95% des gens ne s'y intéressent pas. Quand je fais un push d'OSM vers ma base, un objet qui a changé d'id OSM va provoquer la création d'une nouvelle entrée. Alors que si on avait un identifiant métier dessus, ça n'arriverait pas et je pourrais même mettre à jour avec la nouvelle id OSM. Regarder la géométrie (si un nœud est à la même place avec un id différent c'est le même qui a changé d'id) ? Pourquoi pas, c'est très bancal et si le nœud a à la fois changé de place et d'id tout en représentant le même objet, je fais quoi ? 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. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com Le 11 mars 2014 11:39, Pieren pier...@gmail.com a écrit : 2014-03-11 11:20 GMT+01:00 François Lacombe francois.laco...@telecom-bretagne.eu: Une fois l'itinéraire calculé, je vais avoir une succession de chemins. Pour certains on aura un tag ref=* directement sur le chemin, d'autres seront membres de relations supportant ref=*. Je dois pourtant le retrouver dans tous les cas et trouver la relation dont un chemin est un membre n'est pas vraiment facile avec le modèle OSM. Et surtout savoir quand chercher une relation ou quand ne pas la rechercher est déjà difficile à déterminer (la présence du tag ref=* sur le chemin ou non... mouai). Est-ce que des développeurs ont déjà réfléchi à cette question ? Je pense qu'il ne faut trop se baser sur la présence de certains tags et qu'OSM est avant tout une bdd géospatiale. Il faut distinguer les tags essentiels des autres. Les essentiels sont par exemple highway=primary/secondary ou building=*. Ce sont ceux qui sont les plus persistents dans OSM car ils sont les qualitifcatifs et ceux qui concernent le plus de personnes. Les tags secondaires sont par exemple les ref=* car ils ont un intérêt moindre. Ils peuvent disparaître plus longtemps de la base. Ce que je veux dire, c'est qu'un logiciel de calcul d'itinéraire se basant sur OSM aura surtout intérêt à se baser sur la géométrie des objets (les ways) utilisant des tags essentiels (comme highway=primary) et les coordonnées de départ/arrivée qu'à chercher la présence ou non d'un tag ref sur un way ou une relation. Pour revenir à ton questionnement originel sur un indentifiant métier, tu peux les mettre dans OSM mais ne pas espérer que beaucoup de gens s'y intéressent. Il y aura aussi un travail de maintenance (effacements accidentels, vandalisme) qu'il faudra que tu assumes si tu comptes t'en servir d'une manière pérenne. Ou alors, tu peux aussi décider de conserver tes identifants métiers hors OSM en faisant le lien avec ce qui t'intéresse dans OSM (voirie, bâti) par ce qu'il y a de plus permanent, c.a.d les tags essentiels (highway, building) et des coordonnées géographiques (soit un périmètre autours d'un point de référence, soit un périmètre en lui-même). Mes 2 cents, Pieren ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] De l'utilisation des relations et l'identification métier
Le 11 mars 2014 12:06, François Lacombe francois.laco...@telecom-bretagne.eu 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. -- Christian Quest - OpenStreetMap France Conférence State Of The Map France du 4 au 6 avril à Parishttp://openstreetmap.fr/sotmfr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] De l'utilisation des relations et l'identification métier
Un exemple sur opensnowmap: lorsque je recherche une piste particulière, je regarde s'il n'y a pas un autre way connecté avec les mêmes attributs pour ne retourner qu'une seule piste constituée de plusieurs way. Il vaut mieux faire des requêtes métier que se trimballer des ids. On 11 mars 2014 12:28:11 UTC+01:00, Christian Quest cqu...@openstreetmap.fr wrote: Le 11 mars 2014 12:06, François Lacombe francois.laco...@telecom-bretagne.eu 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. -- Christian Quest - OpenStreetMap France Conférence State Of The Map France du 4 au 6 avril à Parishttp://openstreetmap.fr/sotmfr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] De l'utilisation des relations et l'identification métier
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 dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] De l'utilisation des relations et l'identification métier
2014-03-11 12:51 GMT+01:00 V de Chateau-Thierry v...@laposte.net: 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. Il faut être très prudent ici. Il ne faudrait pas qu'OSM devienne le réceptacle de milliers d'IDs métier. Ils sont aujourd'hui tolérés dans OSM lorsqu'on leur trouve une justification pour OSM (surtout avec l'argument qu'ils pourraient faciliter plus-tard des mises à jour et synchronisation de bases externes, processus encore très hypothétique; on trouve déjà des plaintes sur l'utilité de ces refs). Les IDs métiers à usages purement internes n'ont pas leur place dans OSM et il sera bien difficile de crier au vandalisme si quelqu'un les efface. J'ajouterais que les tags dans OSM ne sont pas moins fragiles que les ID's de primitives, au contraire. Pieren ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] De l'utilisation des relations et l'identification métier
De : Pieren 2014-03-11 12:51 GMT+01:00 V de Chateau-Thierry : 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. Il faut être très prudent ici. Il ne faudrait pas qu'OSM devienne le réceptacle de milliers d'IDs métier. Ils sont aujourd'hui tolérés dans OSM lorsqu'on leur trouve une justification pour OSM (surtout avec l'argument qu'ils pourraient faciliter plus-tard des mises à jour et synchronisation de bases externes, processus encore très hypothétique; on trouve déjà des plaintes sur l'utilité de ces refs). Les IDs métiers à usages purement internes n'ont pas leur place dans OSM et il sera bien difficile de crier au vandalisme si quelqu'un les efface. J'ajouterais que les tags dans OSM ne sont pas moins fragiles que les ID's de primitives, au contraire. Qu'on soit bien d'accords. Je parle d'IDs externes uniquement pour des IDs que chacun sera(it) susceptible de manipuler, un peu comme le sont aujourd'hui les différents identifiants que produit l'INSEE. Il ne s'agit pas de propager des IDs connus uniquement dans une sphère privée (IDs internes à une organisation, une entreprise, et non publiés). Je n'ai pas de détails sur les IDs dont parle François, à lui de préciser dans quelle catégorie se situent ses références métier. vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] De l'utilisation des relations et l'identification métier
+1 avec Pieren et vdct Il me semble que les ID externes ont leur place dans OSM lorsqu'il font référence à une source vérifiable, celle-ci pouvant être le terrain (N° visible sur un objet) ou dans un fichier public (donc vérifiable vu que le fichier est public, exemple: les codes INSEE). Si l'une de ces conditions n'est pas remplie, c'est vraiment un ID privé et à mon avis ça n'a rien à faire dans OSM. Le 11 mars 2014 13:31, V de Chateau-Thierry v...@laposte.net a écrit : De : Pieren 2014-03-11 12:51 GMT+01:00 V de Chateau-Thierry : 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. Il faut être très prudent ici. Il ne faudrait pas qu'OSM devienne le réceptacle de milliers d'IDs métier. Ils sont aujourd'hui tolérés dans OSM lorsqu'on leur trouve une justification pour OSM (surtout avec l'argument qu'ils pourraient faciliter plus-tard des mises à jour et synchronisation de bases externes, processus encore très hypothétique; on trouve déjà des plaintes sur l'utilité de ces refs). Les IDs métiers à usages purement internes n'ont pas leur place dans OSM et il sera bien difficile de crier au vandalisme si quelqu'un les efface. J'ajouterais que les tags dans OSM ne sont pas moins fragiles que les ID's de primitives, au contraire. Qu'on soit bien d'accords. Je parle d'IDs externes uniquement pour des IDs que chacun sera(it) susceptible de manipuler, un peu comme le sont aujourd'hui les différents identifiants que produit l'INSEE. Il ne s'agit pas de propager des IDs connus uniquement dans une sphère privée (IDs internes à une organisation, une entreprise, et non publiés). Je n'ai pas de détails sur les IDs dont parle François, à lui de préciser dans quelle catégorie se situent ses références métier. -- Christian Quest - OpenStreetMap France Conférence State Of The Map France du 4 au 6 avril à Parishttp://openstreetmap.fr/sotmfr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
